Understanding WCAG 2.5.3 Label in Name.
What is it?
WCAG 2.5.3 Label in Name is a Level A criterion.
When a control has a visible text label, its accessible name (the text assistive technology reads aloud or listens for) has to contain that visible label.
What you see and what assistive tech hears should match.
Why it matters
Voice control users say what they see. “Click Search.” “Tap Submit.” The software looks for the control whose accessible name matches the words spoken.
If the button says “Search” but its accessible name is “Submit,” the command finds nothing and the button just sits there.
Who it affects
People with:
- Mobility or dexterity challenges that depend on voice control (Dragon, Voice Control, Voice Access)
- Low vision, who might use screen readers and magnifiers together
- Cognitive disabilities, who might also use screen readers and depend on consistent naming
Common failures
1. An aria-label that rewords the label. The button reads “Send” but the accessible name is “Submit form.” The spoken command “click Send” finds nothing.
<button aria-label="Submit form">Send</button>
2. A “more descriptive” name that excludes the visible words. A button reads “Add to cart” but its accessible name is “Add blue car to your shopping bag.” It reads nicely for a screen reader, but the visible words are gone from the name.
<button aria-label="Add blue car to your shopping bag">Add to cart</button>
Solution
Let the visible text be the name. The simplest fix is less code. A button’s text content becomes its accessible name automatically. No aria-label needed.
<button>Search</button>
When you add context, start with the visible label. When the accessible name starts with the visible words, voice control matches from the start. Keep the visible label first, then add the extra context in visually-hidden text.
<a href="/pricing">
Read more <span class="sr-only">about our pricing</span>
</a>
Match the words, not just the meaning. “Get in Touch” and “Contact Us” mean the same thing to you. To a voice user they are two different commands. Spoken words and visible labels should be identical.
Understand what aria-label does. aria-label and aria-labelledby replace the accessible name. They don’t add to it. If a control already has visible text, you usually don’t need either one.
How to test
- Open the accessibility pane in DevTools. For each control, check the Computed Name and confirm it contains the exact visible text.
- Turn on voice control and operate the site by saying what you see, like “Click Search.” Check that the names match.
- Scan with AAArdvark. It flags controls whose accessible name doesn’t match the visible label.
A note on exact matches
2.5.3 only requires the name to contain the visible label. But matching exactly, with the label at the start, is the safer bet.
Speech input works most reliably when the accessible name and the visible text are the same words in the same order.
Closing
The simplest accessible name is the one you can already see.
When the label and the name match, everyone points at the same button, whether they tap it, read it, or say it out loud.
Learn more
Read the full breakdown: a20y.com/wcag-plain-english/2-5-3-label-in-name/
Want more clear and actionable WCAG breakdowns? Check out wcagInPlainEnglish.com