J5.04.1voice control设计研究
用户通过朗读可见标签来操作
别名: 语音控制 · Voice Control · Voice Access
概念解释
看见按钮上写着「提交」，就说出「点击提交」。语音控制（voice control）作为辅助技术，靠的是用户把屏幕上读到的字念出来，系统再把这句话匹配到可操作对象。它不是另一套隐藏口令，词表就是界面上的可见标签。
机制
这类用户通常能看见屏幕，手或指针用不稳或不便用。策略因此是「看 → 读 → 说」，与屏幕阅读器的「听 → 跳」相反。匹配器拿用户的话语去对控件的可访问名称；用户却是对着可见文字组织那句话。两边对得上，一次命中；对不上，用户会重复可见标签，而不是去猜内部字段名。
第二层：命令空间是当前屏幕上的可见词，不是应用预设的「打开设置」这类全局口令。界面换一套文案，可说的命令就换一套。语音控制把可见 UI 当成口语脚本，所以标签写什么，用户就会说什么。
怎么研究
打开系统语音控制（macOS / iOS 的 Voice Control，Android 的 Voice Access），只许说话，不许点。让人完成「提交订单 / 打开筛选 / 删除一项」，记录第一句口令是不是把可见文字原样读出。
自变量：可见标签是否存在、标签是否唯一、是否与内部名称分离。 因变量：首次口令命中率、改口次数、放弃改用手势的次数。
不要让被试先看文档里的「推荐口令」。测的是看见什么就说什么，不是他们能不能背出隐藏命令。
边界
纯听的用户（同时使用阅读器）组织口令的材料是播报而不是可见字，这条会弱。系统自带的「显示编号 / 显示网格」是匹配失败后的退路，不应当成主路径——主路径仍是朗读可见标签。方言、口音、专名会降低识别率，那是识别层的问题，不是「用户不该读标签」。没有可见文字的控件，这条机制没有原料。
怎么落地
- 每个要被语音点到的对象，屏幕上要有用户能念出来的词。
- 把主操作的可见文案写成用户会说的那句，而不是图标加一段只有开发者知道的内部名。
- 验证：打开语音控制，对着屏幕把按钮上的字读出来。读可见标签就能点中，这条机制才成立；必须先问「这个叫什么」就还没把它当成口语脚本。