Label Not in Name
What is this issue?
The "label not in name" issue occurs when a UI component's accessible name (the name read by assistive technologies and used by voice control software) does not contain the visible text label. WCAG Success Criterion 2.5.3 (Level A) requires that for components with labels that include visible text, the accessible name includes that visible text. This ensures that speech input users can activate controls by speaking the visible label.
This problem arises in several common scenarios: a button that visually says "Search" but has aria-label="Find products on our site", an input visually labeled "Email" but with aria-label="Enter your electronic mail address", or an image-based button whose alt text does not match the visible text in the image. In each case, a voice control user who says "Click Search" gets no response because the accessible name does not contain "Search".
The mismatch between visible label and accessible name often results from well-intentioned but misguided attempts to provide more descriptive accessible names. Developers add aria-label to "improve" the experience for screen reader users, not realizing they are breaking it for voice control users. The solution is to ensure the accessible name starts with or contains the visible text.
Impact on users
Voice control users (using software like Dragon NaturallySpeaking, Voice Access, or Voice Control on macOS) navigate by speaking the visible labels of controls. When a button says "Submit" on screen but its accessible name is "Send your application now", speaking "Click Submit" does not work. The user must guess the correct phrasing or resort to numbered overlays, which is slow and frustrating.
Screen reader users are also confused when the accessible name does not match the visible label. If a sighted colleague references the "Search" button during a call, a screen reader user hears "Find products on our site" and cannot correlate the two. This breaks collaborative work scenarios.
The disconnect also creates testing and QA challenges. Automated test scripts that locate elements by their visible text will fail when the accessible name is different, causing false negatives and reducing confidence in the test suite.
Code example
<!-- Visible: "Search", accessible name: different -->
<button aria-label="Find products on our site">
Search
</button>
<!-- Visible label doesn't match accessible name -->
<label for="email">Email</label>
<input id="email" type="email"
aria-label="Enter your electronic mail address">
<!-- Image button with mismatched alt -->
<button>
<img src="/icons/submit.png" alt="Send form data">
Submit
</button><!-- Accessible name starts with visible text -->
<button aria-label="Search products">
Search
</button>
<!-- Label matches, no override needed -->
<label for="email">Email</label>
<input id="email" type="email">
<!-- Alt matches visible text -->
<button>
<img src="/icons/submit.png" alt="">
Submit
</button>How Scrutia detects this issue
Scrutia compares the visible text of every interactive element (buttons, links, inputs) with its computed accessible name. When the accessible name does not contain the visible label text, the element is flagged. The report shows both the visible text and the accessible name, and suggests how to align them while preserving any additional descriptive context.
Check your site for this issue
Scrutia audits your site against WCAG criteria in minutes.
Frequently Asked Questions
Can the accessible name be longer than the visible label?
Does this apply to placeholder text?
How do voice control users interact with web pages?
Does your site have this issue?
Scrutia scans your pages against WCAG success criteria and delivers actionable fixes. Results in 5 minutes.
Run a free audit