Axe is a digital accessibility toolkit from Deque, which is considered to be among the industry leaders in accessibility testing and resources. It has multiple integrations that help create a consistent approach to testing at multiple stages in the development cycle:
VS Code extension – catch fundamental accessibility issues as you write your code, such as missing alt text on images and not correctly labelled form input elements.
Devtools – this lightweight extension integrates as a tab in your browser dev tools. It allows you to scan a page for accessibility issues and step through any it may find in more detail. Key features include explanations of the issue with links to view more information, and the ability to tag the issue with any WCAG success criteria to help prioritise issues if needed.
React package – if working with a React stack the axe package will output any accessibility violations in Chrome dev tools as you make changes, helping catch issues early as you build.
Jest package – Axe can also be run as part of the tests you write when building components, disabling common issues from making it into production.
Wave is a browser extension that can quickly check a page for accessibility issues.
It’ll categorise them into critical errors and warnings that need some manual testing and investigation.
This is a great tool to see in a snapshot how many issues you may have on a page while using handy tools for checking the heading content structure and colour contrast.
At Code, we have a Pa11y dashboard set up for each of our product teams.
These can be configured as they see fit for the products they work on. Pa11y helps catch and monitor accessibility issues that might appear on sites during development, but also once in production and potentially introduced by new content being added.
Similar to Wave it categorises the issues by severity and can be configured to run periodically against different WCAG conformance levels and criteria.
Lighthouse (Chrome devtools)
Many of us will have used Lighthouse during the development workflow, but have you noticed it has an “accessibility” category?
This can be a great way to surface accessibility issues whilst you’re checking it for other metrics, as it can offer more detailed explanations and links to more information.
As with many automated tools, be aware even with a score of 100 for accessibility, you could still have an inaccessible experience. For example, it can’t inspect any non-visible elements.
An especially useful browser extension for getting a visual on your tab order and stops. It can mark them all on your page, and then link them up with a line as you tab through.
This can be useful when presenting to anyone who may not be able to understand the issue and why it’s so important from explanations alone. Accessibility Insights also comes with some other basic page checks.
This extension seems to have a tool for everything! The ability to highlight heading levels and usage of ARIA is particularly useful.
You can do mini-reviews of pages/sites to see where problems may lie, and there are some nice links to run accessibility checks and HTML/CSS validation as well.
Browser accessibility developer tools
Browser developer tools are improving all the time and include some great ways to test accessibility.
The ability to inspect the accessibility tree is particularly useful. This can sometimes save time debugging issues without having to open a screen reader.
The accessibility tree can be used to see how assistive technology might interpret your element. You can make sure that it has an accessible name, check its role and along with any state information it may have. Think of it as the DOM inspector but for accessibility information.
Browser developer tools can also be used to emulate various vision deficiencies, such as blurred vision and colour blindness, along with settings a user might have toggled at an OS level, such as preferred reduced motion and forced-colours mode.
Manual accessibility tools
Colour contrast checker
This tool, which is also available as a Chrome extension, was created by one of our Computerlovers, Alex. You can quickly check how the contrast of two colours scores at different conformance levels, with the benefit of seeing some example elements using the combination as well.
When considering accessibility testing, the keyboard might not be something that you consider. However, it is one of the easiest and most powerful ways to test accessibility that anyone can do.
Have you ever tried putting your mouse to one side and trying to use a page, component or user journey?
Doing this during the build can be a great way to pick up issues early, such as focus states/order, key components not usable and even components skipped completely!
Testing with screen readers can be intimidating at first, but with handy guides available to learn the shortcuts and functions from WebAIM, it’s an important tool in a testing workflow.
JAWS and NVDA are the most widely used screen readers, both being Windows. For Mac, VoiceOver is already built-in.