视障用户揭开了Agent“已完成”的盲区

一位视障用户让 Agent 把 Word 文档保存成 PDF。Agent 找到了导出入口，选择了 PDF 格式，整个过程几乎没有出错，却漏掉了最后的“保存”。

对于能够看到屏幕的用户，这可能只是一次容易发现的疏漏。对于无法通过画面确认结果的用户，Agent 一旦宣布任务完成，用户便很难知道文件实际上并未生成。

Jakob Nielsen 在 9 月 25 日讨论了一项关于视障用户使用电脑操作 Agent 的研究。研究者邀请 8 位长期使用屏幕阅读器的参与者，在三周内通过一个名为 OLLA 的界面处理自己的日常工作。实验共记录 1,258 条指令，涉及 Word、Excel、PowerPoint 等 12 个应用，包括文档编辑、表格操作、设置调整与文件管理。

运行期间使用的 Agent 完整完成了 52.5% 的指令，部分完成了 34.3%，完全失败的比例为 13.2%。它已经可以处理相当一部分真实任务，失败却往往发生在用户最难察觉的位置。

有时，Agent 完成了“将字体改为 Arial”，却忘记同一句指令中的“字号改为 14”；有时，它没有找到隐藏在对话框里的设置，便告诉用户这个选项不存在；还有一次，它在 Excel 中不断重复创建工作表，因为没有正确识别任务已经完成。

这些案例暴露出电脑操作 Agent 与普通聊天产品之间的差别。聊天回答即使不准确，用户通常仍能阅读、判断和追问。Agent 直接改变文件或系统状态以后，用户需要知道的不只是它做过哪些动作，还包括原先提出的每一项要求是否真正得到满足。

视障用户把这种需求呈现得格外清楚，因为他们无法随时“看一眼屏幕”补足系统没有说明的信息。

研究中的参与者希望 Agent 告诉自己当前位于什么位置、界面上有哪些选项、刚才的操作改变了什么。卡在陌生菜单时，他们有时只需要针对当前位置的帮助，并不希望 Agent 接管整个任务。有人还希望它解释应用的结构和操作步骤，以便下次能够自己完成。

由此看来，面向视障用户的 Agent 不只是一个可以通过语音使用的自动化工具。它需要建立一套完整的非视觉界面：过程如何播报，状态如何描述，失败后从哪里继续，结果又如何验证。执行能力解决的是“替用户操作”，这些反馈机制解决的则是“让用户仍然掌握操作”。

研究还揭示了一个与所有 UI 设计师有关的变化。OLLA 在操作电脑时，同时读取屏幕截图和 Windows 的 UI Automation 结构。后者包含按钮名称、控件角色、层级关系和当前状态，也是屏幕阅读器理解界面的重要依据。一个没有准确名称的按钮、一个未向系统暴露状态的组件，可能同时阻碍屏幕阅读器和 Agent。

另一项无障碍研究提供了更直接的数据。同类电脑操作 Agent 在可以自由使用鼠标时完成了 78.3% 的任务；限制为仅使用键盘后，完成率降至 41.67%。两项研究采用不同任务和条件，数字不能直接比较，但结果指向同一问题：当前 Agent 仍然主要按照视觉用户和鼠标操作的方式理解界面。

Nielsen 对 Agent 改善无障碍体验的速度持乐观态度。不过，这次实地研究只有 8 位参与者，也没有设置同期的屏幕阅读器对照组，尚不足以证明 Agent 已经优于现有辅助技术。

但它对界面设计提出的要求，确显得十分明确，控件必须具有可读取的语义，任务状态必须能够被准确描述，完成提示必须对应一个真正可以验证的结果。

当 Agent 开始替用户使用界面，无障碍信息不再只服务于人，也开始决定 Agent 能否正确理解这个界面。