Three myths about accessibility testing

Teams tend to reach for this after something has already gone wrong. A few things about accessibility testing that get repeated more often than they get checked.

Accessibility work almost always improves the experience for people who have no impairment at all. Budget a little time for it every quarter and it never becomes a project of its own.

“It only matters for big sites”

Automated tools catch perhaps a third of real issues. The cost of getting this wrong is rarely visible on the day it happens. Budget a little time for it every quarter and it never becomes a project of its own.

“We can deal with it after launch”

Sometimes true, usually expensive. The cost of getting this wrong is rarely visible on the day it happens.

“Our platform handles it”

Testing with disabled users finds what nothing else does. Where this goes wrong is almost never a lack of knowledge. The version that survives contact with a real deadline is the simple one.

How to tell if yours is fine

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

Most of the value here comes from doing the first two things, not all of them.