Goal
Ensure voice control users can activate controls using visible labels.
Success Criterion · WCAG 2.5.3
Label in Name
For user interface components with labels that include text or images of text, the name contains the text that is presented visually.
Level AWCAG 2.1Operable2.5 · Input Modalities
Copy button ready
What to do
Make sure accessible names include the visible label text (or match it) for controls with text labels.
Why it matters
Speech input users often say the visible label; if the accessible name differs, activation can fail.
Success criterion
What WCAG 2.5.3 requires
Summarized directly from the official Understanding document so teams can quote the requirement accurately.
For user interface components with labels that include text or images of text, the name contains the text that is presented visually.
Intent
Why WCAG created this requirement
- Visible label text should be included in the programmatic name.
- Mismatch breaks voice control and confuses screen reader users.
- Applies to buttons, links, inputs, and other UI components with visible text labels.
Benefits
Who gains when you pass
- Speech recognition users can activate controls by saying the visible label.
- Screen reader users experience consistent naming that matches what sighted users see.
- All users benefit from consistent UI labeling.
Why it matters
User impact when this criterion fails
Summaries drawn from the Understanding document help you socialize impact statements with product stakeholders.
Voice users may be unable to click “Download” if the accessible name is “Get file.”
Users may mistrust the UI when announced names don’t match visible labels.
Overview
If a button says “Submit,” the accessible name should include “Submit.” This helps speech recognition users and improves consistency between what users see and what assistive technologies announce.
- Prefer using visible text as the accessible name by default.
- If adding extra context, keep the visible label intact (e.g., “Download (PDF)”).
- For icon buttons with visible text nearby, ensure the name includes the same words.
Reference: All summaries and highlights originate from Understanding WCAG 2.5.3 and the W3C quick reference.
Fast facts
- Conformance level
- Level A
- WCAG version introduced
- WCAG 2.1
- Principle
- Operable
- Guideline
- 2.5 · Input Modalities
Examples
Make success tangible for teams
Share pass/fail snapshots to coach designers, engineers, QA, and content authors.
Button label
Pass
Visible: “Save”; accessible name: “Save” (or “Save settings”).
Fail
Visible: “Save”; accessible name: “Store”.
Icon + text
Pass
Visible: “Download”; accessible name includes “Download”.
Fail
Accessible name omits “Download” and uses unrelated text.
Evidence to keep
Document conformance decisions
Capture artifacts for VPATs, procurement reviews, and regression testing.
- Document a rule: avoid `aria-label` when visible text exists unless it includes the visible label.
- Provide examples for icon+text and icon-only patterns.
Official resources
Deep dives and supporting material
Keep these links handy when writing acceptance criteria or responding to audits.
Implementation checklist
Capture progress and blockers
- Audit controls for mismatches between visible labels and accessible names.
- Ensure `aria-label` does not override visible label text incorrectly.
- Use `aria-labelledby` to include visible text in the accessible name when needed.
- Keep accessible names consistent across repeated patterns.
Testing ideas
Prove conformance with evidence
- Inspect accessible names in the accessibility tree and compare to visible labels.
- Use voice control (or simulated) to activate controls by visible label text.
- Use a screen reader to confirm announced names include the visible label.
Related success criteria