ARIA labels, explained without the jargon

There is no clever trick in this one, just a handful of decisions worth making deliberately. Here is ARIA labels without the vocabulary that usually surrounds it.

Accessibility work almost always improves the experience for people who have no impairment at all. Assume whoever inherits this will have half your context and none of your patience.

The short version

No ARIA is better than wrong ARIA. The cost of getting this wrong is rarely visible on the day it happens. The version that survives contact with a real deadline is the simple one.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The reasoning matters more than the rule, because the rule has exceptions.

Use it only when native elements cannot do the job. The teams that handle this well are rarely the ones with the biggest budgets. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Turning this into a decision

Labels must match what the control actually does. It is worth being explicit about, because assumptions differ quietly. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The short version

The cost of retrofitting accessibility is several times the cost of building it in. Three things worth confirming about ARIA labels before you move on:

• Someone can say what the current setup is without going to look
• Use it only when native elements cannot do the job — 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.