Success Criteria

WCAG 2.5.3 Label in Name

Success Criterion 2.5.3 requires that for user interface components with both a visible text label and an accessible name, the accessible name contains the visible label text. It's a Level A criterion under Guideline 2.5 (Input Modalities), added in WCAG 2.1.

Who this protects, and why the mismatch matters

Speech-input software (Dragon NaturallySpeaking, Voice Control, Voice Access) lets users operate an interface by saying the visible label of what they want to interact with — "click Submit," "tap Search." This only works if the control's accessible name (what assistive technology, including speech-recognition software, actually reads) matches or contains what's visually printed on the button. If a button visually says "Submit" but its accessible name (set via aria-label) is actually "Send form data," a voice user saying "click Submit" won't match anything the software recognizes — the command silently fails.

The common cause: overriding accessible names with unrelated text

<!-- Visible text says "Search" but the accessible name is completely different -->
<button aria-label="Find items in our catalog">Search</button>

A screen reader user hears "Find items in our catalog," a sighted user sees "Search," and a voice-control user saying "click Search" gets no match at all — three different, disconnected experiences of the same button.

The fix

Make sure any aria-label (or aria-labelledby) applied to an element that also has visible text either matches that visible text exactly, or at minimum contains it as a substring:

<!-- Accessible name (aria-label) contains the visible text -->
<button aria-label="Search our catalog">Search</button>

Why this is often an easy, avoidable mistake

This violation usually happens when a developer adds an aria-label to provide additional context, without realizing it fully replaces rather than supplements the accessible name computed from visible text. If the goal is just extra context beyond the visible label, keeping the visible text as the start of the aria-label (as in the fix above) satisfies both the extra-context goal and this criterion at once.

Official references

Common questions

What is WCAG 2.5.3?
A Level A criterion: for controls with a visible text label, the accessible name must include that visible text, ideally matching it and starting with it.
Why does Label in Name matter?
Speech-recognition users say the visible label to activate a control; if the accessible name differs, the voice command fails.
What is a common violation?
A button showing 'Search' but with aria-label='Submit query' — the visible word 'Search' isn't in the accessible name, breaking voice control.

Want to see how your own site scores?

Run a free accessibility scan