AI能够生成界面和执行任务，却不会天然理解屏幕阅读器、开关设备或语音控制用户如何操作软件。Salesforce在最新设计文章中强调，智能体不能替用户想象障碍，无障碍能力必须来自真实研究、明确需求和分层测试。

10月9日，Salesforce发布面向AI体验的无障碍设计方法。文章指出，团队容易假设智能体足够聪明，可以自动处理可访问性问题；但模型主要从现有网络内容中学习，而现实中的网页本身就存在大量无障碍缺陷。

动态生成界面会放大传统问题

传统软件至少拥有相对固定的页面结构，AI智能体却可能根据对话不断生成按钮、状态、表单和结果。如果没有焦点管理或实时区域提示，屏幕阅读器用户可能不知道内容已经更新；不断移动的界面会让行动障碍用户难以准确操作；表现不一致的智能体也可能给认知障碍用户带来额外负担。

Salesforce引用WebAIM 2026年的数据称，在其检测的100万个主页中，95%至少存在一项WCAG失败。同时，自动化工具通常只能发现约30%至40%的成功标准问题。这意味着通过一次扫描并不等于真实用户能够顺利完成任务。

从人物画像延伸到具体使用条件

Salesforce建议团队不要只写年龄、职业和业务目标，还要把视觉、行动和认知障碍维度纳入人物画像。比如，用户目标不只是“查看智能体的任务更新”，还要明确屏幕阅读器能够简洁说明发生了什么、动态更新后不会丢失当前位置，并允许用户验证结果。

这些信息不能靠设计师短暂蒙眼或一天不用鼠标来推断。团队应招募长期使用辅助技术的参与者，与残障权益组织合作，并为参与研究的用户提供合理报酬。真实用户是使用情境的专业人士，而不是产品发布前的象征性测试对象。

把研究结果写成可验证要求

需求需要能够直接进入设计、开发和验收流程。例如，当屏幕阅读器用户使用VoiceOver浏览智能体动态任务时，生成完成后应由实时区域通知新内容可用；键盘用户应能按照清晰顺序访问所有操作；动画和状态变化需要提供暂停、减少动态效果或替代说明。

文章还建议把这些验收条件加入提示词和设计系统约束，使AI编码或界面生成工具在创建组件时就考虑无障碍，而不是等产品完成后再补救。不过，提示词只能提醒规则，不能替代结构正确的组件和人工判断。

测试必须跨越三个层次

第一层是自动扫描，用于快速发现对比度、标签或结构等常见问题；第二层是键盘、屏幕阅读器和人工检查，验证焦点、顺序和动态反馈；第三层是由真实辅助技术用户完成关键任务，观察系统是否真的可理解、可控制和可恢复。

编辑观察：无障碍不是发布前的附加检查

企业应在智能体项目立项时就设置无障碍负责人和验收指标，选择登录、搜索、审批、支付、错误恢复等关键旅程开展测试。除了统计合规缺陷，还应记录任务完成率、迷失焦点次数、需要人工协助的比例，以及不同输入方式下的完成时间。

Salesforce的观点把问题从“AI是否聪明”拉回产品过程：智能体不会拥有残障用户的生活经验。如果研究、需求和测试缺席，再强的模型也可能生成不可用的界面。真正普惠的AI，必须让不同能力和不同辅助技术的用户都能独立完成任务。

配图为AIcent原创AI生成实景风格示意图，非官方新闻现场照片，不使用第三方新闻图片。

参考来源：Salesforce官方博客（2026年10月9日）。正文为基于官方消息的中文整理，编辑观察与事实披露分开呈现。