WCAG 2.5.3 Label in Name Explained

WCAG 2.5.3 Label in Name (Level A) requires that when a control shows a visible text label, the control’s programmatic accessible name contains that same text. If a button reads “Search,” its accessible name must include the word “Search” — so someone using voice-control software can say “click Search” and have it work.

What 2.5.3 actually says

The W3C normative wording is short: “For user interface components with labels that include text or images of text, the name contains the text that is presented visually.” There’s also a best-practice note that the visible label should appear at the start of the accessible name.

Two terms do the heavy lifting here:

• Label — the text a sighted user reads to identify a control: the words inside a button, the text of a link, the visible text next to a checkbox or before an input.
• Name — the accessible name, the string computed from your markup (from aria-label, aria-labelledby, an associated <label>, inner text, value, title, etc.) and handed to assistive technology.

The rule is a containment rule, not a perfect-match rule: the name must contain the visible label, ideally beginning with it. Capitalization and punctuation differences don’t count as failures — speech software ignores them, so a visible “First Name:” matches an accessible name of “first name.”

Who it affects

This criterion exists almost entirely for speech-input (voice-control) users: people with motor or mobility disabilities, repetitive strain injuries, or limited dexterity who drive their computer by talking to it. Tools like Dragon NaturallySpeaking, Windows Voice Access, and Apple Voice Control let a user activate a control by speaking its visible label — “click Search,” “click Add to cart.”

When the accessible name doesn’t contain the visible label, that command silently fails. The control is visible but unreachable by voice. There’s an important nuance most guides skip: Dragon and Windows Voice Access will match a control if the visible word appears anywhere in the accessible name, but Apple Voice Control only matches the full accessible name — so extra words before or after the label can break it on Apple devices even when they don’t on Windows. That’s why the criterion pushes for the label at the start of the name.

Screen reader users (NVDA, JAWS, VoiceOver) and people with cognitive disabilities benefit too: when the spoken name matches what’s on screen, there’s no jarring mismatch and less to remember.

Concrete failure examples — and the fix

These are the patterns we see constantly during remediation. Each one passes a visual eye test and a quick “does it have a label?” check, yet fails 2.5.3.

1. An aria-label that overrides the visible word. This is the number-one cause, documented as W3C failure F96. A search button shows “Go” but the developer added a “more descriptive” aria-label:

<!-- FAILS: visible "Go", accessible name "Find in this site" -->
<button aria-label="Find in this site">Go</button>

<!-- PASSES: name contains the visible label, at the start -->
<button aria-label="Go — search this site">Go</button>
<!-- Simpler: drop the aria-label and let the text be the name -->
<button>Go</button>

Saying “click Go” does nothing on the first version, because the accessible name is “Find in this site.”

2. A submit input whose value and accessible name disagree. aria-labelledby wins the name computation, so the on-screen word never makes it into the name:

<!-- FAILS: shows "Search", accessible name "Find in this site" -->
<span id="lbl" hidden>Find in this site</span>
<input type="submit" value="Search" aria-labelledby="lbl">

<!-- PASSES: drop the override; the value becomes the name -->
<input type="submit" value="Search">

3. A visible label and a programmatic label that don’t match. A field shows “Phone” but is wired to a hidden label reading “Daytime contact number.” Voice users see “Phone” and say “click Phone”; nothing happens.

4. Hidden text injected into the middle of a link name. A link reads “Download specification” but inserts off-screen text so the name becomes “Download gizmo specification.” Even though the visible words are present, they’re broken up — Apple Voice Control won’t match the spoken “Download specification.” Keep injected context after the visible label, or move it to aria-describedby.

What’s explicitly allowed. Symbolic glyphs that aren’t human language are exempt: a “B” and “I” in a rich-text toolbar should be named “Bold” and “Italic,” not the letters. Mathematical expressions are the exception to that exception — keep them as-is. And a placeholder may serve as the label only when there’s no other visible text, which is itself a fragile pattern (placeholders disappear on input).

How to test for 2.5.3

You can audit this quickly, but it’s a manual check — automated scanners catch missing names (4.1.2) far better than mismatched names.

1. List every control with visible text: buttons, links, tabs, and inputs with a visible label or button-style text.
2. Read the accessible name. In Chrome or Edge DevTools, inspect the element and open the Accessibility pane — the “Computed Name” is exactly what voice and screen-reader software receive. Or run a screen reader and listen.
3. Compare. Does the computed name contain the visible label text? Ignore case and punctuation. For best results, confirm the label is at the start of the name.
4. Voice-test the high-traffic controls. Turn on Voice Access (Windows) or Voice Control (Mac) and try saying each visible label — Search, Add to cart, Submit, Menu. If nothing happens, you have a real failure, not a theoretical one.

For the markup behind these names, our guide to ARIA labels and roles explains exactly how aria-label and aria-labelledby override visible text — the root cause of most 2.5.3 violations. Because this is a judgment call tools can’t make, thorough work pairs an accessibility audit with hands-on voice testing.

Why it matters legally

A label-in-name failure isn’t an abstract checklist miss — it’s a control a real person can’t operate, and that’s exactly what an auditor reproduces in writing. When a tester runs Dragon or Voice Control over your checkout and saying “click Place order” does nothing, the demand letter cites it not as a style nitpick but as a documented barrier to completing a transaction by voice. The W3C even bundles this exact defect — a visible label that the accessible name doesn’t carry — into a single combined failure, F111, which trips 1.3.1, 2.5.3, and 4.1.2 at once, so one bad aria-label can surface as three separate findings in a report.

The defect is also everywhere, which is why it draws fire. The 2026 WebAIM Million found empty or unlabeled buttons on 30.6% of home pages and empty links on 46.3% — and the next tier of failures, where a control has a name but the name doesn’t match the visible word, is precisely the harder-to-detect 2.5.3 case that automated scans miss and human testers flag by hand. Litigation tracks that prevalence: plaintiffs filed 4,187 website accessibility lawsuits in 2024 per the UsableNet 2024 Year-End Report, and inaccessible interactive controls are a recurring root cause across them. Because 2.5.3 sits at Level A — the conformance tier courts and the DOJ treat as the baseline for an accessible site under ADA Title III — a control that’s mute to voice input is one of the easiest violations for a plaintiff’s expert to demonstrate live.

This is general information about accessibility litigation, not legal advice; for your specific exposure, consult a qualified attorney.

The UsableNet report also found over 1,000 businesses were sued in 2024 despite having an accessibility widget installed — and label-in-name is precisely the failure overlays cannot touch. A toggle can recolor your page or inject a focus ring, but it does not rewrite the accessible names buried in your markup: a button that reads “Go” but is named “Find in this site” still fails voice control after you bolt on the widget, because that aria-label lives in your own code, not the overlay’s. Curbcut is deliberately anti-overlay: we correct the actual aria-label, aria-labelledby, and value attributes so the default control answers to its visible label for everyone, and we document that conformance in a VPAT.

Fixing it for good

The fastest fixes are usually deletions — remove the unnecessary aria-label and let the visible text be the accessible name. Where you need extra context, append it after the visible label or move it to aria-describedby. Then voice-test the result. If you’d rather not crawl every button and input by hand, start with a free scan and we’ll show you exactly which controls a voice-control user can’t reach — and our team, [EXPERT_NAME] and [AGENCY_NAME], will fix the names in your code.