没人做的 AI 无障碍审计

打开你的智能体产品，开启 VoiceOver，然后发送任意提示词。如果你使用的是典型的带有内联推理过程的流式 UI，那么你在接下来的 30 秒内听到的内容并非你的产品。那是一股汹涌的局部 token 流、单词中间的重排、无人播报的状态变化，以及一段视力正常的用户选择查看、但盲人用户却无法逃避的推理独白。在舞台上演示效果极佳的界面，对于屏幕阅读器来说，是一场以语音形式发起的拒绝服务攻击。

这是 AI 团队中没有人会运行的审计。设计评审批准了流式动画。评估套件测量了回答质量。延迟仪表盘追踪了首个 token 响应时间。但这些工具都没有注意到，让某一群体感到产品快速且贴心的功能特性，却让另一群体完全无法使用。这种疏忽正开始出现在亲自诉讼申请中——过去十年一直在处理针对电商网站无障碍投诉的联邦法院，现在看到的 AI 界面相关投诉正急剧增加，据一家追踪机构报告，仅在 2025 年，同比增幅就达到了 40%。

智能体用户体验的无障碍问题与静态网页内容的无障碍问题并不相同。万维网用了几十年的时间在路标、标题层级和表单标签上实现了标准化。屏幕阅读器已经非常擅长播报这些内容。但屏幕阅读器从未被设计用来处理在 40 秒内逐个 token 变化的文本，或者是没有焦点边界的从“正在思考”到“正在调用工具”再到“正在编写”的状态转换，以及一段既不是最终输出也不是装饰、而是介于两者之间的并行内联中间推理过程。传统的 a11y 手册中没有关于这些内容的章节，而发布这些界面的 AI 团队正在重新经历网页端花费十年才修复的失败模式。

流式播报问题

首先崩溃的是动态区域。动态内容的惯例是使用 aria-live="polite"，它告诉屏幕阅读器等待当前播报结束，然后再播报变化。当变化是“你的消息已发送”这种单次触发的短字符串时，这很有效。但当变化是 40 秒响应时间内每秒 20 个 token，且每个 token 都是独立的 DOM 变动时，这就失效了。屏幕阅读器会看到一个包含 200 个播报任务的队列，根据实现方式的不同，它们要么以混乱嘈杂的方式播报每一个 token，要么因为动态区域不断重新触发而反复批量播放相同的局部字符串。

修复方案比“设置 polite 然后不管”要复杂一些。在流式传输阶段，动态区域应标记为 aria-busy="true"，这会告知辅助层在批处理进行时抑制播报。当响应完成时，你清除 aria-busy，就在那一刻，屏幕阅读器会将最终内容作为一段连贯的话语进行播报。这是几乎没有任何 AI 产品会发布的一行代码。原因并不是工程师不知道 aria-busy —— 他们可能从未用屏幕阅读器测试过，所以他们从未听过这种失败模式，也从未想到要去检查。

同样问题的更隐蔽版本出现在可见的“正在思考……”状态指示器上。视力正常的用户看到加载图标从“正在思考”变为“正在调用搜索工具”再到“正在编写回复”。这种状态变化是有意义的。而屏幕阅读器用户要么什么都听不到 —— 因为状态指示器不在动态区域内；要么会听到三次播报，打断了屏幕阅读器正在阅读的任何内容。这两种情况都不正确。修复方法是将状态保持在 polite 动态区域中，对播报进行防抖处理，以免微小的状态变化频繁触发，并提供一种让用户可以完全静音状态追踪的方法，如果他们只想听最终回复的话。

推理过程是一个噪音通道

内联推理是最严重破坏假设的功能特性。这种模式现在无处不在：模型发出一连串中间想法，UI 将其渲染在一个可折叠面板中，通常使用不同的排版处理以标记其为非最终结果。其意图是对产品友好的 —— 展示工作过程、建立信任、让用户能够跟进。对于视力正常的用户来说，这很有效。但对于屏幕阅读器用户来说，推理过程与最终答案属于同一个 DOM 流，通常位于同一个可滚动容器中，辅助层无法区分“这是模型在自言自语”和“这是用户要求的实际回答”。

结果就是，一位询问“法国的首都是哪里？”的盲人用户会听到模型口头叙述 17 秒的自我反思 —— “用户在询问关于法国的问题，我应该考虑他们是指法国本土的首都还是……” —— 然后才听到“巴黎”这个词。对于将 AI 作为辅助技术而非出于好奇而使用的用户来说，这就是一个能帮助他们的工具与一个浪费他们一上午时间的工具之间的区别。

准则是给推理过程分配其独立的 ARIA 角色和播报行为。视力正常的用户看到面板；屏幕阅读器用户则获得一个显眼的选项，从实时播报轨道中抑制推理内容，同时仍保持其按需可用。一些产品通过键盘快捷键来实现这一点，以便用户在需要时阅读推理过程；另一些产品则默认抑制推理，仅播报最终响应。这两种做法都是合理的。不合理的是将这两个流以完全相同的方式进行渲染，并寄希望于屏幕阅读器能自行搞清楚哪一个是答案。

键盘在第二轮对话时就失灵了

仅使用键盘来体验你的 Agent 产品。第一轮通常是没问题的。你可以通过 Tab 键跳转到输入框，输入提示词，然后按 Enter 键。现在阅读回复。你能通过 Tab 键跳转到建议的后续操作按钮（chips）吗？在市面上的一半产品中，答案是否定的——这些按钮是动态渲染的，且焦点顺序（focus order）没有更新，因此键盘用户必须通过 Tab 键切换二十个隐藏元素才能触达它们，或者更糟的是，焦点被困在了本该关闭的模态框（modal）中。

