WCAG 2.5.3 Label in Name: Fix Mismatched Visible and Accessible Labels

What This Criterion Requires

WCAG 2.5.3 requires that for user interface components with visible text labels, the accessible name contains the visible label text. Ideally, the accessible name should start with the visible label text. This criterion exists primarily for users of speech-to-text or voice control software who activate controls by speaking their visible label. If a button visually reads 'Submit Order' but its accessible name is 'Process payment request', a voice control user saying 'click Submit Order' will fail to activate the button because the speech recognition software looks for the accessible name, not the rendered pixels. The accessible name can contain additional text beyond the visible label (such as visually hidden helper text), but it must include the visible text. Common violations occur when aria-label overrides the visible text with completely different wording, when aria-labelledby references text that differs from the visible label, or when CSS content properties are used for visual labels without matching accessible names.

Why It Matters

Voice control technology is increasingly popular, used not just by people with motor disabilities but also by anyone who prefers hands-free interaction. Software like Dragon NaturallySpeaking, Voice Control on macOS and iOS, and Voice Access on Android allows users to interact with web content by speaking commands that reference visible labels. When a user sees a button labeled 'Search' and says 'click Search', the software matches this against the accessible name in the accessibility tree. If the accessible name is something different, the command fails and the user is stuck. This is also an issue for screen reader users who can see the screen but rely on the screen reader for interaction: if the announced name differs from the visible text, it creates confusion. This criterion bridges the gap between visual presentation and programmatic representation, ensuring they are aligned. It is a relatively new criterion introduced in WCAG 2.1 and is frequently violated by well-meaning developers who use aria-label to add context without realizing they are overriding the visible label.

Common Failures and How to Fix Them

<button aria-label="Navigate to the home page">
  Home
</button>

<button>
  Home
</button>

<input type="search" placeholder="Search products" aria-label="Find items in our catalog">

<label for="product-search">Search products</label>
<input type="search" id="product-search" placeholder="Search products">

<button aria-label="Remove item from favorites" title="Unlike">
  <svg aria-hidden="true"><!-- heart icon --></svg>
</button>

<button aria-label="Unlike">
  <svg aria-hidden="true"><!-- heart icon --></svg>
</button>

How to Test

1. Compare the visible text of every interactive element (buttons, links, inputs with visible labels) against its computed accessible name in the browser's accessibility tree inspector.
2. Use a voice control tool (macOS Voice Control, Dragon, or Voice Access) to attempt activating interactive elements by speaking their visible label text.
3. Search for all aria-label and aria-labelledby attributes and verify each one contains or matches the visible text of the element it applies to.
4. Run axe DevTools which can detect some label-in-name violations where the accessible name does not contain the visible text.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

• Wordpress Accessibility Checklist
• Shopify Accessibility Checklist
• Squarespace Accessibility Checklist

Further Reading

• Accessible Forms Guide
• Wcag Explained Plain English
• Five Minute Accessibility Audit

Related WCAG Criteria

• WCAG 2.4.4
• WCAG 2.4.6
• WCAG 4.1.2
• WCAG 3.3.2