Try this for five minutes today: turn on voice control (Voice Control on a Mac, Voice Access on Windows 11, either works), open your own site, and say exactly what's printed on each button. Not what you think it's called behind the scenes — what's literally sitting on the screen in front of you. "Submit." "Add to cart." "Close."
If even one of those commands does nothing, you just found a bug that no visual QA pass will ever catch, because it's invisible unless you're using your voice to drive the page. And it's shockingly common, because it usually comes from a well-meaning developer trying to make a button "more descriptive" for screen readers — without realizing they broke it for a completely different group of assistive tech users in the process.
The fix, once you know what to look for, is a one-line change. Here's the whole story.
The Stat: WCAG Success Criterion 2.5.3, Label in Name, requires that the words visually labeling a component also be included in that component's programmatic accessible name — so speech-input users can activate controls simply by speaking the visible text they see. A button whose visible text is "Submit" but whose accessible name is "Send Form" fails this criterion, because a user who says "Submit" won't activate it. (Source: W3C WCAG 2.5.3 Label in Name)
Why "more descriptive" ARIA labels quietly break voice control
Here's the well-intentioned mistake at the root of this: a developer looks at a button that just says "Submit" and thinks, "that's not descriptive enough for a screen reader user, they won't know what they're submitting." So they add aria-label="Send Form" or aria-label="Submit Contact Request" to give screen reader users more context.
Reasonable instinct. Wrong tool for the job. Here's why.
When an aria-label is present, it completely overrides the visible text for the purposes of the accessible name — the string that gets exposed to assistive technology. Screen readers will announce "Send Form, button" instead of "Submit, button." That part might even be fine, or even nice, for screen reader users.
But speech-input software like Apple's Voice Control or Microsoft's Voice Access doesn't work by reading your intentions. It works by matching what you say out loud to the accessible name of the elements on the page. If you say "Submit" and the button's accessible name is "Send Form," the software has nothing to match your command against. The button might as well not be there. No error, no feedback — the command just silently does nothing, and the user is left wondering if their microphone is broken, or if they misspoke, or if the site is broken. It's the last one.
This is exactly what WCAG 2.5.3 Label in Name exists to prevent. It's a Level A criterion — the baseline, must-fix tier of WCAG conformance — and the rule itself is refreshingly simple: whatever text is visually printed on a control must be contained within that control's accessible name. You can still add extra context after it. You just can't replace it or reorder it so the visible words no longer appear as a match.
The fix is almost always this simple
You don't need to remove your extra context — you just need to keep the visible words in the accessible name, ideally as the leading text.
| Situation | Fails 2.5.3 | Passes 2.5.3 |
|---|---|---|
| Visible text: "Submit" | aria-label="Send Form" |
aria-label="Submit contact request" |
| Visible text: "Add" | aria-label="Add item to cart" (reordered/renamed) |
aria-label="Add to cart" |
| Visible text: "Close" | aria-label="Dismiss dialog" |
aria-label="Close dialog" |
| Icon-only button showing a trash icon, no visible text | N/A (no visible text label to match) | aria-label="Delete" is fine — there's nothing visible to conflict with |
Notice the pattern: the criterion only applies when there is visible text. Icon-only buttons with no printed label aren't affected by 2.5.3 at all, since there's no visible words to fail to match. The problem only shows up the moment you have both visible text and a custom accessible name that diverges from it.
Where this hides beyond aria-label
aria-label is the most obvious culprit, but it's not the only way to accidentally rename a button behind the scenes. Watch for these too:
aria-labelledbypointing at the wrong element. If a button's accessible name is built by referencing another element's text (say, a hidden heading or a tooltip string), and that referenced text doesn't include the button's visible words, you get the exact same silent failure — just one layer more indirect, which makes it harder to spot in a code review.titleattributes used as a substitute label. Some older component libraries fall back to thetitleattribute for the accessible name when nothing else is present. If that title reads "Proceed to next step" on a button that visibly says "Next," you've reintroduced the mismatch through a different attribute entirely.- Framework component libraries with baked-in defaults. Off-the-shelf UI kits sometimes ship a generic
aria-labelprop default (like "button" or a translation key placeholder) that a developer never overrides, especially on icon-plus-text combo components where the icon's label swallows the whole thing. - Visually hidden "screen-reader-only" text that duplicates the wrong string. A common pattern is a
<span class="sr-only">inside a button for extra context. If that hidden span's text doesn't literally contain the visible label, the combined accessible name can drift away from what's printed on screen.
None of these are exotic edge cases — they're the ordinary, everyday ways accessible names get built in real codebases. That's exactly why a five-minute voice test catches things that a code read-through often misses: you're testing the actual computed accessible name, not just guessing at what the markup implies.
Your five-minute audit checklist
Run through this on your own key user flows — checkout, contact forms, account settings, anything with buttons a customer actually needs to complete a task:
- Turn on Voice Control (Mac) or Voice Access (Windows) and say the exact visible label on each button, link, and form control
- Note every command that does nothing — that's a candidate accessible-name mismatch
- In dev tools, inspect each failing element for an
aria-label,aria-labelledby, ortitleattribute that doesn't contain the visible text - Rewrite the accessible name so the visible words appear first, then append any extra context after
- Re-test by voice to confirm the command now activates the control
- Repeat for icon+text combo buttons (a common blind spot — the icon's
aria-labelsometimes overrides the adjacent visible text entirely)
Both major voice control tools are worth testing with directly rather than guessing, since real behavior beats assumptions every time. Apple's official Accessibility Support page covers Voice Control setup and commands for macOS and iOS, and Microsoft's official Voice Access support page walks through the Windows 11 equivalent. Both work the same fundamental way: match spoken words to visible on-screen labels, which is precisely the mechanism 2.5.3 protects.
Why this matters more than it looks like it should
Voice control isn't a niche assistive technology reserved for a small edge case you can deprioritize. People rely on it for repetitive strain injuries, permanent or temporary limited hand mobility, recovery from surgery, or simply because they prefer hands-free interaction while multitasking. It's also built directly into the two most common operating systems on the planet, which means anyone can turn it on at any time without installing anything extra — including a customer who's never identified as having a disability, but who's driving, holding a baby, or typing with a broken wrist this week.
That's the part that makes 2.5.3 different from some of the more visually obvious WCAG criteria, like color contrast or alt text. A mismatched accessible name produces zero visual signal. The button looks completely normal, the sighted developer testing it with a mouse sees nothing wrong, and it can ship, sit in production, and quietly frustrate every voice-control user who touches that flow for months before anyone files a bug report — if anyone ever does, rather than just giving up and leaving.
The takeaway
Extra context for screen reader users is great. Just add it after the visible words, never instead of them. One consistent habit — accessible name starts with the visible text — quietly fixes an entire category of "why won't this button work" support tickets you may not even know you're generating.
Mismatches like this hide in plain sight because they only break for people using tools most teams never test with. If you want to know how many of these are sitting on your own site right now, put it to the test — you can find accessible-name mismatches on your own site with a free scan.