Accessibility testing: what to get right first

The version of this that works is simpler than the version most people imagine. If you only fix one thing about accessibility testing this quarter, make it the first item below.

The cost of retrofitting accessibility is several times the cost of building it in. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Start here

Automated tools catch perhaps a third of real issues. Where this goes wrong is almost never a lack of knowledge. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Then this

Keyboard-only testing finds problems in minutes. It is worth being explicit about, because assumptions differ quietly. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Eventually

Testing with disabled users finds what nothing else does. The teams that handle this well are rarely the ones with the biggest budgets. The version that survives contact with a real deadline is the simple one.

The short version

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
• 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

If any of that sounds like a description of your current setup, it is fixable.