An Accessible Name Is Not a Spoken Command Recording

When someone speaks to a cooking-robot companion interface, the words they say are not the same thing as the interface's accessible name. This distinction matters for procurement, for accessibility planning, and for setting realistic expectations about what audio control means in practice. An accessible name is a label that assistive technologies and speech-driven interfaces use to identify a control; it is not a transcript, a recorded command, or a promise about how the system will interpret spoken input. Understanding that difference helps teams ask better questions during evaluation and avoid conflating visible labels with audio behaviour.

Visible Labels and Accessible Names Are Related but Not Identical

WCAG 2.2 Label in Name requires the accessible name to contain the visually presented text for components whose labels include text or images of text. It is not a demand that the name contain only that text. In a hypothetical companion interface, a visible Start Cooking label could also appear within a longer accessible name. That correspondence helps a person use the visible label in speech-based navigation; it does not record anything the person actually said. Reviewers should inspect the name and visible label together rather than treating one as a transcript of the other.

What Audio Control Actually Covers

WCAG 2.2 Audio Control addresses audio that plays automatically on a web page for more than three seconds. It requires a way to pause or stop it, or a way to control that audio’s volume independently of overall system volume. This is a web-content condition, not a microphone-quality or speech-recognition specification. A reviewer should record what page behaviour was checked before drawing a conclusion about that criterion.

Scope of Audio Control in a Companion Interface

A cooking-robot companion interface may include instructional audio, alerts, or confirmation tones delivered through a web panel. Audio control, in the sense defined by WCAG 2.2, applies to that web-delivered audio. If the robot also produces sounds through its own speakers or responds to voice commands through an onboard microphone system, those behaviours fall outside the web-audio criterion. This separation is useful during procurement because it prevents a misunderstanding: that passing an audio-control check means the entire system's audio pipeline has been validated. It has not. It only means the web content meets the audio-control criterion. For a fuller picture, teams should ask vendors to describe the robot's sound hardware, the speech-recognition engine, and how the companion interface relates to those subsystems. Internal technical documentation, such as technical reference material, may help map these boundaries, but the criterion itself stays within the web-content domain.

Common Misconceptions About Speech and Labels

An accessible name can be used by speech-input software to identify a control. It is therefore relevant to voice interaction, but it remains a property of the interface, not a recording of an utterance or a score for recognition performance. A useful evaluation separates the label/name correspondence from tests of how a chosen speech-input system behaves. Audio Control raises another question about automatically played output; passing it does not establish that spoken input was understood. The distinctions concern evidence, not isolated technologies that can never interact.

Questions to Ask During Evaluation

Questions for evaluation can start with the evidence available: which visible labels were compared with accessible names, which automatically played audio was examined, and which speech-input behaviour was tested separately? Related reading in the article archive may help frame those questions, but an archived article does not supply test results for the product under consideration.

Why the Distinction Matters for Accessibility Planning

Accessibility planning for a cooking-robot companion interface involves more than checking a single criterion. It involves understanding how visible labels, accessible names, and audio behaviour work together. A user who relies on speech input needs accessible names that are predictable and distinct. A user who relies on a screen reader needs accessible names that convey the same information as visible labels, or more. A user who is sensitive to unexpected audio needs reliable control over any sound the web panel produces. None of these needs is automatically met by a single feature or a single test. They require deliberate design and deliberate evaluation. Keeping the terminology precise — accessible name, visible label, audio control — supports that planning by preventing the assumption that one feature covers all three concerns.

Editorial Suggestions for Procurement Teams

As an editorial suggestion, procurement teams might include a terminology section in their evaluation documents that defines visible label, accessible name, audio control, and speech-recognition scope separately. This does not create an obligation, but it reduces ambiguity. Another suggestion is to request that vendors provide a mapping between visible labels and accessible names for all primary controls in the companion interface, without requiring disclosure of the speech-recognition command set. A third suggestion is to test audio control on the web panel independently from the robot's onboard sound system, so that the results reflect the criterion's actual scope. These are editorial suggestions, not institutional requirements, and they can be adapted to the team's context. The goal is to keep the evaluation grounded in what each term actually means, rather than in assumptions carried over from other domains.