WCAG 2.5.3 Label in Name — Testing Guide for Mobile & Web Apps

WCAG 2.5.3, "Label in Name," is a Level A success criterion that mandates a straightforward principle: the name of a user interface component must contain the text of its visible label. This applies t

Ensuring WCAG 2.5.3: Label in Name Compliance

WCAG 2.5.3, "Label in Name," is a Level A success criterion that mandates a straightforward principle: the name of a user interface component must contain the text of its visible label. This applies to interactive elements like buttons, input fields, links, and custom controls.

What WCAG 2.5.3 Requires

At its core, this criterion means that if a button displays the text "Submit Order," then the programmatic name of that button must also include "Submit Order." This programmatic name is what assistive technologies, such as screen readers, use to identify and announce the element to users. Essentially, the visible text and the accessible name should be consistent.

Why It Matters: User Impact

Adherence to WCAG 2.5.3 directly impacts users who rely on assistive technologies.

• Screen Reader Users: Without a consistent label in the name, screen readers might announce an element with a generic or incorrect label, leading to confusion. For example, if a button visually says "Add to Cart" but its programmatic name is "Button," a screen reader user won't understand the action. This creates significant friction, especially for users navigating complex workflows like e-commerce checkouts or registration forms.
• Users with Cognitive Disabilities: Clear and consistent labeling aids comprehension for users who may have difficulty processing complex information. A mismatch between visual and programmatic labels can be disorienting.
• Users with Low Vision: While primarily an assistive technology concern, users who magnify their screen or use high-contrast modes benefit from predictable labeling.

This criterion is crucial for meeting legal requirements such as the European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA), which mandate accessible digital experiences for users with disabilities.

Common Violations and Examples

Violations often occur due to developers not fully understanding how assistive technologies interpret UI elements, particularly with custom controls or complex layouts.

#### Mobile App Violations

1. Icon Buttons Without Text: An "X" icon button to close a modal. Visually, it's clear. Programmatically, if the accessible name is just "Button" or empty, a screen reader user won't know what it does.

• Violation: Button visually labeled "X" but programmatically named "Button."
• Impact: User doesn't know the purpose of the button.

1. Custom Toggle Switches: A switch that visually indicates "On" or "Off" but whose accessible name is simply "Switch."

• Violation: Toggle switch visually shows "On" but programmatically named "Toggle Switch."
• Impact: Screen reader announces the element type but not its current state or action.

1. Input Fields with Missing Labels: A search input field with a magnifying glass icon next to it. The icon might be intended as the label, but if the input field itself doesn't have a programmatic label associated with it (e.g., "Search"), users might not know what to type.

• Violation: Search input field with a magnifying glass icon, but the input's accessible name is empty or generic.
• Impact: User doesn't know the purpose of the input field.

#### Web App Violations

1. Buttons with Only Icons: A "Save" icon button (e.g., a floppy disk) without any accompanying text.

• Violation: Button displays a floppy disk icon but its accessible name is "Button."
• Impact: Users unfamiliar with the icon's meaning are lost.

1. Links with Ambiguous Text: A "Click here" link within a paragraph. The surrounding text might provide context, but the link's accessible name is only "Click here."

• Violation: Link text is "Click here," but the programmatic name is also "Click here." (This is technically compliant if the surrounding text makes it clear, but often these links are not sufficiently descriptive on their own). A more common violation is when the link text is just an icon, and the accessible name is generic.
• Impact: Users might not understand what content the link leads to when encountered out of context by a screen reader.

1. Form Elements Without Clear Labels: A radio button group for selecting a payment method. Each radio button has a label like "Visa," "Mastercard," etc., but the *group* itself lacks a discernible label, or the individual radio buttons are not programmatically linked to their text labels.

• Violation: Radio buttons labeled "Visa," "Mastercard," but the name attribute on the radio buttons is not descriptive, or the aria-label or aria-labelledby is missing.
• Impact: Users may not understand what the group of radio buttons represents or which option they are selecting.

How to Test for Compliance

Testing for WCAG 2.5.3 involves checking the visible label against the programmatic name.

#### Manual Testing Steps

