Skip to content
Resources
Testing

Testing

Automated Tools

There are a number of testing libraries that can be used to test for accessibility issues, including:

These tools can be incorporated into normal pipelines, or run at separate times, to ensure that the accessibility of the site is maintained.

While these will only be identifying the automated issues, they can be used to ensure that the site is at least at a basic level of accessibility.

Handling the output

The output from the axe-core libraries can be quite verbose, and may be large blobs of JSON to those unfamiliar with the output. Over time, the output should only be showing the newly failing issues, but when introducing to a project it may be overwhelming.

The main thing to look for will be the sets of violations, which will be an array of objects, within which the important information for resolution would be the id and nodes, which in turn will have html and target properties to help identify the failing element.

The other properties are very useful for understanding the issues and getting information on how to fix them, so they shouldn't be outright ignored.

If these are still proving too difficult to understand or find the elements, the Accessibility Insights (opens in a new tab) extension can be used to help identify the issues, as this will use the same tool under the hood, but will give a more user-friendly and visual output to help identify the problem elements. (The exact errors returned may differ depending on the versions used and tags checked.)

Manual Testing

When testing the accessibility of a site, it's important to test with a keyboard, screen reader, and other assistive technologies to ensure that the site is usable by all.

Some tools to support that manual testing include:

Screen readers are the hardest to test as someone that has never used one before, so the step before learning that would be to use the Chrome Dev Tools Accessibility Pane to see most of what a screen reader would see.

(For example, using the full accessibility tree view to see the order of elements, and the accessible names of each element.)

Screen Reader Testing

A screen reader will be an incredibly useful way to test the site, but may also give false negatives if it isn't used correctly.

To mitigate this, and to limit the amount of time spent learning how to use a screen reader, there is a tool that allows you to see what a screen reader would see.

NVDA (opens in a new tab) is a free screen reader that can be used to test the site, and it's also a good way to learn how to use a screen reader.

Once downloaded, the volume can be reduced in "Tray Icon -> Right Click -> Preferences -> Settings -> Speech -> Volume". If just using to see what a screen reader would announce, this can be set to 0.

To see what the screen reader would announce, use "Tray Icon -> Right Click -> Tools -> Speech Viewer". This is a written log of all the things the screen reader would try to announce and gives a more debuggable output than the audio.

Ideally, learning how to use the screen reader properly would give the best results, but simply tabbing around with the speech viewer open should give a good idea of what the screen reader would announce, as well as hovering with the mouse.