How do automated accessibility checkers compare?
We ran an audit to see what issues the different accessibility testing tools pick up. We deliberately introduced 143 accessibility barriers to a page of content, and ran them through 10 automated tools. We also had a look at features like usability and cost.
You can use our audit to help choose the best accessibility testing tool for your service.
The full project is available on Github. We welcome contributions.
What we found
We scored each tool for two things.
The first column of numbers shows the percentage of barriers that each tool fully detected on a ‘pass’ or ‘fail’ basis.
The best performing tool in this category found 38% of the problems we introduced. Whereas the worst performing tool only picked up 9% of the barriers.
The second column of results takes into account potential barriers that tools noticed, but needed a human being to check, like whether alt text descriptions were accurate. A tool that flags things like this can help you pick up more issues overall.
The best performing tool in this category picked up 43% of our deliberate mistakes.
How did each tool do?
|Tool||Barriers found||Barriers and potential barriers found|
|Nu Html Checker||9%||9%|
Last updated: 10 March 2017
How do features compare?
We’ve also compared features like how easy tools are to use, cost and technical considerations - all important things to think about when you are choosing a tool.
What these features mean
- Cost (manual) The cost of running the tool manually in a web browser. Paid tools will usually let you check single pages for free, but will redirect you to a login page for some features like documentation.
- Cost (CI) The cost of running the tool if you code it into your service under continuous integration (CI). Some tools are free to run but you have to pay for features like API access.
- Open source The tool is open source, which means you can access the source code for free. You may also be able to help to make the tool better if you can fix a problem with the code.
- Active The tool is being actively developed. We recommend using tools that are updated according to the latest developments in accessibility.
- CI The tool can be run under continuous integration (CI). This is the practice of constantly releasing and testing code. Projects using a CI environment should use an automated testing tool that works with CI. This will help you make sure mistakes in your build are caught early.
- CLI The tool can be run on a command line interface (CLI). CLI tools are more versatile for developers, and can usually be integrated into either continuous integration (CI) or unit testing.
- In-browser The tool works in a web browser. These tools are usually extensions and are easy to install and use, making them useful for non-developers. In-browser tools often make it easier to test things like individual scenarios and internal tools behind firewalls.
- Internal use The tool can be used internally. This might be useful if your service is for internal use only or has sensitive components that you don’t want to test on the internet.
- Mobile The tool can simulate a mobile browser and test with it.
- Scriptable To simulate things like filling in a text box or clicking a button you can write a script for the tool to follow, saving you a lot of manual work.
- HTTP Auth The tool can access and test password protected websites.
- Guidance The tool provides related documentation that explains why the thing it has picked up is a problem and how to fix it.
|Tool||Cost (manual)||Cost (CI)||Open source||Active||CI||CLI||In-browser||Internal use||Mobile||Scriptable||HTTP Auth||Guidance|
|Sortsite||Free||£89.10 / £494.10||No||Yes||Yes||Yes||No||No||No||No||No||Good|
|Nu Html Checker||Free||Free||Yes||Yes||Yes||Yes||No||Yes||No||No||Yes||No|