WCAG 2.5.3 Label in Name

What it asks

People who control a computer by voice say the name of the thing they want: "click Submit", "click Add to basket". The software matches what they said against each control’s accessible name, the name that screen readers also read out. If the words on the screen say "Submit" but the accessible name says "Send form", the command fails. The person can see the button, say its name, and nothing happens, and they have no way of knowing why.

The rule says the accessible name must contain the visible text. It need not be identical. "Submit" visible and "Submit your application" as the name passes, because the visible words appear in the name. The W3C recommends putting the visible text at the start of the name, because some voice software matches on the start.

It applies to controls whose label includes text or images of text: buttons, links, form fields with visible labels, tabs, menu items. It does not apply to controls labelled only with an icon, because there is no visible text to match. And it is about the words, not the punctuation or capitalisation.

The usual cause of failure is an aria-label that overrides the visible text with something different, often added with good intentions to give a screen reader more context.

Its official name is success criterion 2.5.3 Label in Name, at Level A. It was added in WCAG 2.2, under guideline 2.5 Input Modalities and the principle Operable. The W3C’s normative text says, in part:

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

From WCAG 2.2, W3C. Full explanation: Understanding 2.5.3 Label in Name.

Who it helps

People who use speech recognition to operate the computer, who name controls by the words they can see. People who use a screen reader with some sight, who read a label on screen and hear a different one spoken, and who are left wondering whether they are on the right control.

What passes and what fails

These pass

• A button showing "Submit" whose accessible name is "Submit".
• A link showing "Read more" with aria-label="Read more about our pricing". The visible text is in the name, at the start.
• A button with a search icon and the visible word "Search", whose name is "Search".
• A button whose only label is an icon with no text. The criterion does not apply to it.
• A visible label "Email" on a field whose accessible name is "Email address".

These fail

• A button showing "Submit" with aria-label="Send form".
• A button showing an icon and the word "Save", with an aria-label that describes only the icon, such as "Floppy disk".
• A long visible label such as "Download the annual report" shortened in aria-label to "Download".
• A link showing "Contact us" with aria-label="Get in touch".
• A tab showing "Settings" named "Preferences" in the accessibility tree.

Text that is visually hidden but present in the markup, such as "Read more" followed by a hidden "about pricing", is part of the name and does not cause a failure. Text in an image counts as visible text, so a button whose image reads "Buy now" needs "Buy now" in its name.

How to test it by hand

1. Find every control with visible text: buttons, links, tabs, menu items and fields with visible labels.
2. For each one, read its accessible name in the browser’s accessibility inspector, or with a screen reader.
3. Check that the visible words appear in the name, in the same order. Ideally they come first.
4. Pay particular attention to controls with aria-label or aria-labelledby, which is where mismatches live.
5. If you can, test with voice control software: say "click" followed by the visible text and see whether the right control responds.

What automated testing can decide

What a machine can decide

This is one of the few criteria that can be decided by code from start to finish. The visible text is in the rendered page. The accessible name is computed by the browser. Checking that the first appears inside the second, in order, is string comparison, and the W3C’s ACT rule for the criterion spells out exactly how to do it, including which roles it covers and how to treat hidden text, punctuation and case.

What it cannot

Little. The limits are at the edges. Text inside an image needs recognising before it can be compared. A label that is visually near a control without being its label, and a name built from several pieces of text, both need a look to be sure. And a tool only knows about the controls on the pages and states it reached.

How Dreven handles it

Dreven finds the labelled controls on your pages whose visible words may not be in their accessible name and shows you each one, with the visible text, the name, the element and the page.

A reviewer confirms each result from those two strings and signs the report.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 4.1.2 Name, Role, Value (Level A). Every control needs an accessible name in the first place.
• 1.1.1 Non-text Content (Level A). Text in an image needs a text alternative, and that alternative is what becomes the name.
• 2.4.6 Headings and Labels (Level AA). Labels must describe what the control does.
• 3.3.2 Labels or Instructions (Level A). Fields need visible labels or instructions.

Questions people ask

All WCAG 2.2 criteria, in plain words