WCAG 2.1, released in 2018, introduced several new success criteria, enhancing web accessibility. This article focuses on "Label in Name" (2.5.3), a crucial aspect of labeling user interface components. We'll explore common pitfalls, solutions, and best practices.

Understanding Success Criteria

A success criterion is a testable, technology-agnostic statement defining accessibility compliance. "Label in Name" evaluates whether the visual label of a component matches its programmatic name. It's part of WCAG 2.1's "Operable" category, specifically addressing input modalities. Importantly, WCAG 2.1 is backward-compatible with WCAG 2.0.

Label in Name: Visual vs. Programmatic

WCAG 2.5.3 (Level A) states: "For user interface components with labels that include text or images of text, the name contains the text that is presented visually."

This ensures consistency between the visually presented label and the component's programmatic name (accessible name). This consistency is vital for users of assistive technologies like screen readers and speech recognition software. The visual and programmatic names don't need to be identical, but they must share a common, associating term (e.g., "Submit" and "Submit Form"). Discrepancies create confusion and hinder accessibility.

Assistive Technology Implications

Consider an HTML contact form. A user employing speech recognition might encounter a button with the visual text "Send" but a programmatic name of "Submit." This mismatch is a failure. The user, relying on the visual label, cannot activate the button using speech commands. Matching the visual and programmatic names ("Send" in both cases) resolves this issue. If the aria-label adds no value, removing it is preferable.

Screen reader users also benefit from consistent labeling. Hearing text similar to what they see enhances usability. Conversely, mismatched labels can lead to accidental activation of controls via speech input or confusion for users navigating via screen readers. The criterion doesn't apply to components lacking visual labels.

Code Examples: Failure States and Corrections

The article presents three failure scenarios:

1. A disconnect between the spoken and visual labels.
2. A label mismatch due to an "accessibly hidden" span adding extra text to the spoken label.
3. An input with an aria-labelledby attribute failing to establish a correlation between spoken and visual labels.

These examples highlight common errors. The article then provides corrected code snippets for each scenario.

A 2020 WebAIM study revealed that 55% of 4.2 million form inputs were improperly labeled.

Proper label-input pairing using <label></label> elements is crucial, but the programmatic name (accessible name) via aria-label is equally important. Inconsistencies between <label></label> text and aria-label create cognitive overload for users with cognitive disabilities and speech-input users.

Label Placement and Text Specificity

The article clarifies that text isn't considered a visual label if used symbolically rather than literally. Rich text editors, often using images as text, exemplify this.

For consistency, the visually proximate label should be considered the label text. Optimal placement guidelines include:

• Left of text inputs and dropdowns.
• Right of checkboxes and radio buttons.
• Inside buttons or tabs, or below icon buttons.

Minor variations in punctuation and capitalization are acceptable if not symbolic.

Components without visual labels are excluded from this success criterion.

Benefits of Proper Labeling

Consistent labeling allows speech-input users to activate controls seamlessly, eliminating guesswork. Inclusive design benefits all users, creating a more enjoyable and accessible experience.

Conclusion and Testing

The article summarizes WCAG 2.5.3, emphasizing its importance despite seeming simplicity. It highlights the A-level compliance requirement: ensuring the programmatic name contains the visually presented text.

Testing can be performed using browser developer tools (Chrome DevTools, Firefox Developer Tools), or accessibility auditing tools like WAVE and Axe. Adhering to this criterion, though seemingly minor, significantly improves accessibility for all users.

The above is the detailed content of What's New in WCAG 2.1: Label in Name. For more information, please follow other related articles on the PHP Chinese website!