2.5.3 Label in Name

Description

For user interface components that have labels that include text or images of text, the accessible name must contain the visible label text. This criterion ensures that when a user sees a button that says "Submit Order" and uses speech recognition software to activate it by speaking "click Submit Order," the spoken command will match the accessible name of the control. Accessible names that differ from visible labels break the connection between what the user sees and what their assistive technology recognizes.

How To Test

1. Identify all interactive components with visible text labels: buttons, links, form inputs with visible labels, and custom controls.
2. Inspect each component's accessible name using browser DevTools Accessibility panel, or an accessibility inspector tool.
3. Compare the accessible name to the visible label text of the component.
4. Verify that the visible label text is contained within the accessible name (the accessible name may include additional words, but must include the visible label).
5. Test with a speech recognition tool such as Dragon NaturallySpeaking: say "click [visible label text]" and verify the correct control is activated.
6. Look for aria-label attributes that completely replace visible text with different wording - these are common sources of failures.

Testing Tools

• axe DevTools — Scan for missing link text, label associations, and heading structure issues.
• NVDA — Navigate links and form fields using Tab and arrow keys to verify purpose is announced clearly.
• VoiceOver (macOS) — Alternative screen reader to test link names, form labels, and heading hierarchy.

Demo

Fail Explanation

A failure occurs when the accessible name of a control (set via aria-label, aria-labelledby, or the element's content) does not include the visible text of the control. For example, a button that visually reads "Submit" but has aria-label="Confirm and place order" will fail because a speech recognition user saying "click Submit" will not find a match. Similarly, a button labelled visually as "Next" but overridden with an aria-label that does not contain the word "Next" breaks the label-in-name requirement.

Pass Explanation

A passing implementation ensures the accessible name either exactly matches the visible label text or begins with or includes the visible label text. The accessible name may contain additional information beyond the visible text (e.g., "Submit - Place your order now") as long as it starts with or contains the visible text "Submit." The safest approach is to use native HTML labeling mechanisms (<label> for form controls, button text content for <button> elements) which automatically derive the accessible name from visible text, avoiding mismatches entirely.

WCAG Techniques

• Failure: F96 (accessible name includes no visible text label)
• Success Techniques: H44 (using label with form controls), H65 (using label element to associate text with form input), ARIA14 (using aria-label to provide accessible names)

Notes

This criterion is particularly important for speech recognition users, who activate controls by speaking their visible labels. It does not prohibit accessible names that are longer than the visible label - augmenting the accessible name with additional context is fine as long as the visible text is present within it. Acronyms and abbreviations should be treated carefully: if the visible label says "CTA" and the accessible name says "Call to Action," neither contains the other verbatim.

Techniques

WCAG techniques used in this demo: G208, F96

Suggested Solutions & References

Curated from 6 real-world audit findings and official WCAG guidance.

• Understanding SC 2.5.3: Label in Name
• Technique G208: Accessible name includes visible label text
• Failure F96: Accessible name does not contain visible label