accessibility
Voice control
also called speech input (community), Voice Access (android), Dragon (community), show numbers (community)
Operating an interface by speaking control names or numbered overlays, which makes the visible wording of a control its address.
Someone who cannot use a mouse or a keyboard can still use the interface by talking to it. Apple ships this as Voice Control on macOS and iOS, Android as Voice Access, and Windows users have had Dragon for decades. The mechanic is always the same: the user says a verb and the name of a control, “Click Send”, and the software matches the spoken words against what it can find in the accessibility layer. That single sentence rearranges the whole design problem, because it makes the words printed on a control into its address. A button is no longer something you point at. It is something you name.
Which is why one WCAG criterion exists purely for this population. Success criterion 2.5.3
Label in Name (Level A) requires that for components with a visible text label, the name
contains the text that is presented visually. The classic failure is an aria-label added
with good intentions that quietly replaces the words on the button: the button reads Save
draft, the accessible name is “Store changes”, and a voice user who
says “Click Save draft” gets silence. Nothing looks broken, nothing is announced wrongly,
and the control is simply unreachable. The safe habit is to let the visible text be the
name, or, where extra context is genuinely needed, to make the name start with the visible
label rather than substitute for it. The same discipline applies to
label association: a field a voice user cannot name is a field they
cannot fill.
For controls that have no words at all, the platforms offer overlays. Apple’s Voice Control answers “Show names” with a name beside every item, “Show numbers” with a number beside every item, and “Show grid” with a numbered grid over the screen for anything the first two cannot reach. These work, and they are a real fallback rather than a hack, but they charge a lookup on every command: the user has to ask for the overlay, read it, and then speak a number that means nothing five seconds later. An icon-only button is a number for everybody, every time.
Two neighbouring habits are worth rereading with a voice user in mind. Placeholder as label leaves a field with a name that disappears the moment there is anything in it, so a correction becomes impossible to aim. And twelve links that all read “Read more” are ambiguous to speech in the same way they are ambiguous to a link purpose audit, except that here the ambiguity produces a disambiguation prompt on every attempt. Distinct, visible, spoken-out-loud wording is the fix for all three, which is a pleasant thing about this constraint: it almost never asks for anything the sighted pointer user would not also have preferred.
Which word?
| If you want | say |
|---|---|
| the reader clicks by saying the button's name | voice control |
| input is a single button and time, not a pointer | switch access |
| voice, touch, and screen share one interaction | multimodal interface |
| aria-label and the visible text disagree | label in name |
| naming the software that reads an interface aloud | screen reader |
| the interaction has no screen to design | zero ui |