How to get accessibility testing right
There is no clever trick in this one, just a handful of decisions worth making deliberately. The short answer to accessibility testing is that it is mostly a sequence of small decisions, not one big one.
The cost of retrofitting accessibility is several times the cost of building it in. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
What it costs to ignore
Automated tools catch perhaps a third of real issues. In practice this is a scheduling problem more than a technical one. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
The steps
- Establish what you have today before changing anything
- Keyboard-only testing finds problems in minutes
- Testing with disabled users finds what nothing else does
- Write down the decision so the next person does not re-litigate it
Testing with disabled users finds what nothing else does. The reasoning matters more than the rule, because the rule has exceptions. The version that survives contact with a real deadline is the simple one.
Where to go from here
In practice
Accessibility work almost always improves the experience for people who have no impairment at all. Three things worth confirming about accessibility testing before you move on:
- Someone can say what the current setup is without going to look
- Automated tools catch perhaps a third of real issues — and you know whether that is true here
- There is a way to tell whether the last change to this helped
The point is not perfection, it is knowing which of these you have consciously chosen to skip.