AI 界面中无人关注的可访问性鸿沟

大多数 AI 团队都会对其落地页进行无障碍审计。但几乎没有人对聊天界面本身进行审计。这种差距并非源于懒惰 —— 而是因为工具根本不存在。WCAG 2.2 没有针对流式内容的成功标准，没有针对非确定性输出的标准，也没有针对逐个 token 传输的指南。这意味着目前每个将响应流式传输到 <div> 中的 AI 产品都处于合规灰色地带，同时破坏了很大一部分用户的体验。

这并不是一个微不足道的边缘情况。盲人和低视力用户报告称，寻求信息是他们使用 AI 的首要场景。患有诵读障碍、ADHD 和认知障碍的用户正积极尝试使用 AI 工具来减轻阅读负担 —— 而默认的实现模式却实际上让情况变得更糟。

为什么流式传输会破坏屏幕阅读器

让 AI 界面感觉响应迅速的逐个 token 流式传输模式，在结构上与 ARIA live regions 的工作方式不兼容。

当你的 LLM 流式传输响应时，典型的实现方式是在 token 到达时将其丢入容器中 —— 每秒更新 DOM 5 到 20 次。在屏幕上，这看起来像打字机效果。但对于屏幕阅读器来说，这是一场灾难。

这里有三种不同的失败模式：

重新朗读风暴。 如果你在流式传输容器上使用 aria-atomic="true"，每当有新 token 到达时，整个累积的响应都会重新朗读。屏幕阅读器用户在 500 字的响应中，每出现一个 token 就会听到第一个词，然后是前两个词，接着是前三个词。用户学不到任何东西；他们听到的只是噪音。

无声更新。 如果你使用 aria-atomic="false"（更合理的选择），频繁的 DOM 更新会导致屏幕阅读器完全跳过更新。NVDA、JAWS 和 VoiceOver 处理高频实时区域变化的方式各不相同，而且在负载下都会丢失内容。视障用户收到的是零碎、部分的响应 —— 甚至什么都收不到。

思考状态盲区。 无论是流式传输还是“正在输入...”的旋转图标，都没有提供系统正在处理的可访问信号。依赖屏幕阅读器的用户无法区分“AI 正在生成”和“页面已崩溃”。Microsoft Copilot 发布时没有任何关于处理状态的无障碍指示 —— 这一失败直到外部无障碍审计后才暴露出来。

根本问题在于 ARIA live regions 是为有限的、离散的更新而设计的：股票价格变化、表单错误出现、通知弹出。它们从来不是为在 10 到 30 秒内以数百个微小增量到达的内容流而设计的。

WCAG 的空白是真实且结构性的

WCAG 2.1 和 2.2 并没有涵盖流式 AI 响应。最接近的适用标准是 SC 4.1.3（状态消息），它要求在不获取焦点的情况下，状态更新必须是程序可确定的。该标准是为“表单提交成功”之类的场景编写的 —— 而不是为了“这里有 800 个 token 的生成文本”。

W3C Web 无障碍倡议（WAI）发布了 ARIA live region 指南，建议对动态内容使用 aria-live="polite" 和 aria-atomic="false"。该指南是建议性的，而非规范性的。而且它假设更新是以可预测的块到达，而不是以 token 的速度。

这产生了一个真实的组织问题：你无法根据 WCAG 审计 AI 聊天界面并获得有意义的结果。自动化的无障碍检查器无法评估流式响应是否可访问，因为没有标准定义什么是“可访问的流式传输”。想要合规的团队没有可以遵守的规范。

这意味着 AI 界面中的无障碍性需要工程判断，而不仅仅是清单合规。WCAG 告诉你必须做什么；它没有告诉你在这里该做什么。

认知负荷是问题的另一半

屏幕阅读器用户是最显而易见的无障碍关注点，但患有认知障碍的用户面临着同一问题的不同版本：AI 响应在设计上就是冗长的。

一个提示良好的 LLM 会生成全面、微妙、多段落的回答。这就是它的功能。对于患有诵读障碍的用户，阅读同样的响应所需的精力远远超过了信息密度所值的程度。对于 ADHD 用户，密集的段落响应会在重点传达之前中断注意力。对于患有认知障碍的用户，默认 AI 响应的巨大长度可能会产生疲劳，阻碍任何信息的留存。

