Voice Control Users
Voice control users say what they see. When the visible label and the accessible name disagree, the command fails silently.
"Click Submit" only works if the button's accessible name actually contains the word Submit.
The user looks at a button that says "Submit application" and says "click submit application." If the button's accessible name is "Send form" — because someone added an aria-label that reads better to a developer — nothing happens, and there is no error to explain why. This is the failure mode WCAG 2.5.3 exists to prevent, and it is one of the few criteria that is broken by trying to be helpful.
Scale: Voice control is used by people with mobility impairments, repetitive strain injuries, and temporary injuries, and overlaps heavily with the population that cannot use a mouse. (Source: CDC mobility disability data. Survey-based disability figures undercount — treat this as a floor.)
What they're using
- Dragon NaturallySpeaking and Dragon Professional
- Voice Control on macOS and iOS
- Voice Access on Android and Windows
- Numbered-overlay modes that let users say a number instead of a name
4 barriers we find most often, and the criteria behind them.
Accessible names that do not contain the visible text
An aria-label that replaces rather than extends the visible label breaks voice activation. The accessible name must start with, or at least contain, the words the user can see.
Success criteria: 2.5.3 Label in Name A
Icon-only controls with no visible text
There is nothing to say. Voice users fall back to grid or number overlays, which is slower and more error-prone.
Success criteria: 2.5.3 Label in Name A · 4.1.2 Name, Role, Value A
Duplicate visible labels
Nine identical "Learn more" links on a page means "click learn more" is ambiguous, and the software has to disambiguate with a numbered overlay.
Success criteria: 2.4.4 Link Purpose (In Context) A
Controls that require dragging
Sliders, sortable lists, and map interactions that only work by dragging cannot be driven by voice. A single-pointer alternative is required.
Success criteria: 2.5.1 Pointer Gestures A · 2.5.7 Dragging Movements AA
The changes that actually remove the barrier.
Make the accessible name start with the visible label
If the button reads "Submit," the accessible name should be "Submit" or "Submit application" — never "Send."
Give icon buttons visible text where you can
A small text label beside the icon helps voice users, cognitive accessibility, and conversion rates at once.
Make link text unique and descriptive
"Read the 2026 deadline guide" instead of the ninth "Learn more" on the page.
Provide a non-drag alternative for every drag interaction
Buttons to reorder, a text input for a slider value, a list view alongside the map.
Three tests you can run before you call anyone.
- Turn on Voice Control on macOS or Voice Access on Windows and try to navigate your main flow.
- Compare each button's visible text to its accessible name in the browser's accessibility panel.
- Count how many links on the page say the same thing.
If any of those go badly, you have your answer and you did not need a vendor to get it. What a vendor is for is the part after: knowing which of the 55 criteria that maps to, how deep it goes, and what it costs to fix properly rather than patch.
Run the Free CheckerWhere this shows up in practice
Other people the standard was written for.
People With Cognitive and Learning Disabilities
The largest disability group and the least served by automated testing. Almost nothing here can be caught by a scanner.
Read the profilePeople With Dyslexia and Reading Differences
Reading differences are common enough that designing for them is designing for a large share of your audience.
Read the profileAll 55 Success Criteria
Every Level A and AA criterion in plain language, with the failure we see most often for each.
Reference