1. Identify Interactive Elements: Focus on buttons, links, input fields, checkboxes, radio buttons, and custom controls.
2. Observe Visible Labels: Note the text or icon displayed for each element.
3. Use Accessibility Inspectors:

• Web: Utilize browser developer tools (e.g., Chrome DevTools' Accessibility tab, Firefox's Accessibility Inspector) or extensions like axe DevTools. Inspect the element and check its "name" or "accessible name" property.
• Mobile: Use platform-specific tools like Android's Accessibility Scanner or iOS's Accessibility Inspector. For Android, you can often enable "Explore by Touch" in Developer Options and tap elements to hear their spoken labels.

1. Compare Labels: Verify that the text announced by the accessibility tool matches the visible text or icon's intended meaning. For icon-only buttons, ensure the accessible name clearly describes the action (e.g., "Close," "Save," "Search").

#### Automated Tools

Several automated tools can help identify violations:

• axe DevTools (Browser Extension/CLI): Detects "label-in-name" violations automatically.
• Lighthouse (Browser Extension/CLI): Includes accessibility audits that flag this criterion.
• Pa11y (CLI Tool): A command-line accessibility checker that can be integrated into workflows.

#### Mobile-Specific Considerations

• Android: Use contentDescription for image buttons or icons, and ensure android:labelFor is correctly set for input fields. For custom views, implement accessibility services to provide a meaningful accessible name.
• iOS: Use accessibilityLabel for elements that lack visible text labels. Ensure accessibilityTraits are set appropriately to convey the element's purpose.

How to Fix Violations

The fix depends on the technology stack and the type of violation.

#### Code Examples

Web (HTML):

• Icon Button Violation:
• *Bad:* (Screen reader might announce "Button")
• *Good:*
• Input Field Violation:
• *Bad:* (No visible label)
• *Good:* Search (The label element provides the visible and programmatic name).
• *Alternative for icon-based search:*

Mobile (Android - Kotlin):

• Icon Button Violation:
• *Bad:* (Screen reader might announce "Close button" based on ID, but not reliably)
• *Good:*
• *In strings.xml:* Close
• Input Field Violation:
• *Bad:* (No associated label)
• *Good:*

Mobile (iOS - Swift):

• Icon Button Violation:
• *Bad:* let closeButton = UIButton(type: .system) followed by setting an image.
• *Good:* let closeButton = UIButton(type: .system) \

closeButton.setImage(UIImage(named: "closeIcon"), for: .normal) \

closeButton.accessibilityLabel = "Close"

• Input Field Violation:
• *Bad:* let emailTextField = UITextField()
• *Good:* let emailLabel = UILabel() \

emailLabel.text = "Email Address" \

emailTextField.accessibilityLabel = "Email Address" (Or use UIAccessibility methods to associate the label)

How SUSA Checks This Criterion

SUSA's autonomous QA platform actively tests for WCAG 2.5.3 compliance during its exploration of your application.

• Autonomous Exploration: SUSA uploads your APK or web URL and begins exploring your application's user interface. It doesn't rely on pre-written scripts.
• Persona-Based Testing: SUSA utilizes 10 distinct user personas, including "Accessibility" and "Curious" users. The "Accessibility" persona is specifically programmed to analyze elements for accessibility compliance.
• Element Analysis: As SUSA interacts with your app, it inspects each interactive element. It retrieves both the visible label (text or icon representation) and the programmatic accessible name.
• WCAG 2.1 AA Checks: SUSA performs comprehensive WCAG 2.1 AA testing, which includes the "Label in Name" success criterion (2.5.3). It compares the visible label with the accessible name for all interactive components.
• Violation Reporting: When SUSA detects a mismatch that violates WCAG 2.5.3, it logs this as a specific issue. This includes identifying the element, the visible label, and the incorrect accessible name.
• Cross-Session Learning: With each run, SUSA gets smarter about your application's structure and how elements are implemented, improving its detection accuracy over time.
• Flow Tracking: SUSA tracks critical user flows like login, registration, and checkout. Failures related to WCAG 2.5.3 within these flows are clearly flagged, providing PASS/FAIL