Getting started with accessibility testing
It comes up on almost every project, usually later than it should. A short on-ramp to accessibility testing for teams who have not touched it before.
The cost of retrofitting accessibility is several times the cost of building it in. Check it against what you would want a competitor's site to get wrong.
The reason this keeps coming up
Automated tools catch perhaps a third of real issues. Getting it slightly wrong is survivable. Ignoring it entirely is not. Write the reasoning down alongside the decision, because the reasoning is what changes first.
Your first week
- Find out what is already in place
- Keyboard-only testing finds problems in minutes
- Change one thing and measure it
Testing with disabled users finds what nothing else does. 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.
What this looks like day to day
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
- Keyboard-only testing finds problems in minutes — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you want a second opinion on how yours is set up, ask.