WCAG 2.5.3: Label in Name

Who this helps

Picture the failure from the user’s side: the page shows a button labelled “Send”. The user says “Click Send.” Nothing happens, because a developer set aria-label="Submit message". The user tries again, louder. Then they fall back to a numbered grid overlay, speaking coordinates instead of words. A one-attribute mistake turned a two-second task into a workaround.

Accessible name vs. visible label

Every interactive component has an accessible name computed by the browser from, in priority order: aria-labelledby, then aria-label, then the associated <label> or the element’s own text content (with title and placeholder as last resorts. The visible label is whatever text a sighted user reads on or next to the control.

When you write no ARIA at all, the accessible name is the visible text, and 2.5.3 passes automatically. The criterion only bites when the two diverge — almost always because aria-label or aria-labelledby overrides the visible text with different words.

• →The name may extend the label. Visible “Read more” with accessible name “Read more about pricing” passes — the visible words are all there, at the start.
• →The name may not replace the label. Visible “Send” with accessible name “Submit message” fails — the word the user would speak is missing.
• →Images of text count as visible labels. A button rendered as an image reading “Checkout” must have “Checkout” in its alt text / accessible name.
• →Icon-only controls are out of scope — no visible text, nothing to match. They still need a sensible accessible name under 4.1.2 Name, Role, Value.

Pass and fail examples

Code examples

The classic aria-label mismatch

If you add an aria-label to a control that already shows text, start it with the visible words — or better, do not add one at all.

<!-- ✗ Fails: name "Submit message" does not contain visible "Send" -->
<button aria-label="Submit message">Send</button>

<!-- ✓ Passes: no override — the name is the visible text -->
<button>Send</button>

<!-- ✓ Passes: name extends the label, visible text first -->
<button aria-label="Send message to support">Send</button>

Extending repeated links accessibly (React)

The common pattern of disambiguating “Read more” links is fine — as long as the visible text stays at the start of the name.

// ✗ Fails: visible "Read more" is missing from the name
function ArticleCard({ title, href }) {
  return <a href={href} aria-label={"Full article: " + title}>Read more</a>
}

// ✓ Passes: name starts with the visible label, then adds context
function ArticleCard({ title, href }) {
  return <a href={href} aria-label={"Read more: " + title}>Read more</a>
}

// ✓ Also passes: visually hidden extension keeps the DOM text intact
function ArticleCard({ title, href }) {
  return (
    <a href={href}>
      Read more<span className="sr-only"> about {title}</span>
    </a>
  )
}

Form fields: keep label, name, and instructions aligned

<!-- ✗ Fails: visible label says "Work email", name says "E-mail address" -->
<label for="em">Work email</label>
<input id="em" type="email" aria-label="E-mail address" />

<!-- ✓ Passes: the <label> element is the accessible name — one source of truth -->
<label for="work-email">Work email</label>
<input id="work-email" type="email" autocomplete="email" />

Common failures

• ✗aria-label text written independently of the visible text — 'Go' on screen, 'Submit search query' in the name.
• ✗Localisation drift: the visible label gets translated or reworded during a redesign, but the hard-coded aria-label is never updated.
• ✗aria-labelledby pointing to a nearby heading or tooltip instead of the control's own visible label.
• ✗Adding context before the visible words ('Product page link: Read more') instead of after them — the label should be at the start of the name.
• ✗Image buttons or images of text whose alt attribute is a filename or marketing description rather than the words shown in the image.
• ✗Icon + text buttons where the accessible name is built from the icon's label only (e.g. name 'magnifier' for a button that visibly says 'Search').
• ✗Design systems that expose a label prop for the accessible name separate from children, letting the two drift apart unnoticed.

How to test for 2.5.3

1. 1

   Run an automated scan first

   axe DevTools and similar engines include a check (label-content-name-mismatch) that compares each control's visible text with its computed accessible name and flags names that omit the visible words. This catches most aria-label mismatches instantly.

2. 2

   Inspect computed names in DevTools

   For each control with visible text and any aria-label/aria-labelledby, select it and open the Accessibility pane (Chrome/Edge/Firefox). Confirm the 'Name' value contains the visible text, ideally at the start.

3. 3

   Test with real voice control

   Enable Voice Control on macOS/iOS or Voice Access on Windows/Android, or use Dragon if available. Speak 'Click <visible label>' for key controls — navigation, search, form submission. If the control does not activate, its name does not match.

4. 4

   Listen with a screen reader while looking at the screen

   Tab through interactive elements with NVDA or VoiceOver running. Whenever what you hear does not include the words you see on the control, you have found a 2.5.3 candidate.

5. 5

   Audit ARIA usage in the codebase

   Grep for aria-label and aria-labelledby on elements that also render visible text (buttons, links, labelled inputs). Each hit is a place where the name can drift from the label — verify or remove the override.

Then work through the rest of the WCAG 2.2 checklist — 2.5.3 pairs naturally with 2.4.6 Headings and Labels, which asks whether those same labels are descriptive.

Frequently asked questions