I have a quick question and I’m curious to see how people respond. Ever since this video, more and more projects require accessibility testing. I’m curious—what tools or procedures do you use for that?
I have a few on my list, and each day I come across more and more—like this one, for example. But I’d prefer to hear opinions or get a few ideas directly from people. Google or Perplexity are full of articles that just copy each other, and tools that are either super expensive or just weird.
It’s a classic “it depends” answer. So there are levels of accessibility testing depending on the commercial importance of the product and the markets they’re used in.
In past prior to EAA 2025, we had WCAG levels stated in contracts so we got deep into Accessibility testing. The main level aimed for was AA compliance. So we used Axe dev tools and did exploratory testing using screen readers. We used that experience and “shifted left” so that all the key issues we found were built into our dev style guide so it became habitual and less of a big deal.
On top of that as part of one of our government contracts, one product was put through specific accessibility testing involving impaired users…which in the end is the ultimate test.
So automated tools go so far, exploratory testing by non-impaired users who’ve researched the subject adds a bit extra. But as EAA non-compliances can result in a fine and/or removal of service, then the level you invest in compliance testing depends on budgets, whether your software product is publicly available etc. as to whether you utilise in a specific accessibility testing centres.
So whilst I think we do a pretty good job with our accessibility compliance and have put some good practices in place, its never “done” with these evolving standards.
Depending how compliant you need to be, determines how much to do. Exploratory or heuristic reviews strike a nice balance of “speed and good feedback”.
I’ve written about this before, and the approach generally still applies in different contexts. Even in non-government settings. On recent projects I’ve taken a more exploratory led approach over showing WCAG compliance, due to the project contexts. This has worked well in these situations.
As Gary says, it depends. If you’re content to do a bit of superficial and potentially inaccurate testing, there are dozens, perhaps hundreds of tools of varying complexity. However, even if you use them all, and use them correctly, you can only do perhaps 30% of the tests required for a proper WCAG audit. bear in mind that the EAA mandates conformance with EN 301 549, which goes a long way beyond WCAG.
Tools can’t get you anywhere near that. The Cypress.io video is disgraceful - they know or should know the limitations of what their tool can do.
To do a complete, accurate WCAG audit requires a detailed understanding of the 55 level A and AA success criteria and the techniques for testing them. In many cases, the appropriate technique depends on how features are coded, so you need a “toolbox” of at least a couple of hundred techniques to draw from.
Don’t trust tools
Tools can help, but they only provide information. The pass / fail decision MUST be based on inspection of the code and the user interface. Never take the result from a tool at face value because they are frequently wrong. We increasingly build our own tools so at least we know when they may be misleading.
It’s really difficult
To get to a reasonable level of competence requires thousands of hours of learning and even more experience i.e. somewhere in the range of 10,000 to 20,000 hours. We don’t even interview people with less than 10 years’ full time accessibility testing experience. I mention this to give some context to what a functionality tester can expect to achieve if they only do a few hours of accessibility testing here and there. There’s some low hanging fruit, but it gets really difficult after that.
Bookmarklets
We use loads of individual ones from various sources as well as writing our own. The following are some useful collections.
Browser extensions
We use loads of single-purpose extensions, such as for freezing the DOM or applying custom CSS. We also use these WCAG testing extensions.