WCAG 2.5.3 Label in Name

Success criterion 2.5.3 makes voice control work. People who cannot use a mouse or keyboard often operate a site by saying the text they see — "click Add to cart". That only works if the control's accessible name (what software knows it as) contains the visible words. It also keeps screen reader users and sighted colleagues talking about the same thing. It is level A and part of EN 301 549 (clause 9.2.5.3).

What the criterion requires

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

• The "label" is the visible text that identifies the control — the button text, the link text, or the text next to a form field.
• The "name" is the accessible name exposed to assistive technology, which may come from the text content, a <label>, aria-label or aria-labelledby.
• W3C's best practice: put the visible label text at the start of the name. Extra words after it are fine.

Controls without visible text (an icon-only button) are not covered by this criterion, though they still need a name under 4.1.2.

Typical failures on an online shop

• a button that reads "Buy" with aria-label="Purchase item";
• a "Search" button whose aria-label is "Submit query";
• a field visibly labelled "Postcode" while its aria-label says "ZIP";
• a link "Shop now" with aria-label="Go to summer collection";
• translated storefronts where the visible text is translated but the hard-coded aria-label stays in English.

How to check it

Automated: our checker compares the visible text of controls with their accessible names and flags names that do not contain the visible text (label content name mismatch rule). The rule is marked experimental in axe-core and cannot handle every case (for example text in images or icons with symbols), so review its findings and spot-check by hand.

By hand: inspect buttons, links and fields with the browser's accessibility panel and compare "Name" with what you see. Or use voice control (Voice Control on macOS and iOS, Voice Access on Android) and say "click" followed by the visible text of important controls.

How to fix it

• Prefer visible text as the name; add aria-label only when it adds something.
• If you use aria-label, start it with the exact visible text: aria-label="Add to cart – Linen shirt".
• Connect form fields to their visible label with <label for> instead of a separate aria-label.
• Translate aria-label values together with the visible text.

Related criteria

• 2.4.6 Headings and Labels — labels must describe the purpose.
• 2.4.4 Link Purpose (In Context) — link text must say where it leads.
• 2.1.4 Character Key Shortcuts — another criterion for speech input users.

Frequently asked questions

What does WCAG 2.5.3 Label in Name require?

For controls whose label includes text or images of text, the accessible name must contain the text that is shown on screen. W3C recommends putting that text at the start of the name.

Is aria-label a problem for 2.5.3?

Only when it replaces the visible text with different words. A button showing "Buy" with aria-label="Purchase this item" fails; aria-label="Buy now – Linen shirt" contains the visible text and passes.

Who benefits from label in name?

Mainly people who use speech recognition: they say "click Add to cart", and it only works if the accessible name contains those words. Screen reader users also hear a name that matches what sighted users see.