WCAG 2.5.3 Label in Name: make the spoken name match the visible label

Who gets stuck when names and labels differ

Some people who can use neither a mouse nor a keyboard control a computer or phone by speech. They look at the screen and say the words on a control: "click Search", "tap Next". The software looks for a control whose accessible name matches. If the name is different, nothing happens, or the wrong control fires.

Screen reader users who have some sight meet the same mismatch from the other side: they hear one word and see another, and wonder whether they are on the right control. People with cognitive disabilities also benefit when the spoken and printed words agree.

What WCAG 2.5.3 asks for

It applies to user interface components with a label that includes text or images of text. That text has to appear inside the accessible name. W3C recommends going further and putting the visible text at the start of the name, because some voice software matches from the beginning.

• Case and punctuation do not matter much: a label "Name *" and a name "Name, required" pass.
• Extra words after the label are fine: "Read more" can be named "Read more about pricing".
• Icons are not text labels, so an icon-only button is outside this rule. It still needs a name, which 4.1.2 requires.
• Text near a control that is not acting as its label, such as a paragraph of instructions, does not count.

Label in name WCAG examples: pass or fail

Code: when aria-label hides the visible words

Most failures come from an aria-label added with good intentions. It replaces the button's own text in the accessibility tree.

<button aria-label="Add this item to your basket">
  Buy now
</button>

<button>
  Buy now<span class="visually-hidden">: Trail running shoes</span>
</button>

For form fields, a real label element tied to the input by for and id keeps the name and the visible label identical automatically. Our ARIA labels page explains when an aria-label is the right tool.

Testing for 2.5.3

1. Pick the controls with visible words: buttons, links, tabs, menu items and form fields.
2. Open the browser's accessibility inspector, select each one and compare its computed name with what is on screen.
3. Flag any control whose name leaves out the visible words, changes their order or spells them differently.
4. Turn on the voice control built into Windows, macOS, iOS or Android and try saying a few labels exactly as they appear.
5. Check translated pages too: a translated button text with an untranslated aria-label is a frequent failure.

Common causes and quick fixes

• Name copied from a design spec. The aria-label says what the designer called the button, not what it says on screen. Delete it.
• Marketing copy changed, code did not. The visible label was edited but the aria-label kept the old wording. Prefer no aria-label so there is only one place to edit.
• aria-labelledby pointing at the wrong element. The name comes from a heading instead of the field's own label. Point it at the label, or add the label's id first in the list.
• Placeholder used as a label. The visible hint and the hidden name drift apart. Use a real label.

Criteria that sit beside 2.5.3

This criterion builds on 4.1.2, which requires a name in the first place, and on 3.3.2, which requires visible labels on inputs. 2.4.6 asks that those labels describe their purpose, and the link purpose rule (2.4.4) often leads teams to add aria-labels to links, which is where 2.5.3 failures creep in. Read W3C's Understanding Label in Name for the intent, and tick it off in our WCAG checklist.