2.5.3 Label in Name

1. What is the goal of this criterion?

Imagine trying to activate a “Submit” button by voice – and nothing happens, even though the word is right there on the screen. Frustrating, right? Voice control users run into this again and again when visible labels don’t match the names in the code.

The goal of WCAG Success Criterion 2.5.3 is clear: what people see should be what the technology understands. Specifically, the visible text of a control must be part of its accessible name.

2. What exactly does it require?

This criterion covers all user interface components with labels made of text or images of text:

The accessible name contains the visually presented text. The two don’t have to be identical – but the visible text has to appear in the name, ideally as a continuous phrase in the same order.

Best practice from the normative text: the visible text comes first in the accessible name. If a button says “Buy”, then “Buy: Product XY for €29.99” is ideal. “Product XY – buy now” also meets the criterion because “buy” is included, but it’s less robust.

What it doesn’t cover: the criterion only applies to controls with a visible text label. Icon-only buttons without text are not covered – they still need an accessible name under Name, Role, Value.

A practical example: a “Sign in” button is clearly labeled. A voice control user says “Click Sign in” – and expects exactly that button to respond. But if the code says aria-label="Log in", the voice command goes nowhere.

3. Why does it matter for accessibility?

Imagine navigating a website by voice, and half of the visible buttons don’t respond to your commands. Or you use a screen reader and hear completely different names from the ones you see on screen.

Matching labels improve accessibility because they:

• let voice control users activate elements by what they see – a “Send” button responds to “Send”
• help screen reader users who can also see – they hear what they read and can talk about the interface more easily with sighted people
• relieve people with cognitive disabilities, who don’t have to remember different commands
• create consistency across input methods – mouse, keyboard, voice or touch

And: interaction becomes more predictable for everyone, including people who only use voice control now and then.

4. How to meet the criterion

The good news: if you write semantic HTML, this usually happens automatically. Here are the key tips:

Use semantic HTML elements:

• <button>Submit</button> just works.
• <label for="name">Name</label> <input id="name"> creates the correct association.
• <a href="/">Home</a> needs no extra attributes.

Be careful with ARIA:

• If you use aria-label, it must contain the visible text.
• Prefer aria-labelledby to point to the visible label.
• Skip aria-label when a suitable visible label already exists.

<!-- Good: visible text at the start of the name -->
<button aria-label="Buy: Alpine hiking boot">Buy</button>

<!-- Fail: visible text missing from the name -->
<button aria-label="Add to cart">Buy</button>

Mind the order:

• The visible text should come first in the accessible name.
• Extra text may follow, but the visible text shouldn’t be split up or rearranged.

Testing:

• Browser developer tools show the computed accessible name in the “Accessibility” panel.
• Test with a screen reader, such as the free NVDA.
• Test with voice control: Voice Access on Windows 11, Voice Control on macOS and iOS, or Voice Access on Android.

Common pitfalls:

• Placeholder text is not a substitute for a label.
• For images of text, the alt text must contain the visible text.
• Check symbols that might be read as text carefully – when in doubt, add a real text label.

5. Why this criterion matters for businesses

2.5.3 is part of WCAG 2.1 Level A and therefore part of EN 301 549, the standard behind the European Accessibility Act. In Germany, the EAA is implemented by the BFSG, which has applied since 28 June 2025 to online shops, banking services and other consumer services, among others. Public sector bodies must meet it as well. This section is general information, not legal advice.

1. Reach more people

Voice control is now built into all major operating systems. Besides people with motor disabilities, it’s used by people with temporary injuries or whose hands are busy. Matching labels make your website work for all of them.

2. Low effort, big impact

Often all it takes is removing unnecessary or mismatched aria-label attributes. That’s one of the cheapest improvements there is – and it avoids a classic audit finding.

3. Better quality overall

When visible and programmatic labels match, automated tests are easier to write, translations stay consistent and quality assurance gets simpler.

6. The success criterion in the W3C’s words

Success Criterion 2.5.3 Label in Name (Level A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Note: A best practice is to have the text of the label at the start of the name.

In short: for controls with a visible text label, the accessible name must contain that text – ideally right at the start.