Automated accessibility testing can be used to detect the most common accessibility problems. This is only the first step in the process; you MUST NOT rely on automated testing as your sole method of validation! None of these tools on their own will catch every error. Even by combining all of them, it's still possible to produce an inaccessible webpage.
Terrill Thompson compared several of the most popular tools which should give you some idea of the scale of the problem. The GDS Accessibility team ran an experiment in 2017 to audit the performance of a large number of available automated accessibility testing tools. They found that the highest number of errors that one tool was able to detect was 40%. The majority of the tools fell into the 20%-30% range.
You MUST NOT rely on automated accessibility testing tools as your sole safeguard for accessibility testing.
We use Pa11y to perform automated accessibility testing. Pa11y is an automated accessibility testing tool that supports HTML_Codesniffer by Squizlabs, and axe by Deque.
Projects MUST have Pa11y integrated at the build stage, and builds MUST fail if errors are introduced. You MUST NOT allow accessibility regressions to enter your project's codebase. We're aiming to make accessibility better, so our baseline is to not make it worse.
Mature projects using Pa11y for the first time MAY use the threshold
flag to specify a baseline number of errors to allow through, but MUST aim to reduce that threshold to zero at the earliest opportunity. Watch this talk by Laura Carvajal of the Financial Times to get a high level overview of the concept.
Read Automated accessibility testing with Travis CI to see how to integrate Pa11y with your build process. If you're not using Travis, adjust the setup for the software that you are using.
You can use HTML_Codesniffer or axe as your test suite; we recommend using both. Neither engine is "better" than the other, they just use different testing strategies. When you fail builds based on Pa11y results, bear in mind that the two testing engines return different numbers of results, and their results are formatted differently.
If you're a VS Code user, you can also install Deque's axe accessibility linter from the Visual Studio marketplace and catch some common accessibility errors before they get to the build stage.
Manual accessibility testing fills in the gaps that automated tools miss.
- Microsoft’s free Accessibility Insights tool is a browser extension for Chrome that will guide you through the process of assessing a webpage for basic accessibility conformance. It's not a complete guide to accessibility, but will help you catch things that automated testing can't.
You're encouraged to test your pages with assistive technology (AT). Many operating systems include some AT as standard, including screenreaders, magnifiers, or input remapping.
Make sure you test your work at high magnification. You may also find navigating without an input device using Voice Control instructive. Ensure your interfaces work with keyboard navigation.
If you don’t use a screen reader regularly, the way that you use it will be different to that of a habitual screen reader user, so be cautious in extrapolating your own experiences to those of other users. But also bear in mind that not all regular screen reader users are experts or power users, just like not all users of web browsers are experts.
If you’re a Mac user, VoiceOver is built-in to OSX and is a decent, basic screen reader. This guide from WebAIM explains the basics of using VoiceOver to test pages.
If you’re a Windows user, NVDA is one of the more popular screen readers amongst blind users. This guide from WebAIM explains the basics of using NVDA to test pages.
On mobile, VoiceOver is built-in on iOS devices, and TalkBack is usually built-in on Android devices. 71% of respondents to the WebAIM Screen Reader User Survey #8 use iOS VoiceOver on mobile.
Many people use multiple screen readers, instead of relying on just one. For this reason (and because our philosophy is that we must support all users, no matter their device, browser, or network condition), we don't target specific Assistive Technology packages.
- Squizlabs have an HMTML_Codesniffer bookmarklet for quick tests.
- The Axe engine comes as a browser extension for Chrome, Firefox, and Edge, and as an NPM module that you can integrate with your build, like Pa11y.
- WebAim's WAVE extension for Chrome and Firefox evaluates accessibility in place on the page.
- The ARC Toolkit by TPGi is a useful extension for Chrome that (among other things) can detect semantic/structural issues, and problematic use of ARIA.
In addition to Microsoft's Accessibility Insights tool, here are some other things we like:
- Check colour contrast conformance with WebAim's Colour Contrast Checker or TPGi's Colour Contrast Analyser tool (for Mac and Windows).
- The Landmarks browser extension (for Firefox, Chrome and Opera) enables navigation of WAI-ARIA landmarks, via the keyboard or a pop-up menu.
-
An extensive guide to making audio and video media accessible from the W3C.
-
The Trace Center’s Photosensitive Epilepsy Analysis Tool (PEAT) is a downloadable resource that can identify seizure risks in web content and software. PEAT analyses visual media to detect patterns, flashing lights, and rapid color changes.
Disability simulators are apps, extensions, or experiments that imitate the experience of being disabled for non-disabled people. They're designed to increase empathy and awareness of the issues facing disabled people.
It's very important that you understand the limitations of disability simulators. No browser extension could ever give you an appreciation of what it's like to navigate the world as a disabled person. No blindfold game can teach you what it's like to be systematically discriminated against in virtually every aspect of your daily life. You can just switch the simulator off - a disabled person doesn't have that option.
If used carelessly, disability simulators can also have the opposite effect of what's intended. Instead of giving non-disabled people empathy with those who experience disability in a particular context, they can elicit sympathy or pity reactions. Pity reactions lead to responses like "that's terrible", and not "how can we help?". As web professionals who care about the experiences of all of our users, we need to make sure our response to any disability simulators is "how can we help?". The June 2017 issue of Braille Monitor discusses the research on disability simulation, its limitations, and how it can be improved.
With this caveat in mind, here are some disability simulators that may help you or your team understand some of the ways in which people with some disabilities may perceive your web pages.
- Funkify is an extension for Chrome that helps you experience the web and interfaces through the eyes of users with different abilities and disabilities.
- Empathy prompts are flashcards with things to consider when making things for others to use.