Accessibility testing, explained without the jargon

It comes up on almost every project, usually later than it should. Here is accessibility testing without the vocabulary that usually surrounds it.

Most of it is correctness rather than charity: use the right element and much of it happens automatically. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

The short version

Automated tools catch perhaps a third of real issues. There is a version of this that is over-engineered, and it is worth avoiding. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. It is worth being explicit about, because assumptions differ quietly.

Keyboard-only testing finds problems in minutes. The teams that handle this well are rarely the ones with the biggest budgets. Assume whoever inherits this will have half your context and none of your patience.

Making it stick

Testing with disabled users finds what nothing else does. That sounds obvious written down. It is still the thing most often skipped. Doing this properly once is usually cheaper than doing it approximately three times.

The short version

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

Worth checking on your own setup before it becomes someone else's problem to fix.