Web Accessibility Tools

This page contains a list of tools that can be used to evaluate the accessibility of web content. These tools are available under an open source licence unless otherwise noted. Inclusion in this list does not imply endorsement.

Note: most accessibility requirements, such as the WCAG success criteria and the requirements in EN 301 549, cannot be evaluated automatically.

Lists of Tools

Individual Tools

Code Checkers

This section lists browser add-ons or extensions and web-based accessibility checkers. For libraries that allow test automation, for example, in pipelines, see the section Automated Testing.

Abandoned Tools

The following tools are no longer being developed:

Automated Testing

Running axe-core

axe-scan (NPM)

axe-scan is a command line tool that you can use to test multiple web pages using the axe-core library. The axe-scan code (hosted on GitHub) requires Node.js, axe-core and Puppeteer. See also axe-scan on NPM.

Below is a short version of the list of instructions provided at the above link. They were tested in the PowerShell on Windows 10. The instructions should also work with the regular command prompt.

  1. Open the PowerShell and use the command node -v to find out whether Node.js is installed on the system. If not, download and install Node.js. You may need to reboot Windows after installing Node.js.
  2. In the PowerShell, install axe-scan using the following command: npm install -g axe-scan. At the end of the installation process, you may get a recommendation to update to a newer version of npm. If this is the case, update npm; the command will look as follows, but you may need a different number at the end: npm install -g npm@10.2.1.
  3. Still in the PowerShell, create a config file for axe-scan using the following command: axe-scan init --global.
  4. Still in the PowerShell, update axe-scan using the following command: npm update -g axe-scan.
  5. Create a directory where you want to save scan results. For example, if you are in C:\Users\<your-user-name>, you can create a directory named axe-scan, either in Windows Explorer or from within the PowerShell. In the PowerShell, you can use the command mkdir axe-scan to create the directory, then move into that directory using the command cd axe-scan. If you wish, you can create separate subdirectories per site that you want to scan.
  6. In the directory where you want to save scan results, create a file named urls.txt. In this file, list the URLs of the pages you want to scan. Use one line per URL and make sure there are no empty lines, even at the end of the file. Important: the file should be encoded in UTF-8 without a byte order mark. Incorrect encodings, including UTF-16, can lead to “protocol errors” because the tool can't read the URLs.
    (You can also create files on the command prompt, but you will still need to check that there is no empty line at the end of the file.)
  7. In the PowerShell, make sure that you are in the directory where you stored urls.txt. Then run the scan using the following command: axe-scan run > results.csv. You can choose a different file name than results.csv, for example one that contains the name of the scanned site.
  8. After the scan has finished, you can open the CSV file in a spreadsheet program. For example, if you use LibreOffice Calc, make sure that only tab and comma are selected as separators, and that the semicolon is deselected.

See also

Abandoned Libraries

The following libraries are no longer being developed:
  • Grunt Accessibility, by Steven Miller is an HTML codesniffer to grade accessibility. It is a command-line tool for checking static HTML pages on your hard drive. You can specify which level of the Web Content Accessibility Guidelines (WCAG) 2.0 the code should be tested against. (Licence: MIT.) The source code has not been updated since early 2018, so it has not been updated since the publication of WCAG 2.0.
  • access_lint: Check for web accessibility errors from Ruby. Available under the MIT licence. Uses the Audit Rules defined for the Google Chrome accessibility developer tools. (This tool is no longer being maintained. The developer instead recommends AccessLint.)
  • Ember A11y Testing (available under the MIT licence) is a wrapper around Deque Labs' axe-core accessibility testing engine. It integrates into your testing environment with a simple a11yAudit() helper. The GitHub repository has not been updated since November 2017. (Last accessed on 23.12.2024.)
    See also Ember A11y on GitHub.
  • AccessLint: Automated and continuous web accessibility testing. According to its developers, AccessLint is a GitHub App that finds accessibility issues in your pull requests. (20.07.2022.) The AccessLint app in the GitHub Marketplace can be used for free by hobbyists for the personal projects but requires payment if you want to use it for private projects or on an entire organisation on GitHub. (See also the AccessLint app and the other checkers by the organisation AccessLint.
  • Deque Labs: aXe Selenium (Java) Integration: demonstration of how to use aXe to run web accessibility tests in Java projects.
    This repository was deprecated in October 2020. Licence: Mozilla Publice License 2.0.
  • Peter Kranz: Raakt - The Ruby Accessibility Analysis Kit. Source code available on Rubyforge.org under the BSD 3-clause licence. (The source code repository could not be reached on 06.05.2022.)
  • Anil Suryanarayana: seleniumAccessibility: Selenium Webdriver driven accessibility testing module to check for webpage accessibility compliance. Licence: MIT License.
    The source code repository has not been updated since July 2015. (Last accessed on 06.05.2022.)

Contrast Checkers

Whether foreground and background colous have sufficient contrast is not something that you should try to “eyeball”. For example, red and green are strongly contrastly contrasting colour for people with normal colour vision but not for most people with colour vision deficiencies. There are many free tools that can help you check contrast, find colours with sufficient contrast or simulate certain colour vision deficiencies.

Most contrast analysis tools now support the contrast algorithm defined in the Web Content Accessibility Guidelines (WCAG) 2.0 and will tell you whether the contrast ratio pass at Level AA or at Level AAA. Some tools will also tell you whether the contrast meets the requirements defined in the Techniques For Accessibility Evaluation And Repair Tools (AERT) (August 2000). However, this document never went beyond the W3C working draft stage, and its contrast algorithm is explicitly marked as open to change.

Tools that simulate colour blindness try to approximate what people with colour vision deficiencies see; the output of these tools should not be interpreted as exact renditions of what these people see.

See also the separate list of bookmarklets for colour or contrast.

Articles on Checking Contrast

Accessible Colour Pickers

Colour Blindness Simulators

Important: so-called colour blindeness simulators or colour vision simulations provide only approximations of colour vision deficiencies.

Articles about Automated Accessibility Evaluation

The Automatability of Accessibility Evaluation

In other words, how many of WCAG's success criteria can be checked automatically?

Developing Browser Extensions

Stylesheets for Finding Issues

Various Browser-Based Tools

Browser Features for Accessibility Inspection

Bookmarklets

Bookmarklets are listed in their own section because they are useful in environments where installing browser extensions or add-ons is not allowed.

Bookmarklets for Colour or Contrast

Stylesheets and Various Scripts

Stylesheets, bookmarklets and other scripts for visualising specific markup features.

Browser Features and Extensions for End Users

Comparing or Benchmarking Evaluation Tools

Using Screen Readers for Accessibility Testing

Reporting Tools

Monitoring Tools

Other Resources and Links