WCAG 2.5.3: Label in Name

WCAG 2.5.3: Label in Name – Enhancing Predictability for All Users

WCAG 2.5.3, also known as “Label in Name,” is a crucial success criterion introduced in WCAG 2.1. It mandates that for user interface components with visible labels, the accessible name of that component must include the visible text. This seemingly simple rule has a profound impact on usability and accessibility, particularly for users of assistive technologies like screen readers and speech input software.

Introduction to Label in Name

At its core, WCAG 2.5.3 ensures consistency between what a user sees on the screen and what assistive technologies convey about an interactive element. Imagine a button with the visible text “Submit.” A screen reader user should hear “Submit” when they encounter it, and a speech input user should be able to activate it by saying “Submit.” The “Label in Name” criterion formalizes this expectation, requiring that if a component has a visible textual label, that exact text (or an image of text’s alternative text) must be part of its programmatic accessible name.

Why is Label in Name Important?

Compliance with WCAG 2.5.3 significantly improves the user experience for several groups:

• Screen Reader Users: Users who rely on screen readers often scan the visual interface first, or they may be sighted users who prefer to use a screen reader. If they see a label like “Cart” but the screen reader announces “Shopping Basket button,” it creates confusion and cognitive load. Consistency allows them to easily correlate visual elements with what they hear.
• Speech Input Users: Individuals who control their computers using voice commands (e.g., Dragon NaturallySpeaking) often vocalize the visible labels they see on the screen to interact with components. If a button visibly says “Save” but its accessible name is “Store Data,” saying “Click Save” might not work, leading to frustration and inefficiency. This criterion ensures that visible text acts as a reliable command.
• Users with Cognitive Disabilities: Predictability and consistency are vital for users with cognitive or learning disabilities. Mismatches between visual and auditory cues can cause significant confusion and make it difficult to understand the interface and complete tasks.
• Users with Low Vision: These users might partially see a label and then use a screen magnifier or screen reader to get more information. If the accessible name doesn’t include what they partially saw, it can disrupt their understanding.

Understanding the Success Criterion 2.5.3

The official wording of WCAG 2.5.3 is:

2.5.3 Label in Name (Level A): For user interface components with labels that include text or images of text, that text or text alternative is included in the accessible name.

Key aspects to note:

• “User interface components with labels that include text or images of text”: This refers to any interactive element (buttons, links, form fields, etc.) that has a visible text label or an image of text that serves as a label.
• “that text or text alternative is included in the accessible name”: The visible label’s text must be part of the component’s programmatic accessible name. It doesn’t have to be an exact match or appear at the beginning, but it must be present. For images of text, the image’s text alternative (e.g., from an alt attribute) must be included.

Exceptions:

There are two specific exceptions where this criterion does not apply:

1. Text is Hidden Visually: When the text content is visually hidden using CSS (e.g., off-screen positioning, clip, display: none, or visibility: hidden), the component does not have a visible text label. In such cases, the accessible name is still expected to convey the component’s purpose, but the “Label in Name” criterion does not apply because there is no visible text for the rule to check against. For example, a “hamburger menu” icon without visible text, but an aria-label="Menu".
2. Graphic as Label with Text Alternative: When the component’s label is primarily a graphic (e.g., an icon), and there is no visible text alongside it. The graphic itself serves as the visible label, and its text alternative (e.g., provided via aria-label or an <img> element’s alt text) forms the accessible name. In this scenario, as there’s no visible text to include, the criterion does not apply. If there is visible text accompanying the graphic, then that visible text must be included in the accessible name.

Practical Guidelines for Compliance

Achieving compliance with WCAG 2.5.3 often involves careful construction of accessible names. Here’s how to ensure your components meet the criterion:

• Prioritize Semantic HTML: Whenever possible, use native HTML elements that inherently handle accessible names well.
  • For input fields, use a properly associated <label> element.
  • For buttons, the text content within the <button> tags typically forms its accessible name.
  • For links, the text content within the <a> tags forms its accessible name.
• Use aria-labelledby Thoughtfully: If you use aria-labelledby to construct an accessible name, ensure that one of the referenced elements (or the concatenation of multiple elements) contains the visible label text. For example, if your accessible name combines a heading and the component’s visible label, ensure the visible label’s ID is included in the aria-labelledby list.
• Use aria-label Carefully: When using aria-label, remember that it directly overrides any other name computation methods. If a component has a visible text label, the aria-label‘s value MUST include that visible text. Avoid using aria-label to provide a completely different name than what is visibly presented.
• Image Buttons and Icons: If an <img> element is used within a button or link and serves as its visible label, its alt text should be used as part of the accessible name. If an icon font or SVG is used, ensure the accessible name (e.g., via aria-label on the button/link) includes the visible text if there is any, or provides a clear, consistent name if it’s icon-only (referencing the exception).

Examples of Correct and Incorrect Implementations

Correct Implementations

<button>Submit Form</button>

<label for="email">Email Address</label>
<input type="email" id="email">

<button type="button">
  <span class="icon-save" aria-hidden="true"></span> Save
</button>

<button aria-label="Close this popup">Close</button>

.sr-only {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
  white-space: nowrap;
}

<button>
  <span class="icon-menu" aria-hidden="true"></span>
  <span class="sr-only">Menu</span>
</button>

<button aria-label="Menu">
  <span class="icon-menu" aria-hidden="true"></span>
</button>

Incorrect Implementations

<button aria-label="Go to Login Page">Log In</button>

<label for="username">Username:</label>
<input type="text" id="username" aria-label="Enter your account ID">

<a href="#" title="Read the full article">More info</a>

Best Practices and Common Pitfalls

• Always Start with Semantic HTML: Leverage <label> for form controls and put text directly inside buttons and links. This is the most robust and accessible approach and often naturally satisfies 2.5.3.
• Use aria-label and aria-labelledby Judiciously: These are powerful tools but can easily break WCAG 2.5.3 if not used correctly. Always double-check that the visible text is a substring of the value provided by aria-label or the combined text referenced by aria-labelledby.
• Test with Assistive Technologies: The best way to ensure compliance is to test your implementation with actual screen readers (NVDA, JAWS, VoiceOver) and speech input software. Listen carefully to what is announced for interactive elements.
• Inspect the Accessibility Tree: Use browser developer tools (e.g., Chrome DevTools > Accessibility tab, Firefox Accessibility Inspector) to examine the computed accessible name of your components. This provides a programmatic view of what assistive technologies will receive.
• Consider Localization: When translating your interface, ensure that the “Label in Name” consistency is maintained across all languages.
• Avoid Over-engineering Accessible Names: Simple, direct accessible names are often best. Don’t add unnecessary descriptive text to aria-label if it makes the visible label a small, non-inclusive part of it, unless there’s a strong reason and the visible text is still included.
• Icons vs. Text: Remember the exceptions. If a button is purely an icon (no visible text), then the accessible name can be solely descriptive of the icon’s function (e.g., aria-label="Search" for a magnifying glass). This is an exception and does not violate 2.5.3, as there is no visible text label to include.

Conclusion

WCAG 2.5.3 “Label in Name” is a fundamental criterion for creating accessible and usable web interfaces. By ensuring that the visible text of a component is always included in its accessible name, we empower users of screen readers and speech input software to interact with web content more efficiently and with less cognitive effort. Adhering to this principle of consistency and predictability fosters a more inclusive digital environment for everyone.