Accessible name must contain the visible label text
Rule
label-content-name-mismatch· Forms · impact serious · Static + live
Why it matters
Speech-input users activate a control by speaking its visible label. If the accessible name (e.g. an aria-label) omits that visible text, the spoken command fails even though the label is right there on screen.
How to fix
Either remove the aria-label / aria-labelledby so the name comes from the visible text, or keep it and put the visible words inside it, ideally first ("No, thanks – close without accepting cookies"). Extra context for screen-reader users belongs in aria-describedby, which is not part of the name. Case and punctuation are ignored in the comparison. Hiding the visible text with aria-hidden silences this check but helps no one: speech-input users still see the words on screen and say them.
Example
<button aria-label="Submit form">Send</button>
<button aria-label="Send message">Send</button>
Example
<a href="/next" aria-label="Forward">Continue reading</a>
<button type="button" aria-label="Close"><span aria-hidden="true">×</span></button>
Example
<div role="tab" aria-label="Home">Dashboard</div>
<div role="tab" aria-label="Dashboard overview">Dashboard</div>
Named-from-content widgets (tabs, menu items, custom checkboxes/switches) are covered too — the aria-label must contain the visible text a speech user would say.
Example
<button aria-label="Close without accepting cookies">No, thanks</button>
<button aria-label="No, thanks – close without accepting cookies">No, thanks</button>
The aria-label may add context as long as the words on screen are in it — or drop the aria-label and move the extra context to aria-describedby.
WCAG success criteria
2.5.3 Label in Name — Level A
A control’s accessible name must contain its visible label text, so speech-input users can activate it by name.
Standards
This rule contributes to the following standards:
WCAG A EN 301 549
| Standard | Criteria |
|---|---|
| EN 301 549 | 9.2.5.3 |