vocab.design

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 wantsay
the reader clicks by saying the button's namevoice control
input is a single button and time, not a pointerswitch access
voice, touch, and screen share one interactionmultimodal interface
aria-label and the visible text disagreelabel in name
naming the software that reads an interface aloudscreen reader
the interaction has no screen to designzero ui

Sources