2.5.3 Label in Name
- Level A
- Operable
- Since WCAG 2.1
Summary
Speech input users operate an interface by saying what they see. If a button visibly says "Search", the user says "click Search", and the software matches that phrase against the control's accessible name. When the accessible name is something else entirely, say "Find products", the command silently fails and the user is left guessing at invisible vocabulary. This criterion closes that gap: for any component whose label includes text or images of text, the accessible name must contain that visible text.
The same mismatch harms screen reader users working alongside sighted colleagues. Documentation, training, and phone support all refer to controls by their visible labels; a screen reader user who hears "Send form" cannot find the "Submit" button everyone else is describing. The scope is deliberately narrow: the criterion only applies where a component has a visible text label (including images of text). Icon-only controls have no visible text to match, so they are out of scope here and are graded under other criteria. Introduced in WCAG 2.1 at Level A, this is one of the cheapest criteria to fix and one of the most disruptive to fail.
Official wording
For user interface components with labels that include text or images of text, the name contains the text that is presented visually.
EN 301 549 mapping
- Web pages
- Clause 9.2.5.3
- Software and native apps
- Clause 11.2.5.3
- Closed functionality (kiosks, terminals)
On systems closed to screen readers, the standard recommends (does not require) meeting clause 5.1.3.3 on auditory output correlation.
Clause 9.2.5.3 applies this criterion to web pages unchanged and clause 11.2.5.3 applies it to software that supports assistive technologies. On closed systems only a recommendation applies, so it cannot be reported as a mandatory failure there.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
The classic failure is an aria-label overriding visible text. A button renders "Search" but carries aria-label="Find products", usually because someone wanted to give screen reader users "better" wording. The accessible name computation makes this inevitable: aria-labelledby wins first, then aria-label, then the element's own content (or an associated <label>), with title and placeholder as fallbacks. Any ARIA naming attribute on an element that already has visible text replaces that text in the name, so it must repeat the visible label if it is used at all.
Icon plus text buttons are the second hotspot. A "Download" button gains a decorative icon, a developer adds aria-label="Save file to device" for the icon, and the visible word "Download" vanishes from the name. The icon should be hidden from assistive technology instead, leaving the text to name the control.
Test through the accessibility tree, not the markup. Browser developer tools show the computed name for each element; compare it against the text painted on screen. The name must contain the visible label as a complete string of words (differences in case and punctuation are generally tolerated, split or reordered words are not). Best practice is for the name to start with the visible text, because some speech tools match commands from the beginning of the name; note in reports that this is best practice, not the requirement. "Search products" passes for a visible "Search" whether or not it leads, as long as the phrase is contained intact.
iOS
On iOS the failure pattern is an accessibilityLabel diverging from the visible title. A UIButton titled "Continue" is given accessibilityLabel = "Next step", and a Voice Control user saying "tap Continue" gets nothing. VoiceOver users hear a name that matches no visible control, which matters the moment anyone describes the screen to them.
Localisation drift is a distinctly mobile version of the same defect. The visible title is pulled from the strings catalogue and evolves with copy changes, while a hardcoded or separately keyed accessibilityLabel stays frozen on old wording, or worse, in another language. Any audit of a localised app should sample screens in more than one locale, because a label and name that match in English can diverge in German.
Test with Accessibility Inspector, comparing each control's label attribute against the text rendered on screen. A faster device-level sweep is Voice Control itself: enable it and turn on "Show Names", which overlays every control with the name Voice Control will respond to. Any overlay that does not contain the visible text on the control is a finding you can screenshot as evidence.
Android
On Android the equivalent mistake is setting contentDescription on a control that already displays text. For a text button, contentDescription is almost always unnecessary and actively harmful: it replaces the visible text in the accessible name, so a button reading "Add to basket" with contentDescription = "Purchase item" breaks Voice Access commands and misleads TalkBack users. The rule of thumb for auditors: a contentDescription on anything with visible text deserves scrutiny; it must contain that text or it should not be there.
In Jetpack Compose the same applies to a semantics contentDescription set over composables containing Text. Compose derives the name from the text content by default, which passes automatically; an explicit override reintroduces the divergence risk.
Test by comparing the announced name against the rendered text. Turn on the screen reader and swipe through the screen, or use the platform's accessibility tooling to inspect each node's name. Voice Access provides the same practical check as Voice Control on iOS: try activating controls by saying their visible labels, and anything that needs different wording is a failure candidate.
Pass and fail examples
Passes:
- A visible "Search" button with
aria-label="Search products": the name contains the visible text intact, so it passes. - A "Download" button with a decorative icon hidden from assistive technology and no overriding label: the name comes from the visible text itself.
- An iOS button titled "Continue" with no custom
accessibilityLabel: the title supplies the name automatically.
Fails:
- A visible "Submit" button with an accessible name of "Send form": the name does not contain the visible text, and "click Submit" fails for speech input users.
- An iOS button titled "Continue" with
accessibilityLabel = "Next step". - An Android text button reading "Add to basket" with
contentDescription = "Purchase item". - A visible "Sign up" button whose accessible name reorders the words as "up to sign": the label must appear as an intact string of words; scattered fragments do not count.
Not a fail under this criterion:
- An icon-only button (a magnifying glass with no text): there is no visible text label, so this criterion does not apply. Whether the icon has an appropriate name at all is graded under name quality instead.
- An input whose only visible cue is placeholder text is still in scope: the W3C's understanding material says placeholder text "may be a candidate for Label in Name" where no other visible label exists, and WCAG's definition of a label is any text presented to identify the component. Where the placeholder is the only visible identifier, treat it as the label and grade a name that fails to contain it as a fail; the missing proper label is a separate finding under other criteria.
- A name that adds context around the visible text ("Read more, pricing article"): extra words are fine so long as the visible text survives intact.
Commonly confused with
- Icon-only controls. No visible text means no Label in Name question. A missing or poor name on an icon button belongs to 1.1.1 Non-text Content and 4.1.2 Name, Role, Value. Citing 2.5.3 against an icon-only button is the most common misfiling in practice.
- No programmatic name at all. If the control has a visible label but no accessible name whatsoever, that is 4.1.2 Name, Role, Value; if there is no visible label where one is needed, that is 3.3.2 Labels or Instructions. 2.5.3 is specifically about a mismatch between two things that both exist.
- Label quality. "This button is labelled 'Click here' and that is unhelpful" is a descriptive quality finding under 2.4.6 Headings and Labels. 2.5.3 does not judge whether the label is good, only whether the name contains it.
- Contains versus equals. The requirement is containment, not an exact match. Auditors who fail every name that adds words beyond the visible label are grading a stricter rule than the one that exists.
How AUDITSU tests this
AUDITSU's audit walkthrough puts Label in Name into the per-screen checks: for each screen you review, the walkthrough asks you to compare the announced or computed name of every control carrying a visible text label against the text actually rendered, and to record a pass, fail, or not applicable result with evidence attached. Because the comparison is a straight string check, findings are unambiguous and land in your report tied to the exact screen and control, with the mismatched pair quoted.
The EN 301 549 mapping for this criterion is applied automatically to web and software audits. One nuance the platform reflects: on closed systems, where assistive technology cannot be attached, only a recommendation applies, so a mismatch there cannot be recorded as a mandatory failure and is graded as advisory instead.
For the full guided workflow, see the audit platform.