Voice interfaces were never designed with accessibility in mind. Amazon built Alexa to sell more batteries and diapers. Apple built Siri so drivers could send a text without touching a screen. Google built Assistant to keep people inside its search ecosystem a few extra seconds. Convenience was the pitch. Inclusion was not part of the deck.
And yet, somewhere between the marketing plans and the shipped products, voice control quietly became one of the most important accessibility tools that exists. For someone with a motor impairment who cannot reliably operate a mouse or trackpad, a voice command is not a novelty feature, it is the primary way they use a computer. For someone with low vision who cannot track a cursor across a busy screen, saying "open settings" is faster and far more forgiving than hunting for a tiny icon. Nobody planned for this outcome. It happened because voice was convenient for everyone, and it turned out to be load-bearing for some.
That accident is now running headfirst into a WCAG rule that most product teams have never heard of, let alone tested against.
The Stat: WCAG's 2.5.3 Label in Name success criterion specifically requires a component's accessible name to contain its visible label text, so voice-control users can activate it by speaking what they see. (Source: W3C WCAG 2.5.3)
What "Label in Name" Actually Checks
SC 2.5.3 lives inside the Input Modalities principle of WCAG 2.1, and it is a Level A requirement, meaning it sits in the baseline tier that every conformance claim depends on. The rule is narrow and mechanical, which is exactly why it is so easy to violate without noticing.
Here is the mechanism. Voice control software, whether that is Voice Control on iOS and macOS, Voice Access on Android, or Dragon-style dictation tools, does not understand your interface visually. It reads the accessible name of each interactive element, the same name a screen reader announces, and it matches that name against what the user says out loud. When someone looks at a button that says "Submit" and speaks the word "Submit," the software is silently checking: does any control on this screen have an accessible name containing that word?
If a developer has set aria-label="btn-primary-01" on that button, perhaps left over from a component library default, or aria-label="Complete your purchase and continue to shipping" because it seemed more descriptive for screen reader users, the voice command fails. Not with an error message. It simply does nothing, because the system was never told that "Submit" refers to this control. The user assumes they misspoke, tries again, and eventually gives up or looks for a mouse.
This is the overlap nobody planned for. Screen reader accessibility and voice control accessibility both depend on the accessible name, but they are not the same requirement. A verbose, highly descriptive accessible name can be excellent for screen reader users and simultaneously break voice control completely, because the visible word the user is looking at is no longer contained inside it.
Why It Keeps Slipping Through Review
Most accessibility QA processes are built around screen reader testing and automated scanners. Automated tools can flag a missing accessible name, but they generally cannot flag a mismatched one, because from a purely technical standpoint the element still has a name, an aria attribute, a computed value. Nothing is technically empty or broken in the way a scanner checks for.
The mismatch only becomes visible when a human, or voice control software, tries to act on the visible text. This is why a component can pass an automated audit, pass a screen reader spot check, and still fail SC 2.5.3 the moment someone tries to operate it by voice. It is a gap between "has a name" and "has the right name," and that gap is exactly where Label in Name violations live.
The W3C's own perspective video on voice makes this dependency concrete by showing, in practice, how someone who relies on speech to navigate a page experiences a page where labels do not match what is spoken. If you want the formal wording and worked examples, the official W3C Understanding document for SC 2.5.3 is the primary reference, and the W3C's perspective video on voice is a useful companion for showing stakeholders why this matters in a way a spec document rarely does.
A Practical Checklist for Voice-Ready Components
Fixing this is not a redesign. It is a naming discipline problem, and it is checkable component by component.
- Treat visible text as the anchor. Whatever words appear on screen, in an icon button's tooltip, in a link, in a form control's visible label, the accessible name must contain those exact words somewhere in it. It does not need to be identical, but the visible text must be a substring of the accessible name.
- Audit icon-only buttons first. These are the highest-risk components because there is no visible text at all, only an icon, which means the entire accessible name is invented by whoever wrote the
aria-label. If a trash icon's accessible name is "Remove item" but the tooltip that appears on hover says "Delete," voice users saying "Delete" will fail to trigger it. - Stop over-writing labels for screen readers alone. A common well-intentioned mistake is padding an
aria-labelwith extra context, like changing "Submit" to "Submit your application for review," assuming it helps screen reader users understand intent. It might. It also breaks voice control unless the original visible word is preserved somewhere in that string. - Test with real voice control software, not just a screen reader. Turn on Voice Control or Voice Access, look at your page, and try to operate every interactive element by speaking exactly what is printed on it. This single test catches more Label in Name failures in ten minutes than most manual audits catch in an hour, because it reproduces the actual failure mode instead of inspecting markup.
- Standardize naming conventions across design and engineering. Most Label in Name violations are not deliberate, they are the result of a designer's copy changing after a component's
aria-labelwas already written and never synced back. A shared source of truth for visible copy and accessible names, reviewed together, closes this gap at the root.
If you want a fast way to check where your own components stand, running your site through the free accessibility tools at wcag.world is a reasonable first pass before committing engineering time to a full manual audit.
The Same Mismatch Is Showing Up in Chat
Voice assistants are not the only conversational surface racing ahead of accessibility testing. Chatbots have the identical problem in a different shape: a widget button might visually say "Chat with us," but if its accessible name, ARIA live region behavior, or focus handling does not match what is presented on screen, both screen reader users and voice control users hit the same kind of silent failure. We covered exactly this pattern, and the legal exposure that comes with it, in our breakdown of why your AI chatbot is probably a WCAG lawsuit waiting to happen. Voice interfaces and chat interfaces are converging on the same underlying requirement: what a user sees, hears, and says all have to point at the same thing.
That convergence is why Label in Name deserves more attention than it typically gets. It was written for a world of buttons and forms, but it turns out to be exactly the rule that determines whether a voice-first future is usable by everyone or just the people who happen to phrase things the way a developer guessed they would.
If you are not sure whether your product's accessible names actually match what is on screen, that is a fast, concrete thing to check, and it is the kind of gap that automated scanners routinely miss. Reach out to experts@wcag.world and a real person on our team will walk through it with you, or start with the free tools at wcag.world to see where your components stand today.