2.5.3 Label in Name

What this rule means

WCAG 2.5.3 requires that the accessible name (the name exposed to assistive technology) of a user interface component contains the visible text label as a substring. When a button displays "Search" visually, its accessible name must include the word "Search". The accessible name can be longer, but the visible text must appear within it.

This criterion ensures that voice control users can activate controls by speaking the visible label. If the visible label says "Submit" but the accessible name is "Send form data", a user saying "Click Submit" will not find a match.

Why it matters

Speech recognition users interact with web pages by speaking the names of visible controls. When the accessible name does not match the visible label, these users cannot reliably activate controls. They see a button labeled "Search" and say "Click Search", but the command fails because the accessible name is something different.

This criterion also helps users of screen readers who can see the screen. If the visible label says "Continue" but the screen reader announces "Proceed to next step", sighted screen reader users become confused because what they hear does not match what they see.

Related axe-core rules

While axe-core does not have a specific rule mapped to 2.5.3, the label-content-name-mismatch rule in some implementations checks that the accessible name of elements with visible text includes that text. Manual verification is still recommended.

How to test

1. Identify all interactive controls with visible text labels (buttons, links, form inputs with labels).
2. Use a browser accessibility inspector (Chrome DevTools Accessibility pane) to read the computed accessible name.
3. Verify the visible text appears within the accessible name string.
4. Test with a speech recognition tool (Dragon NaturallySpeaking, Voice Control on macOS/iOS) by speaking the visible label.
5. Check that aria-label or aria-labelledby values include the visible text, not replace it entirely.

How to fix

Ensure the accessible name includes the visible text. Below are common patterns.

Button labels — bad practice

<!-- Visible text is "Search" but accessible name is "Find items" -->
<button aria-label="Find items">Search</button>

<!-- Visible text is "Close" but accessible name is "Dismiss dialog" -->
<button aria-label="Dismiss dialog">
  <span>Close</span>
</button>

Button labels — good practice

<!-- Accessible name matches visible text -->
<button>Search</button>

<!-- Accessible name includes visible text -->
<button aria-label="Search products">Search</button>

<!-- Close button with matching accessible name -->
<button aria-label="Close dialog">
  <span>Close</span>
</button>

Form input labels

<!-- Bad: aria-label does not contain visible label text -->
<label for="email">Email address</label>
<input id="email" aria-label="Enter your electronic mail">

<!-- Good: no conflicting aria-label, native label is used -->
<label for="email">Email address</label>
<input id="email">

<!-- Good: aria-label contains the visible label text -->
<label for="email">Email address</label>
<input id="email" aria-label="Email address (required)">

Common mistakes

• Using aria-label that completely replaces visible text with different wording.
• Providing an aria-labelledby that points to hidden text instead of the visible label.
• Adding a title attribute with different text than the visible label, which overrides the accessible name in some browsers.
• Using CSS to visually display text that differs from the DOM text content (e.g., text-transform or ::before pseudo-elements that change the perceived label).
• Icon buttons where aria-label uses terminology different from any adjacent visible tooltip or text.