Before you invest in accessibility testing

It comes up on almost every project, usually later than it should. Before you spend anything on accessibility testing, it is worth confirming a few things are already true.

Accessibility work almost always improves the experience for people who have no impairment at all. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• Automated tools catch perhaps a third of real issues
• You have a way to tell whether it worked

The mistakes we see most

Keyboard-only testing finds problems in minutes. In practice this is a scheduling problem more than a technical one. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Testing with disabled users finds what nothing else does. Getting it slightly wrong is survivable. Ignoring it entirely is not. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

How to tell if yours is fine

Most of it is correctness rather than charity: use the right element and much of it happens automatically. 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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.