Accessibility Testing Tools

Automated testing tools help you find accessibility issues in your Information Technology (IT), like websites or web applications. These tools range from browser add ons that will alert you to issues in specific pages, to cloud services that will scan websites and provide you with a report.

You will still need an understanding of web technology to interpret the results. Automated testing tools will also only surface about 40% of the potential issues in your IT. Actually inspecting your IT with a checklist while doing manual functional testing is also required.

We do recommend an “automated testing first” strategy, however, because:

  • it will identify with little effort a large proportion of any problems your IT may have
  • it will give you a quick idea of the accessibility of your IT
  • it will narrow down the number of manual functional tests you need to perform afterwards

Test case-driven vs view-driven testing

When doing automated or functional testing you may choose a route through your IT determined by what you consider to be the critical paths. This test case-driven approach has the benefit that it will shed light on the most important areas of your IT so that you can address them first. It will also highlight inconsistencies between views as you follow a workflow. It does require preparation of the test cases, however.

View-driven testing involves examining each view as a thing in itself, without reference to others. It is quicker to get off the ground, but you may miss some “whole picture” issues or issues that have an impact on some critical functionality.

Which testing regime you choose will depend on many factors. If the IT is mostly informational, and you are confident that the information architecture is clear and efficient, view-driven testing is adequate. If the IT is interactive and requires user input and decisions, test case-driven testing is highly recommended. Imagine if the login screen is inaccessible and you did not follow the “User can log in” test case, for example.

Tools for documents

If your IT is not web-based, the most common authoring tools provide you with ways to check the accessibility of the documents you are creating. Instructions:

Tools for websites and web-based apps

If you are comfortable with HTML, CSS and Javascript:

If you have a limited technical background:

If your IT is static, public and voluminous and you would like to check many pages in one go:

Other tools for web-based IT

  • Web Disability Simulator
    Lets you simulate color blindness, low vision, dyslexia and more.
  • Colour Contrast Analyser
    Most automated testing tools will find contrast problems, but occasionally they are not able to do so with accuracy because of diverse reasons. When this is the case, the Colour Contrast Analyser browser add on is invaluable.
  • HeadingsMap
    Produces a lightweight report of the structure of a page (headings and landmarks).
  • Stylus
    Useful to inject styles into a page - provide visible focus, highlight all images without an alt attribute, etc. You will seldom need to use this, but it will be very useful when you do. Requires some knowledge of CSS.
  • Photosensitive Epilepsy Analysis Tool (PEAT).
    A Windows tool to help authors determine whether animations or video in their content are likely to cause seizures.

Using the tools

We can only provide documentation and support for a limited number of tools.

axe Expert

U-M has a limited number of licenses for the axe Expert extension for Chrome. If you download it, let the accessibility team know so that we can register it. If we run out, you can use axe DevTools. Screencasts below will be using Attest, the old version of axe Expert.

Accessibility Insights for the Web

Again - the testing engine is axe, so the reports will have some similarities to axe Expert. It does provide a bit more scaffolding and support documentation. See the screencasts below.

axe Monitor

axe Monitor is intended to help units and departments that have a large web presence make their offerings accessible. It is a server based spidering service that uses the axe engine to provide reports on entire static websites. The university has a limited number of licenses and we want to reserve these for folks that are going to take an active role in monitoring and remediating core informational websites. See more information on U-M's axe Monitor system.


WebAIM has some simple documentation on using this tool. The WAVE browser extension is probably the easiest way to incorporate it into your workflow.

What next?

As mentioned above, automated testing is just the first step. With that done your manual functional testing can focus on the things that automatic testing will likely miss.

You should perform simple non-technical tests designed specifically to surface issues that will not be reported by automated testing.