Interactive elements often display visible text such as button labels or link text. Users rely on this text to understand what a control does and to interact with it. When the visible label does not match the element’s accessible name, users of assistive technologies may be unable to operate the control as expected.
Ensuring that visible text is included in the accessible name keeps visual and programmatic labels in sync.
What Is an Accessible Name
The accessible name is the text that assistive technologies use to identify and announce a user interface element.
An accessible name may come from:
- The element’s visible text content
- An
aria-labelattribute - An
aria-labelledbyreference - Other programmatic labeling mechanisms
Users of screen readers and speech input software interact with elements primarily through this accessible name, not through visual appearance alone.
WCAG Success Criteria
This requirement is defined by the following WCAG success criteria:
2.5.3 Label in Name (Level A)
For user interface components with labels that include text or images of text, the accessible name contains the text that is presented visually.
4.1.2 Name, Role, Value (Level A)
User interface components must expose correct names so assistive technologies can identify and operate them.
Together, these criteria ensure that interactive elements are labeled consistently across visual and programmatic representations.
What This Requirement Means
If an interactive element has visible text, that text must also appear in the element’s accessible name.
- The accessible name does not need to match the visible text exactly.
- The visible text must be contained within the accessible name.
- Best practice is for the accessible name to start with the visible text, in the same order.
Differences in case (uppercase vs lowercase) and leading or trailing whitespace do not matter.
How Accessible Names Are Computed
Accessible names are computed using a defined priority order.
Importantly:
aria-labeloverrides visible textaria-labelledbyoverrides both- If neither is present, visible text content is often used
This means that adding an aria-label to an element that already has visible text will replace, not supplement, that text in the accessible name.
This is a common source of failures.
Why This Matters
Speech input users often interact with web pages by speaking the visible text of buttons, links, and menu items.
If a user says what they see on screen, but the component’s accessible name does not contain that text, the command may fail.
Screen reader users are also affected when the announced name does not align with what is visually presented, increasing cognitive load and reducing trust in the interface.
When visible labels and accessible names are aligned, users can:
- Reliably activate controls
- Predict how controls will behave
- Navigate interfaces with confidence
Where This Rule Applies
This rule applies to interactive elements that have visible text and whose accessible name is provided or overridden by the author, such as through:
- Visible text content
aria-labelaria-labelledby
If an element has visible text and an author-provided accessible name, those two must not conflict.
Examples That Pass
Visible label and accessible name match (ignoring whitespace)
<div role="link" aria-label="next page ">next page</div>Case differences only
<div role="link" aria-label="Next Page">next page</div>Visible label fully contained in accessible name
<button aria-label="Next Page in the list">Next Page</button>In all of these examples, the visible text is present within the accessible name.
Examples That Fail
Visible label does not match accessible name
<div role="link" aria-label="OK">Next</div>This fails SC 2.5.3 because the visible label “Next” is not contained in the accessible name.
Accessible name does not include a full visible label
<button aria-label="the full">The full label</button>This fails SC 2.5.3 because not all of the visible label is included in the accessible name.
Overriding visible text with aria-label
<button aria-label="Submit">Search</button>This fails SC 2.5.3 because the visible label “Search” is not part of the accessible name.
“Clarifying” labels that change the starting text
<button aria-label="Save changes to server">Save</button>This fails SC 2.5.3 because the accessible name does not begin with the visible label.
How to Fix the Problem
To fix this issue:
- Ensure the accessible name includes the entire visible label
- Preserve the same word order
- Prefer fixing visible text rather than overriding it with
aria-label - Use
aria-labelledbywhen referencing existing visible text is appropriate - Avoid adding
aria-labelto elements that already have meaningful visible text unless absolutely necessary
Expectation
For every interactive element with visible text:
- The visible text must either match or be contained within the accessible name
- Ignore differences in case and leading or trailing whitespace
Rule Description
Interactive elements with visible labels must include that visible text as part of their accessible name. Any mismatch that prevents users from activating the control using the visible label fails this requirement.
Automated Testing Logic (Non-Normative)
Automated tools commonly check whether:
- An element has visible text
- An accessible name is present
- The accessible name contains the visible text, in order
These checks reflect common testing logic and are not WCAG text, but they help identify likely failures.
Wrapping Up
When users see a label on screen, they expect to be able to use that label to interact with the control. If the accessible name does not include the visible text, assistive technology users, especially speech input users, may be unable to operate the interface.
Keeping visible labels and accessible names aligned is a core Level A requirement and one of the simplest ways to prevent avoidable accessibility failures.