讽刺的是，许多用户专门转向 AI 工具来减轻认知负荷 —— 使用 AI 来总结、解释或起草，而不是处理原始源材料。旨在帮助他们的工具生成的内容却让同样的问题变得更糟。

大多数聊天界面没有提供对响应长度或格式的控制。需要简短回答的用户必须重新提示。需要要点列表而非散文的用户每次都必须明确说明。这些都不是合理的便利措施；它们要求用户知道要请求什么，并且在每次会话中都要重复。

四种确实有效的设计模式

好消息是，工程解决方案已经非常明确，只是尚未被应用到产品中。

摘要优先输出。在流式传输完整回答之前，先发送 1–3 句的摘要，并将其作为第一个可见元素进行渲染。认知障碍用户可以阅读摘要并决定是否阅读完整回答。屏幕阅读器用户在流式传输开始前，能获得一段完整且有界的内容。流式部分随后仍可继续，但关键信息已经传达。

用结构化输出替代流式文本。如果你约束你的 LLM 返回结构化的 JSON —— 一个 summary 字段、一个 key_points 数组、一个 action_items 列表 —— 你就可以将响应渲染为语义化的 HTML：标题、项目符号列表、表格。结构化输出以完整文档而非 Token 流的形式到达，彻底消除了 ARIA live region 的问题。对于喜欢的用户，它们可以渲染为正文；对于需要快速浏览的用户，可以渲染为要点；对于无法阅读屏幕的用户，可以进行语音播报。同样的响应，多种格式，一套系统。

用户控制的详细程度。一个简单的设置 —— 简洁 / 标准 / 详细 —— 让你能够选择适合你认知风格的回答长度。患有多动症（ADHD）且希望获得单句回答的用户可以将其设为默认。需要全面解释的用户也能如愿。该设置应在不同会话中保持并自动应用；要求用户在每个 Prompt 中都指定偏好并非无障碍设计。

针对不可避免的流式传输采用无障碍 ARIA 模式。当流式传输是正确的产品选择时，请遵循以下实现规则：初始化空的 live regions，并等待 2–3 秒后再注入内容，以便屏幕阅读器识别该区域的存在；使用 aria-live="polite" 而非 assertive；使用 aria-atomic="false" 配合 aria-relevant="text" 来仅播报新增内容；在流式传输期间添加 aria-busy="true" 并在完成时切换为 false；在流式传输结束时播报一个有界的摘要，以便屏幕阅读器用户知道响应已完成。请使用 NVDA 和 JAWS 进行测试，而不仅仅是 VoiceOver —— 不同屏幕阅读器的行为差异巨大。

缺失的一环：测试

大多数团队没有使用辅助技术测试 AI 界面的流程。自动化工具无法评估流式内容。人工审计需要大多数前端工程师所不具备的屏幕阅读器熟练度。而且每当 AI 生成不同的回答时，测试覆盖面都会随之变化。

实际的可行方案是分层的。为静态结构添加自动化检查：响应是否被包裹在具有正确 Role、Label 和标题的语义化容器中？自动化 ARIA live region 冒烟测试：该区域是否存在，是否初始化为空，是否触发了 aria-busy 状态变化？然后，将人工屏幕阅读器测试添加到你对任何响应渲染管线变更的“完成定义”（Definition of Done）中 —— 不是针对整个 AI 功能，而仅仅是渲染层。

渲染层比 AI 输出更稳定。使流式内容具备无障碍性的模式不会随着模型说的话而改变。测试容器，而不是内容。

未来展望

在美国，26% 的成年残疾人并不是边缘案例。到 2025 年，AI 工具将触及全球 3.78 亿人。对于其中许多用户来说，这是第一个能真正减少他们日常获取信息摩擦的工具。如果交付 AI 输出的界面默认就不具备无障碍性，那么这个承诺将立即破灭。

WCAG 标准的差距不会很快缩小。W3C 的进程缓慢，而流式 LLM 响应是一个非常新颖的交互模式，规范性指导可能还要等 2–3 年。那些等待规范出台才去遵循的团队，在未来几年内交付的都将是缺乏无障碍性的产品。

这些模式现在已经存在。摘要优先输出、结构化响应、用户控制的详细程度以及正确的 ARIA 实现，都不需要等待标准出台。它们需要的是一个深思熟虑的决定：将无障碍性视为渲染契约的一部分，而不是发布前才去核对的项目清单。

大多数团队尚未做出这个决定。这正是目前无人填补的空白。