This list of Web Accessibility tools is going to be a bit unusual. Some of them may not even be considered accessibility tools, especially the ones from the first section. But, usability and accessibility go hand in hand, and some usability tests will help improve and boost Web Accessibility later on.
With these points in mind, I picked 12 tools and grouped them into four different categories:
- General validation tools: not necessarily related to accessibility, but rather to web validation.
- Color contrast checkers: specific tools to detect contrast issues.
- General accessibility validation tools: to scan for technical accessibility issues.
- Screen readers: programs that will traverse the screen to read its content.
The order of the list above is not random either. The scope of some of the tools overlap, but in my opinion, this order would be ideal to use the different programs and perform the accessibility tests. If for any reason you are not running any tests, or if you want to start but don't know how, begin at #1 and work your way up to #4.
This is the set of tools that are normally not considered related to accessibility, but they will find potential accessibility issues that are not normally detected by accessibility tools (e.g. incorrectly formed HTML, image size recommendations, etc.).
Fixing the problems reported by these tools will improve more than accessibility: performance, SEO, security... In this sense, they are the first step to making sure that your website not only is properly built, but also properly accessible.
The W3C HTML validation service will just check the markup validity of your document. It won't focus on accessibility, but many of the issues that it will find may improve the current accessibility status (e.g. missing attributes like
alt) and some others that will help pave the road for a better accessible site (e.g. incorrectly formatted/nested HTML elements).
This is one of my favorite tools for testing HTML compliance and performance. It not only provides incredibly useful information and links, but also creates solutions in some cases. For example, if an image is not the right size or format, it will process it and generate a new image that will fit better for you to download, simplifying the correction process.
Insufficient color contrast between text/images and their background was the most common issue found in The WebAIM Million analysis. So, it should not come as a surprise having contrast checkers as an independent section (even when the tools from the following section include color contrast checkers of their own).
There are many tools that can help to detect insufficient contrast, all of which have their pros and cons. It's more a matter of finding one that matches your needs or easily developing your own.
This WebAIM tool is not particularly special. It resembles most of the other color contrast checkers online, as it is easy to use and contains detailed information about the guidelines.
This site allows to customize the color contrast test a little bit (font size, colors, accessibility levels, etc.), but the interesting part is that it goes a step beyond only calculating the color contrast. If the colors are not a good match and fail the validation, Accessible Colors will suggest new combinations that will actually pass the test.
Google Chrome includes an interesting color contrast checker with the Developer Tools. It is one of the few I've seen that allows multiple color formats, and it has a great graphical interface in which you can see which values would be accessible and which ones wouldn't. The only con I have found is that it only seems to work if the element has the color and background properties defined. (It doesn't infer them from the ancestors.)
You must be saying, "Finally!" These are the tools that most people associate with accessibility (along with the screen readers), and the ones that you were probably expecting. (I said it was an unusual list at the beginning.)
With these tools, you will be able to scan a site, generally one page at a time, for accessibility issues: color problems, unorganized content, empty links, missing
alt attributes, etc. But, always take the result with a grain of salt. Although they are great for detecting technical problems, some of the guidelines are not always technical and can slip through the cracks of these tools.
This tool is probably my favorite accessibility application, in part because it is the one that I used to start and learn the basics. I would use its online mode (and later its convenient Chrome plugin and Firefox add-on) to check my web pages and read about the errors, their descriptions, and the suggestions to fix them. Another thing that I like about this tool is its color contrast checker that infers the ancestors' background more accurately than other tools.
Axe is another add-on/plugin that works on Chrome and Firefox. It is powerful and easy to adopt in your day-to-day programming (though you have to open the Developer Tools in order to use it), and the analysis is well organized thanks to its comprehensive navigation and the categorization of issues.
This tool works in two ways: (1) directly online by parsing the HTML code on the tool site; and (2) as a bookmark that you can activate on any page independently of the browser used. The results are sound, but sometimes the number of false positives that HTML_CodeSniffer reports (especially related to color contrast) is a bit high. You can record the false positives as such, and the tool won't detect them again.
You have run tests with the accessibility checkers above, and the results are all positive. Does that mean that your website is fully accessible and compliant? Unfortunately, no. All the previous tools are great, but they mainly check for technical requirements, or the "theory." But some real "practicality" may still be needed.
And that's where screen readers become useful. Being proficient at using them and browsing your site in a way similar to the one a user with disabilities would require time, but reaching a comfortable level of proficiency is not so time-consuming, especially when many of the screen readers have common commands or share instructions on the fly.
NVDA is an amazing tool. It's straightforward, easy to use, reliable, and really powerful. It is my go-to screen reader when working in Windows... which is its main issue: it only works with Windows machines (here the authors explain why). But, its usability and performance make it an incredible tool, able to compete with other screen readers that cost hundreds of dollars.
Mac users have a nice screen reader integrated in the Mac OS system. VoiceOver can be activated by pressing Command + F5, and deactivated in a similar manner. As with NVDA, this is a full screen reader that will work beyond the scope of the browser and read every program (which can be a bit annoying if you only want to test a website).
If you work with Chrome, this plugin is a must for accessibility. When activated, it will act as a screen reader and present most of the functionalities that other screen readers include. (Keyword: "most.") Its core functionality is really nice, and it is a good way to test things fast. A pass in ChromeVox may or may not indicate a pass in NVDA or VoiceOver, but a fail in ChromeVox is most assuredly a fail with the other screen readers.
This list includes tools that I have used and continue to use every day to test and ensure Web Accessibility in applications. All the tools have their pros and cons (a reason why I use them in parallel many times, even when some run the same tests), but the tools' advantages overall outweigh the disadvantages.
Many great tools such as Sortsite, Total Validator, JAWS, or ZoomText are missing, but you have to pay for them (though the first two have some nice trial versions), and I wanted to limit the list to free tools.
What tools do you use to test accessibility? Which one would you recommend or add to this list?
Note: All the tool logos have copyright/trademark that are owned by the different companies/organizations that develop them.