Label and name from content mismatch
Accessibility testing for dev teams - No experience required
Compliance Data & Impact
Disabilities Affected
- Blind
- Low Vision
- Deafblind
- Mobility
Standard(s)
- WCAG 2.1 (A)
- Section 508
WCAG Success Criteria [WCAG 2.1 (A)]
- 2.5.3: MUST: Label in Name
Section 508 Guidelines
- 1194.22: MUST: Web based intranet and Internet Information & Applications
- 1194.22 (n): MUST: When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
How to Fix the Problem
Fix this issue by ensuring that the accessible name — such as the
aria-label — contains the text of the visible label in the
same order in which it appears. While it is not necessary that the visible
label and accessible name match exactly, it is a best practice to have the
accessible name begin with the visible text.
The following examples pass the Label and name from content mismatch rule:
-
Visible label and accessible name matches when trailing white spaces are removed:
<div role="link" aria-label="next page ">next page</div> -
Character insensitivity between visible label and accessible name.
<div role="link" aria-label="Next Page">next page</div> -
Full visible label is contained in the accessible name.
<button name="link" aria-label="Next Page in the list">Next Page</button>
The following examples fail the Label and name from content mismatch rule:
-
Visible label doesn’t match accessible name.
<div role="link" aria-label="OK">Next</div> -
Not all of visible label is included in accessible name.
<button name="link" aria-label="the full">The full label</button>
Why it Matters
This rule applies to any element that has:
-
a semantic role that is a widget that supports name from content, and
visible text content, and
-
an
aria-labeloraria-labelledbyattribute.
Note: widget roles that supports name from content are: button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, searchbox, switch, tab, treeitem.
Expectation
The complete visible text content of the target element either matches or is contained within its accessible name.
Note: Leading and trailing whitespace and difference in case sensitivity should be ignored.
Speech input users can interact with a webpage by speaking the visible text labels of menus, links, and buttons that appear on the screen. It is confusing to speech input users when they say a visible text label they see, but the speech command does not work because the component's accessible (programmatic) name does not match the visible label. When a user interface component has a visible text label — whether it be real text or an image of text — that text must also be found in the component's accessible (programmatic) name. When the visible label and accessible (programmatic) name for interactive components are in sync, speech input users can effectively interact with those components.
Rule Description
Interactive elements labeled through their content must have their visible label as part of their accessible name
The Algorithm (in simple terms)
For each user interface component that includes a visible text label, the accessible name MUST match (or include) the visible text in the label.
Resources
Refer to the complete list of axe 4.3 rules.
Was this information helpful?
Your response was as follows:
Date/Time feedback was submitted: