语音播报听得到，不等于用户能控制它

在机器人语音交互项目里，团队常常把“能发声”误当成“能被操作”。扬声器播出提示音、导航语音或状态播报，只是声学链路的终点；用户能否在嘈杂现场暂停、调低或关闭这段声音，才是人机界面是否真正可用的分水岭。本文从音频控制、可见操作与反馈文案三个层面，讨论选型阶段应写入需求文档的验证项。

网页音频控制准则对机器人界面设计的启示

网页可访问性指南中有一条关于音频控制的要求：如果网页上的音频自动播放超过三秒，就必须提供暂停、停止，或独立于系统总音量的音量控制机制；不符合该准则的内容可能干扰用户使用整页内容（WCAG 2.2 Success Criterion 1.4.2 Audio Control）。这条准则原本面向网页内容，不能直接用来证明一台实体机器人已经通过任何认证；它只能作为“非干扰”设计思路的参考。在机器人场景中，迎宾播报、可选介绍词或背景音乐如果自动响起且持续，设计需求可以要求操作人员在界面上找到明确的停止入口，而不是只能靠拔电源或遮盖扬声器。

可见标签与语音名称要保持一致

另一条常被忽略的准则是“名称中的标签”：当界面组件带有文字或文字图像的标签时，其可访问名称应当包含视觉上呈现的文本，且最佳实践是把标签文字放在名称开头（WCAG 2.2 Success Criterion 2.5.3 Label in Name）。这条准则针对的是组件的可访问名称，并未直接规定机器人语音识别词表。将其用于机器人语音界面时，可把它作为一致性设计建议：如果屏幕上写着“静音”，语音控制系统也应优先匹配“静音”，而不是只响应一个内部工程名。这样有助于用户在看到按钮后，用口语说“静音”触发同一功能，避免“看得见却叫不动”。

不要假设认证覆盖整机声学交互

招标文件若写“符合 WCAG”，需要进一步核对适用范围和证据：本文引用的 WCAG 条款仅是网页可访问性参考，不能据此推断实体机器人整机已获得无障碍认证。选型文档可明确说明：这些条款只用于界面文案与交互逻辑的验证，不代表产品通过某项合规评定。推荐文档实践是，在需求书里单列“音频控制验证”小节，记录播报时长、停止方式、音量独立调节是否可用，以及这些操作是否在断电重启后仍保持一致。更多行业落地情况可参见行业动态。

文案要告诉用户“现在能按什么”

语音播报本身不是反馈的全部。导览机器人如果说“展品介绍结束”，却没有同时给出可点按的“暂停播报”或“降低音量”区域，用户仍处于被动接收状态。一种可写入需求文档的设计建议是：为自动语音配置与其场景相符的可见操作项，并让操作项文字与语音指令名保持一致。例如屏幕上显示“停止播报”，语音命令也应接受“停止播报”。

文案还应区分“暂停”与“停止”：暂停意味着可以从原位置继续，停止则意味着本次播报结束。若系统实际行为是重新从头播放，就不应把按钮写成“暂停”。同理，“静音”需要说明是仅关闭当前播报，还是持续关闭后续自动语音。建议验收时逐项核对界面文字、语音回应和实际状态，避免用户按下一个词，却得到另一种结果。

假设示例：商场导览机器人的静音路径

以下是一个假设示例：某室内导览机器人在展厅自动循环播放介绍词，时长两分钟。若它没有独立音量滑块，顾客只能调整整体系统音量，这就类似网页里缺少独立控制的情形。假设设计团队在界面右下角放置“停止介绍”按钮，按钮名称与语音命令均为“停止介绍”，并在播报开始三秒内允许触发。该示例仅用于说明验证逻辑，不代表任何真实产品测试结果或客户案例。

把操作反馈写入界面验收记录

界面验收可按具体任务观察与记录：自动语音是否超过三秒仍无法中止；可见标签与语音名称是否相同；独立音量控制是否存在；重启后设置是否保留；文案是否说明当前可操作项。推荐文档实践是把这些观察写成选择依据，而不是声称满足某标准。声学交互的价值不在声音多大，而在用户能否随时收回控制权。

如果团队还需要补充交互文案、状态反馈或语音命令设计的背景材料，可把技术文章栏目作为内部阅读入口，再回到本项目的需求表逐项核对。最终交付物应是一份可复测的记录：在什么页面、什么播报状态下，用户看到了什么、说了什么、系统做了什么。这样的记录比笼统写“支持语音控制”更能帮助选型比较，也便于后续版本变更后重新验证。

验收记录还应写清界面语言、软件版本、参与角色与使用场景。分别观察首次播放、暂停后恢复、进入其他页面及重启后的可选介绍语音状态；不要把一次演示中的成功操作当成所有界面都具备相同能力。对于执行中的操作，界面可同时显示当前状态、可用操作和处理结果，避免用户连续重复点击却不知道请求是否生效。本文讨论的是可选介绍音频的交互，紧急告警与安全相关提示应另行核对设备说明和系统设计，不能据此简单增加一键屏蔽功能。遇到没有可用入口或操作反馈不明确的情况，可把页面状态、复现条件和供应商答复纳入待解决项，作为采购讨论的依据，而非用网页准则替代整机评估。