更深层次的问题在于，对话界面的焦点切换模式是键盘传统规范从未针对性调优过的。当一条新消息到达时，焦点应该去哪儿？如果你把它移到新消息上，就会中断用户正在进行的操作。如果你不移动它，用户就必须手动导航到新内容，而屏幕阅读器用户甚至根本不知道新内容的产生，除非你的活跃区域（live region）触发正确。大多数产品什么都不做——焦点留在原处——其结果就是键盘用户在模型每次响应后，都必须通过 Alt-Tab 和方向键在整个对话记录中翻找。

修复方法是建立一个明确对话状态的焦点管理约定。默认情况下，焦点留在输入框。新消息通过 live region 播报。如果用户想要进行交互，可以通过一个贴有清晰标签的键盘快捷键将焦点移至最新回复。工具调用和中间状态永远不应抢占焦点。承载确认对话框或设置面板的模态框模式应遵循实际的可访问模态框约定——焦点陷阱、按 Escape 关闭、焦点返回触发器——由于这些模式往往是从两年前最后一次审计过的组件库中搬来的，AI 团队可能已经违反了三次这些约定。

无人执行的审计现在有了代价

为什么在 2026 年这比 2024 年更重要，是因为监管和诉讼环境的变化速度超过了大多数 AI 产品团队的预期。2025 年，美国联邦法院处理的 ADA 诉讼案件同比增加了 40%，而那些让起草诉状变得易如反掌的 AI 工具，现在正被列为被告。加利福尼亚州的算法可访问性评估要求于 2026 年 1 月起对面向公众的 AI 系统生效。法院越来越多地引用 WCAG 2.2 作为事实上的标准，而 WCAG 2.2 的标准中，流式输出的 AI 界面经常在这些指标上失败——焦点可见、焦点不被遮挡、拖拽动作、目标大小——这甚至还没涉及到 live region 的问题，而这些问题根本不在 WCAG 中，因为该标准是在这种 UX 出现之前编写的。

执行审计的成本很低。而不执行审计的代价是一类不会出现在你的评测套件中、不会出现在你的延迟仪表板上、而是在有组织的原告律师事务所决定将 AI 产品作为下一个抓取目标（使用类似于 Lighthouse 的工具并批量提起诉讼）时首先暴露出来的失败。经历过电子商务可访问性周期的团队知道那意味着什么。还没经历过的团队即将领教。

审计到底包含什么

一场真正的 AI 可访问性审计不是一次勾选清单式的走过场。它是在开启辅助技术的情况下，对产品进行结构化的走访、记录和审查。最少需要进行三轮测试。

屏幕阅读器测试轮次是在 macOS 上使用 VoiceOver 或在 Windows 上使用 NVDA，戴上耳机，如果可以的话闭上眼睛进行。你发送三个提示词：一个短的，一个长的，以及一个触发工具调用的提示词。你记录下每一个错误的、缺失的、冗余的或被中断的播报。你记下推理路径（reasoning trace）在哪里渗入到了 live region 中。你记下哪些状态变化是无声的。你记下哪些最终回复在完成之前就被播报了，因为 aria-busy 从未被设置。仅这一轮测试通常就能在一个无人审计的产品中暴露出 15 到 30 个不同的问题。

键盘测试轮次是在拔掉触控板和鼠标的情况下进行的。你仅使用 Tab、Shift-Tab、Enter、Escape 和方向键导航整个对话。你尝试有视力用户可以进行的每一个流程——发送消息、编辑之前的消息、复制回复、打开设置、切换对话、重新生成。你记录下每一个无法完成的流程，每一个未正确生效的焦点陷阱，以及由于动态元素被移除且未预先移动焦点而导致焦点消失的每一个地方。

认知负荷测试是大多数团队会跳过的，也是最能发现前两轮漏网之鱼的一轮。你计时屏幕阅读器用户获取简单问题答案所需的时间，然后与有视力用户进行比较。如果比例差于 2:1——通常确实如此，而且差得很多——那么即使每一个单独的 ARIA 属性在技术上都是正确的，你仍然存在可用性问题。修复方法很少是增加更多的 ARIA，通常是做减法：更简洁的界面、压制推理过程、压缩状态，以及一条清晰的、不需要听模型“内心独白”就能从提示词直达答案的路径。

采取这一行动的团队会改变他们所构建的产品

进行这项审计还会产生一种次生效应，而执行审计的团队往往很晚才发现这一点。对屏幕阅读器友好的界面，对于多任务处理的有视力用户、使用语音助手驾驶的用户、在慢速连接下流式动画显示异常的用户，以及那些只想直接获取答案而不想看模型思考过程的用户来说，同样是更好的界面。无障碍审计不仅仅是一项合规练习。它是一种强制机制，能够促使界面保持克制。当每一种新的模型能力都演变成一种新的 UI 装饰时，AI 产品往往会忽视这种克制。

在 2026 年，如果一个团队在发布智能体产品前没有进行这项审计，他们就是在赌：赌其用户群中的残障人士不会投诉，赌监管机构不会跟进，赌为演示而做的设计选择不会最终演变成导致联邦诉讼的设计选择。在电子商务领域，这种赌注已经输了十年。没有任何结构性的理由表明这种赌注会在 AI 领域继续赢下去，反而有几个理由——诉讼数量、监管转变，以及比普通用户更依赖 AI 的辅助技术用户群——让我们有理由认为它会输得更快。

审计只需半天的工作量。审计结果只需一个冲刺周期的修复。产品变得更好，诉讼风险降低，而那些被设计评审遗忘的人群现在也能使用你构建的产品了。在 2026 年的 AI 产品路线图中，没有任何一个版本是不值得去做这件事的。