Screen readers, explained without the jargon

Teams tend to reach for this after something has already gone wrong. Here is screen readers without the vocabulary that usually surrounds it.

Accessibility work almost always improves the experience for people who have no impairment at all. Check it against what you would want a competitor's site to get wrong.

The short version

Test with one and the theory becomes obvious. There is a version of this that is over-engineered, and it is worth avoiding. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. Where this goes wrong is almost never a lack of knowledge.

Correct markup does most of the work. The cost of getting this wrong is rarely visible on the day it happens. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Where to go from here

Announced changes need live regions. It is worth being explicit about, because assumptions differ quietly. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

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 screen readers before you move on:

• Someone can say what the current setup is without going to look
• Correct markup does most of the work — 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.