ARIA label coverage: when one hundred percent is the warning sign

The first rule of ARIA, stated in the WAI ARIA authoring practices, is that no ARIA is better than bad ARIA, and native elements with native labels beat added attributes. A standard button element with the text checkout inside it is fully labelled already. Adding an aria label that says complete your purchase now means a screen reader announces words the sighted user cannot see, and a voice control user who says click checkout gets no match, because the accessible name no longer contains the visible words.

That failure has a criterion: label in name, WCAG 2.1 success criterion 2.5.3, Level A. It exists precisely because well meant labelling diverged names from labels at scale. A coverage metric that climbs by adding labels to text buttons is therefore manufacturing A level risk while reporting itself as accessibility progress.

The first rule is not a slogan

Two narrower numbers do the real work. First, the share of icon only and textless controls that carry an accurate accessible name: that one should be one hundred percent, and every miss is a genuine defect. Second, a sampled accuracy audit of existing aria labels: does the name contain the visible text, does it describe the actual action, does it include context like the product name on repeated controls. Report the two numbers separately and let the blanket coverage figure go.

Sampling catches the other common rot: stale labels. A button relabelled in a redesign keeps its old aria label because nobody sees it, so the screen reader goes on announcing last year's wording. Coverage cannot see staleness. A human comparing name to screen, fifty controls at a time, sees it immediately.

What to measure instead

Replace the single coverage dial with three lines: textless controls named, currently a count of misses with locations; label in name violations found in the latest sample; and stale labels corrected this period. The dashboard gets less pretty and more useful, which is the usual direction of honest metrics in this field, and the team's effort moves from adding labels to fixing names.

A dashboard that tells the truth

Keep reading: Focus Visible Failure Rate: The Metric That Predicts Keyboard Complaints, Alt Text Coverage vs Alt Text Quality: Two Metrics, Two Different Lies.

Frequently asked questions

Why is full ARIA label coverage a bad target?

Because most buttons are already labelled by their visible text. Adding aria labels to them overrides that text for assistive technology, and when the wording differs it breaks the label in name criterion and defeats voice control users who speak the visible words. Coverage rewards exactly that harm.

Which controls genuinely need an aria label or equivalent?

Icon only controls, controls with no visible text, and repeated controls that need context, like four remove buttons in one cart. Those should all carry accurate accessible names. That narrower set is the one where one hundred percent is the right target.

What is the label in name criterion?

WCAG 2.1 success criterion 2.5.3, Level A. Where a control has visible text, its accessible name must contain that text, so voice control users can activate it by speaking what they see and screen reader users hear names that match the screen.

How do I audit existing aria labels efficiently?

Sample them. Take fifty labelled controls per audit, compare each accessible name against the visible text and the actual action, and log mismatches and stale wording. Sampling finds the systematic problems, which are usually one component's labels copied everywhere.