skip to content

What is an accessible name, and what breaks for a voice-control user when it disagrees with the visible label?

level: juniorimportance: must knowfreq 76%

answer

  1. Which one is this, not what kind
  2. Every operable control needs one
  3. Speech input repeats what is visible
  4. Two sources of truth can disagree
  5. A Level A criterion covers the mismatch

basics

~20 s

An accessible name is the string assistive technology announces to identify a control - which one it is. Every operable control needs one, and it must contain the visible text, or voice-control users cannot activate it by saying what they see.

solid answer

~50 s

An **accessible name** is the short string assistive technology announces to identify a control: the *which one is this* fact, distinct from the *what kind of thing is this* fact carried by its role. Every control a user can operate must have one, because a node announced as button with no name cannot be told apart from the four beside it. That requirement is *4.1.2 Name, Role, Value* (Level A). The name can come from the control's own visible text or from a string the author supplies, and the two can silently drift apart. When they do - the control reads Buy ticket and is named Purchase - a screen-reader user hears a word nobody else on the team uses, and a voice-control user, who speaks the words printed on the control, gets nothing at all. *2.5.3 Label in Name* (Level A) exists for exactly that failure.

code

pseudocode · 5 lines
pseudocode
VISIBLE TEXT      Buy ticket
ACCESSIBLE NAME   Purchase

speech announces          -> Purchase, button
spoken command Buy ticket -> no match, nothing happens

go deeper

for a junior

Know that every control a user can operate must have an accessible name, that the name says which control it is rather than what kind it is, and that it should contain the words printed on the control.

for a middle

Explain how a name and a visible label drift apart in the first place, what each audience loses when they do, and why speech input matches the announced string literally rather than approximately.

for a senior

Expect to be asked how you would find naming defects across a whole product: which ones a machine can flag, which need a person operating and listening, and how you keep them from coming back after the current batch is fixed.

for a principal

Own naming as a content problem rather than a code one. Decide who writes the words, how they stay consistent across a product and its translations, and what a shared component library owes so that names cannot silently diverge from labels.

## Name is identity, not kind Assistive technology describes a control with several facts, and the two that get confused are its **role** and its **accessible name**. The role says what kind of thing it is - a button, a checkbox, a link. The name says *which* one: Buy single ticket, Add a passenger, Cancel and start again. A user who cannot see the screen walks the interface one node at a time and hears both. Role alone is useless on a screen with five buttons; name alone reads as prose and gives no hint that anything can be operated. The accessible name is deliberately short. Where a control needs more explanation than a name can carry, that supplementary text is an **accessible description** - a separate, longer, optional fact announced after the name. Stuffing an explanation into the name makes every future announcement of that control long, and speech has no scroll bar. Also note what a name is *not*: it is not an identifier used by code, not a variable, and not a test hook. It is user-facing content in the same sense the visible text is, and it should be written by whoever writes the visible text. ## Why every operable control must have one *4.1.2 Name, Role, Value* (Level A) requires a programmatically determinable name and role for every user-interface component. Level A is the conformance floor: this is not a refinement for mature products, it is the baseline. *2.4.6 Headings and Labels* (Level AA) adds that labels must actually describe purpose, so Submit on eleven different screens satisfies the first requirement and fails the second. | What the node exposes | What the user gets | Verdict | | --- | --- | --- | | Role only | button, five times, indistinguishable | Unusable | | Name only | a phrase that reads as ordinary text | Skipped | | Name and role | Buy single ticket, button | Usable | | Name that contradicts the visible text | the wrong word, and a failed voice command | Worse than useless | ## When the announced name and the visible label disagree Take a public transport ticketing kiosk. Its confirm control is printed **Buy ticket** and, because a designer renamed the copy late and nobody changed the annotation, it is announced as **Purchase**. Three separate audiences break, in increasing severity: 1. **Screen-reader users** hear a word that appears nowhere on the screen and nowhere in the help text. They can still operate the control, but every instruction written for the product - say, a support script telling them to press Buy ticket - now refers to something they cannot find. 2. **Users of speech output alongside the visible screen**, including many people with cognitive or reading disabilities, hear one word while reading another. The mismatch itself is the barrier. 3. **Voice-control users** simply cannot use it. Speech input matches the spoken phrase against the accessible name, and it matches it **literally**, not approximately. The user says the words printed in front of them, nothing happens, and there is no error message to explain why. There is no workaround available to them from the outside. That third case is the reason for *2.5.3 Label in Name* (Level A): where a control has a visible text label, the accessible name must contain that text. Contain, not resemble. A name of Purchase does not contain Buy ticket. A name of Buy ticket for zone 2 does contain it, and word order matters - putting extra words *before* the visible text can still defeat a spoken command on some input methods, so the safe pattern is visible text first, qualifier after. ## Where the mismatches come from On a 41-screen kiosk journey, name defects are rarely one bad decision. They accumulate: - **Late copy changes.** The visible text is updated and the annotation is not, because the two live in different places and only one of them is visible in review. - **Icon-only controls.** A control with no text at all gets a name invented by a developer rather than written by whoever owns the product's words, so it says what the code does instead of what the user sees. - **Duplicated names for distinct controls.** Nine screens each with a control named Continue is technically conformant and practically hostile, because the announcement carries no information about what the user is continuing to. - **Names that restate the role.** Naming a control Buy ticket button makes every announcement say button twice. - **Translation.** The visible text is translated and the annotation is not, or the two are translated separately by different people, and the pair drifts again in every language after the first. ## Catching them Automated inspection can tell you a name exists and can compare it against nearby visible text, so the empty-name and obvious-mismatch cases are cheap to find. It cannot tell you the name is the *right* word, that nine Continue controls are ambiguous, or that a name reads badly out loud. Those need a person operating the product and listening - and, for the voice-control case specifically, a person trying to drive it by speaking the words on the screen. Treat naming as a content review, not a code review, and it stops regressing.

  • Why is a control announced only as button still a defect, even though it does have a role?
    Because the role tells the user what kind of thing it is and nothing about which one. On a screen with several controls the announcement is identical every time, so the user has to activate them to find out what they do, and on a destructive action that is unacceptable. Role and name answer different questions, and a component that carries only one of them is half-described.
  • Is it enough for the accessible name to be similar to the visible text?
    No. Speech input matches literally, so a near-miss is a miss: a control printed Buy ticket and named Purchase ticket still fails a spoken Buy ticket. The rule is containment - the visible text appears inside the name, unchanged. Put the visible text first and add any qualifier after it, so the spoken phrase matches from the start.
  • Besides voice-control users, who else is hurt when the announced name differs from the visible label?
    Anyone who reads the screen while listening to it, which includes many people with reading or cognitive disabilities: they get two different words for one control and have to resolve the conflict themselves. Support staff are hurt too, because written instructions refer to words some users never hear. And any team member testing by listening sees a product that describes itself inconsistently.

The role is the job title and the accessible name is the person's name. Telling someone to go and press a button is useless in a room of five buttons.

saying these in an interview costs you the question

  • Says a control is fine because some text exists somewhere nearby
  • Confuses the accessible name with an identifier used by code
  • Thinks only screen-reader users are affected by a mismatch
  • Assumes a roughly similar name is close enough for speech input
  • Packs a whole explanation into the name instead of a description
  • Treats naming as optional for controls that look obvious