Five mistakes teams make with accessibility testing
There is no clever trick in this one, just a handful of decisions worth making deliberately. These are the ones we run into repeatedly when we audit accessibility testing.
Accessibility work almost always improves the experience for people who have no impairment at all. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
Where it usually goes wrong
- Treating it as a launch task rather than an ongoing one
- Assuming someone else already owns it
- Automated tools catch perhaps a third of real issues
- Keyboard-only testing finds problems in minutes
- Never checking whether the fix actually worked
Testing with disabled users finds what nothing else does. The teams that handle this well are rarely the ones with the biggest budgets. Write the reasoning down alongside the decision, because the reasoning is what changes first.
What to do next
How to tell if yours is fine
The cost of retrofitting accessibility is several times the cost of building it in. Three things worth confirming about accessibility testing before you move on:
- Someone can say what the current setup is without going to look
- Testing with disabled users finds what nothing else does — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Most of the value here comes from doing the first two things, not all of them.