Label in Name
Where a control has a visible label made of text, its accessible name has to contain that text. Voice-control users activate what they can see by saying it, so a button reading Search whose name is 'Submit query' cannot be operated by saying 'click Search'. Three things narrow this usefully. It only applies where a visible text label exists, so an unlabelled icon button is a different rule's problem. Capitalisation and most punctuation are ignored, because speech software ignores them, so 'First Name' and a name of 'first name' agree. And text used as a symbol rather than as language is not a label at all, so the B on a bold button should be named Bold, and a greater-than sign standing in for an arrow should be named Next. Maths is the exception to that exception. A formula on a button carries meaning, and it belongs in the name exactly as written.
Why it matters
Voice control matches what a person says against a control's accessible name. When the visible label and the name disagree, a perfectly correct command lands on a control that, as far as the software is concerned, is not there. No error, no visible cause, and the words are printed right in front of them. There is a worse version of this. A name that does not match its label can act as a hidden command, so the user says one thing and activates something else entirely. And for people with cognitive difficulties who use speech, the cost is remembering a second name for every control, which is exactly the kind of load the interface should be carrying instead.
Who this rule protects
This affects voice-control users, whose spoken commands target the labels they can see, screen-reader users who hear one thing while a sighted colleague reads another, people using text-to-speech alongside the visible page, and people with cognitive difficulties who use speech and would otherwise memorise a second name for every control.
How to check it yourself
- Compare each control's visible text with its accessible name in the accessibility tree, and confirm the visible text appears inside the name. At the start of it is better, though the rule does not require it.
- Ignore case and punctuation when you compare. Speech software does, and so does the criterion.
- Decide which text is the label before you judge the name. The label is the adjacent text, meaning inside a button or a tab, immediately left of or above a text field, or immediately right of a checkbox. A heading, a set of instructions or a group name is not a label for this rule.
- Check controls whose only visible text is a placeholder. Where there is no other nearby text, that placeholder is a candidate label and belongs in the name.
- Check the parentheses. 'Name (required)' can carry an accessible name of just 'Name', and where it does, the required state has to be exposed in code some other way.
Failures we see most often
- A button that reads 'Buy now' and carries aria-label="Purchase product", so the command 'click Buy now' does nothing at all.
- A control with visible label text and no accessible name, which fails this rule, 1.3.1 and 4.1.2 in one go.
- Labels rewritten by a translator or a marketer while the aria-label stays behind, so the visible words and the spoken ones drift apart release by release.
- A formula button reading 11 times 3 equals 33 in symbols, named out in words instead, which no speech user is going to say that way.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Blind and screen reader userspeople who cannot see the screen
- Voice controlpeople who operate the page by speaking to it
- Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it
How this one is tested
We list 2 ACT rules against 2.5.3. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.
- Form field has non-empty accessible nameA tool can check this
- Visible label is part of accessible nameNothing implements this yet
How to fix it
- Let the visible text be the accessible name, and skip aria-label wherever real visible text already exists. That is one deletion and it fixes the whole class.
- Where you need extra context for screen-reader users, put it in aria-describedby rather than in the name. It is announced right after the name, so screen-reader users get the context and speech users keep the command.
- If you must extend the name, add to the end of the label rather than replacing it, such as aria-label="Buy now, Gold twist ring".
- Name symbol buttons after their function. The B is Bold, the I is Italic and the chevron is Next, because none of those characters is a word anybody would say out loud.
- Use the right character inside a formula. Three different multiplication symbols all read the same to a sighted user, and they do not all match what speech software hears.
Step-by-step fix guides (5)
Passes vs. fails
Passes
The accessible name reads 'Order your audit', matching the visible text, and the extra detail rides in a description instead.
Fails
The visible text reads 'Order your audit' and the accessible name reads 'Start purchase flow', so a voice user saying what they can see gets nothing.
In audits and lawsuits
This is usually a well-meant failure. A team adds a fuller aria-label for screen readers and breaks voice input in the same commit. Both aria-label and aria-labelledby override the visible text in the name computation, even when that text is properly associated with the control, so the safest advice is to leave the visible text as the name and put the extra context somewhere else. Reading an automated result needs care too. The published rule for this covers thirteen widget roles, only fires where an aria-label or aria-labelledby is present, and cannot read an image of text, so a clean automated pass covers a slice of the criterion rather than the criterion. Our own tooling compares visible text against accessible names across every page we audit.