Voice-selectable controls need an accessible name that matches the visible label

What it is

A voice user looks at the screen and says the word they see. For that utterance to select the control, the accessible name must contain the visible label. A button that reads “Send” but is named submitBtn or “Submit form” leaves “Click Send” hitting air. This is the interface contract for the voice channel: the visible string is the speakable string. It is not a manual of how an assistive technology matches tokens internally.

Why it happens

The speaker plans the utterance from vision; the system matches on the name. If the two strings diverge, selection fails while the feature still exists. Typical splits: marketing copy on the face (“Get started”), an engineering or screen-reader name behind it (“Create account”); visible text hidden with CSS while the name keeps old copy; a button label updated in paint but not in the name.

“Contains” allows the name to be longer (visible “Send”, name “Send message”), because the spoken substring can still hit. The reverse does not: visible “Send message”, name only “Send”, and a user who speaks the whole phrase may miss. If the visible label is split by decorative characters or icon fonts and the name concatenates them literally, nobody will pronounce that.

Studying it

Turn on platform voice control (macOS / iOS Voice Control, Android Voice Access). For every control with visible text, speak that text and see whether it hits. Then speak the code name or ARIA name and see whether only a developer word succeeds.

Independent variables: whether the visible label is contained in the name, leftover hidden copy. Dependent variables: hit rate on the visible word, rephrasings, whether the user falls back to numbers or the grid.

Automation can check containment of visible text in the accessible name, but still run real speech. Synthesized matching is not always the platform’s voice control.

Where it stops holding

Controls with no visible text are not under this contract; the problem becomes “there is no word to say.” Duplicate visible labels do not disambiguate even when each name matches. With voice off, a mismatched name still hurts screen readers, which is a separate check. Do not treat the name-computation cascade as selectability itself. A wrong cascade shows up as a mismatch; the test remains “does speaking the visible word select it.”

Applying it

• Make the visible label part of the name. What is painted on the button is in the name; change both when copy changes.
• Do not overwrite the visible word with a hidden “more professional” name. Extra explanation goes after the visible word, not instead of it.
• Verify: for every action with text, say “Click” plus the visible word. Log misses with both strings, and fix until the visible word hits.

Related

• Same group: J3.12.2 Icon-only buttons cannot be reached with a natural spoken command · J3.12.3 Duplicate on-screen names need numbers so voice can disambiguate · J3.12.4 A voice-control grid must not hide the content it is meant to target
• Nearby: J5.04 Voice Control · J5.10 Name, Role and Value
• Search terms: label in name · accessible name · voice control