Duplicate on-screen names need numbers so voice can disambiguate

What it is

Three “Delete” controls on one screen, twenty “Play” labels in a list: the visible words are identical. Even a perfect utterance does not say which one. Voice control disambiguates with a number overlay (“Show numbers”): the user says “Click 7.” Those controls must exist as separate namable objects so a number can land on each. Otherwise the collision is not a copy problem. It is a selection failure.

Why it happens

Name matching is one-to-many on a duplicate set. Without a second key (an index, a spatial command), the matcher can only refuse or pick the first. Numbers pull “which one” out of semantics and into a spatial index. That requires each target to be its own accessibility node with a hittable on-screen box. A custom list painted as one blob, rows as pixels, gets one number on the whole list; in-row actions cannot be named.

The more stable fix is fewer duplicates: the second and third “Delete” become “Delete draft” and “Delete account.” Numbers are the channel when duplicates cannot be avoided (repeated rows, repeated cards), not a licence to name every button the same.

Studying it

Build a screen of several controls with the same visible label. Turn on voice-control numbers. Record whether a number appears on every instance, whether speaking the number hits the intended one, and whether speaking the label hits a different one.

Independent variables: duplicate count, exposure as separate accessible objects, virtualized node reuse. Dependent variables: number coverage, accuracy of spoken numbers, mis-hits when the label is spoken.

Virtualized lists reshuffle numbers after a scroll. Test “scroll, then speak”: an old number the user memorized will go stale.

Where it stops holding

A unique name on screen does not require numbers; the label is enough. Grid picking (nameless canvas coordinates) is a different overlay; do not accept it in the same pass as control numbers. If the number glyph sits opaque on the control and hides the judgment, that is occlusion, not this disambiguation claim. Two near-homophones collapsing in the recognizer is a recognition error, not a duplicate-name problem.

Applying it

• Distinguish visible names where you can. For unavoidable repeated rows, make every row and every in-row action its own accessible object so platform numbers can land separately.
• Do not swallow a column of repeated buttons under one poster-sized hit layer.
• Verify: speak a number for each of three identical “Buy” actions. A missing number, or a number that hits the whole card instead of the button, is a disambiguation failure.

Related

• Same group: J3.12.1 Voice-selectable controls need an accessible name that matches the visible label · J3.12.2 Icon-only buttons cannot be reached with a natural spoken command · J3.12.4 A voice-control grid must not hide the content it is meant to target
• Nearby: J5.04 Voice Control · J5.02 Accessibility Tree and Roles
• Search terms: show numbers · voice disambiguation · duplicate accessible name