WCAG 2.5.3 Label in Name Explained in Plain English

2.5.3 Label in Name is the WCAG success criterion that says the name a control has in the code must include the words people can see on it. If a button says “Search”, its accessible name must contain “Search”. This matters most for voice control users, who say what they see, “Click Search”, to press a button. This guide explains WCAG 2.5.3 Label in Name in plain English, the common mistakes and how to test.

The official wording: “For user interface components with labels that include text or images of text, the name contains the text that is presented visually.” (W3C, WCAG 2.2)

What Is 2.5.3 Label in Name?

2.5.3 Label in Name is a Level A requirement under the Operable principle, in the guideline “Input Modalities”, added in WCAG 2.1. Every control has an accessible name that assistive technology announces and uses. Normally it comes from the visible text, so it matches. Problems start when developers add aria-label or aria-labelledby, which replace the visible text as the name, and write something different.

Why 2.5.3 Label in Name Matters

Voice control software, such as Voice Control on Mac and iPhone, Voice Access on Android and Dragon on Windows, lets people operate a page by speaking. They read a control’s visible label and say it. If the accessible name is different, the command does not match and nothing happens.

It matters for screen reader users who can see the screen too, such as people with low vision or dyslexia. If they hear “Find items” while looking at a button that says “Search”, the page feels inconsistent and confusing.

Who Is Affected by 2.5.3 Label in Name

• People who use voice control because of motor disabilities, repetitive strain injury or temporary injury
• Screen reader users who can also see the screen
• People with cognitive disabilities who rely on consistent labels

How to Meet 2.5.3 Label in Name

Let the visible text be the name

The simplest fix is to not override the name at all. A button with text, a link with text and an input with a label element all get their accessible name from that visible text automatically. Only add ARIA naming when you need to add information.

If you add words, include the visible text, ideally first

The W3C techniques G208, including the text of the visible label as part of the accessible name and G211, matching the accessible name to the visible label describe the fix. An accessible name that does not contain the visible label is failure F96.

<!-- Fails: name does not contain "Search" -->
<button aria-label="Find items">Search</button>

<!-- Passes: visible text first, extra context after -->
<button aria-label="Search products">Search</button>

<!-- Passes: visible text plus context from the page -->
<h3 id="tent">2-person tent</h3>
<button id="buy" aria-labelledby="buy tent">Buy now</button>

Watch for form labels that differ from placeholders

If a field has a visible label, the accessible name should come from that label. Do not label it with aria-label text that differs from what people see.

Ignore punctuation and capitalization

Matching is about the words. “Search” and “search” match, and so do “Next ›” and “Next”. Symbols that are not words, such as arrows, do not need to be in the name.

How to Test for 2.5.3 Label in Name

1. Inspect each control with your browser’s accessibility panel and compare the accessible name with the visible text.
2. Look for aria-label and aria-labelledby in your code. Each one is a place the name and label can drift apart.
3. Try voice control. Say “Click” followed by the visible text of buttons and links. Each should work.
4. Listen with a screen reader while looking at the screen. What you hear should match what you see.

Related Success Criteria

• 4.1.2 Name, Role, Value: every control has an accessible name and role.
• 2.4.4 Link Purpose (In Context): link text describes where links go.
• 3.3.2 Labels or Instructions: fields have visible labels.
• 2.4.6 Headings and Labels: labels describe their purpose.

Run a free WCAG scan to compare accessible names with visible labels on any page, then test with voice control.

Testing WCAG 2.5.3 With AccessBell

This criterion depends on meaning or context, so it needs a person to judge. AccessBell's report lists it for manual review rather than marking it pass or fail automatically, so it is not missed.

Run a free scan to spot issues on your own pages.

Frequently Asked Questions

What level is WCAG 2.5.3 Label in Name?

Level A. It was added in WCAG 2.1, so it applies to WCAG 2.1 and 2.2 targets.

What is an accessible name?

The name assistive technology uses for a control. It usually comes from the visible text or label, but aria-label and aria-labelledby replace it. 2.5.3 Label in Name is about making sure that replacement still contains the visible words.

Does the accessible name have to match the label exactly?

No. It must contain the visible text. Extra words are allowed, and the W3C recommends putting the visible text first, so "Buy now, 2-person tent" is better than "2-person tent, buy now".

Does 2.5.3 apply to icon-only buttons?

Not directly. It applies to controls whose label includes text or images of text. An icon-only button has no visible text to match, though it still needs an accessible name under 4.1.2 Name, Role, Value.

Can AccessBell test WCAG 2.5.3 automatically?

Not fully. This criterion needs a person to judge, so AccessBell's report lists it for manual review rather than marking it pass or fail on its own.

Sources

• W3C: Understanding 2.5.3 Label in Name (opens in a new tab)
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab)

This page explains a technical standard and is not legal advice. See our disclaimer.