你的聊天机器人真的人人都能用吗？

聊天机器人存在无障碍问题

客服聊天机器人已成为许多数字产品的主要——而且往往是唯一——的联系方式。预期很明确：如果你需要帮助，就打开聊天窗口。而如果聊天窗口对你不起作用，通常也就别无他法了。

对残障用户而言，这种局面常常令人难以承受。大多数商用聊天机器人都无法满足基本的无障碍要求。屏幕阅读器用户听不到陆续到达的消息。键盘用户被困在聊天组件里出不来。运动障碍用户遇到的触摸目标太小，难以稳定点击。认知障碍用户面对的是大段文字，而在查询被误解时又没有清晰的补救途径。

这在伦理和法律层面都很重要。自 2025 年 6 月起生效的《欧洲无障碍法案》涵盖了适用范围内企业的数字客服渠道——其中就包括聊天机器人界面。美国的《美国残疾人法案》（ADA）已在网页无障碍诉讼中被适用于聊天机器人。如果聊天机器人是一条主要的服务渠道，那么一个无法访问的聊天机器人就等于一种服务排斥。

聊天机器人最常见的七大无障碍问题

1. 缺少 ARIA 实时区域

当聊天窗口中出现一条新消息时，屏幕阅读器用户需要能够听到它。但屏幕阅读器只会朗读那些被告知是重要且动态的内容。如果没有一个包裹聊天消息容器的 ARIA 实时区域，消息虽然在视觉上出现了，但对屏幕阅读器用户来说却完全悄无声息。

<!-- 没有实时区域：新消息不会被朗读 -->
<div class="chat-messages">
  <!-- 消息在此处动态添加 -->
</div>

<!-- 有实时区域：新消息一到达即被朗读 -->
<div
  class="chat-messages"
  role="log"
  aria-live="polite"
  aria-label="聊天对话"
>
  <!-- 消息在此处动态添加 -->
</div>

role="log" 是 ARIA 中专门为聊天对话和消息流定义的角色。aria-live="polite" 会在用户停顿之后再朗读新内容——对于对话场景而言，这比 assertive 更少打扰。

2. 键盘陷阱

键盘陷阱是指用户用 Tab 键进入某个组件后，就再也无法用 Tab 键离开——被困住了。聊天机器人组件是最常出现键盘陷阱的地方之一。

解决办法需要实现恰当的焦点管理：Tab 和 Shift+Tab 必须能在聊天窗口内的可交互元素之间导航，而 Escape 必须能关闭聊天窗口，并将焦点返回到触发它的那个元素。WCAG 2.1.2 无键盘陷阱（A 级）涵盖了这一要求。

测试这一点很简单：仅用键盘打开你的聊天机器人，用 Tab 键遍历其中所有可交互元素，并确认你可以通过 Escape 键或一个清晰可见的关闭按钮退出。

3. 色彩对比度不足

聊天机器人常常采用品牌色渲染，而品牌色往往没有对照 WCAG 对比度要求进行测试。常见的问题有：

聊天气泡文本相对于气泡背景达不到 4.5:1 的对比度
输入框占位符文本低于对比度阈值
采用非常浅的灰色的时间戳文本

对比度要求适用于聊天机器人界面，正如它适用于你网站的其余部分一样——组件没有例外。

4. 未标注的输入框和按钮

聊天输入框——“输入你的消息……”——必须有一个以编程方式关联的标签，而不能只有占位符文本。占位符文本在用户一开始输入时就会消失，无法可靠地替代标签。

发送按钮、最小化按钮、关闭按钮以及任何其他可交互控件都必须有可访问的名称。一个只有图标、既无文本也无 aria-label 的”发送”按钮，会被屏幕阅读器朗读为”按钮”，而不会说明其用途。

<!-- 缺少标签：不合格 -->
<input type="text" placeholder="输入一条消息……">
<button><svg><!-- 发送图标 --></svg></button>

<!-- 有标签和 aria-label：合格 -->
<label for="chat-input" class="sr-only">输入你的消息</label>
<input type="text" id="chat-input" placeholder="输入一条消息……">
<button aria-label="发送消息">
  <svg aria-hidden="true"><!-- 发送图标 --></svg>
</button>

5. 触摸目标对运动障碍用户来说太小

WCAG 2.2 在 AA 级引入了 2.5.8 目标尺寸（最小），要求可交互元素的最小目标尺寸为 24×24 CSS 像素。许多聊天机器人界面将关闭、最小化和表情按钮设为 16–20 像素——远低于这一阈值。

对于患有运动障碍、震颤或精细动作控制减弱的用户而言，小目标是真正无法使用的。聊天机器人的操作按钮正是最常受影响的界面元素之一。

6. 没有超时警告或会话延长

许多聊天机器人会在设定的时段后结束一次不活动的会话。当这种情况在毫无警告下发生时，那些需要更长时间来撰写或阅读消息的用户——包括许多认知或运动障碍用户——可能会在没有任何机会延长会话的情况下丢失他们的对话。

WCAG 2.2.1 时限可调整（A 级）要求，当设定了时间限制时，用户必须能够关闭它、延长它，或者该限制至少为 20 小时。一个在不活动 5 分钟后就在无警告下终止会话的聊天机器人是不合规的。

7. 语言复杂且无错误补救

聊天机器人只有在用户能够有效地与之沟通时才有用。对于认知障碍、学习障碍或识字水平较低的用户而言，一个使用行话、提供大段无结构文字，或在无法理解查询时悄然失败的聊天机器人，在功能上是无法访问的。

无障碍的聊天机器人内容应当：

使用通俗易懂的语言（短句、常用词）
将回复拆分成便于扫读的单元，而不是呈现大段落
提供清晰的错误补救：当机器人无法理解时，它会明确说明，并提供具体的替代方案
支持用户重新组织查询，而不只是说”我没听懂”

与聊天机器人尤其相关的 WCAG 2.2 新准则

WCAG 2.2 新增了几条对聊天界面尤其适用的成功准则：

2.4.11 焦点不被遮挡（最小）——AA 级。当聊天组件打开时，它不得将获得焦点的元素完全隐藏在其后。许多聊天组件会浮现在页面内容之上，当用户用 Tab 键浏览下方页面时，会遮挡获得焦点的元素。

2.4.12 焦点不被遮挡（增强）——AAA 级。获得焦点的元素应当完全可见。

2.5.7 拖动动作——AA 级。如果你的聊天组件可以通过拖动来重新定位，那么必须存在一种单指针替代方式。

2.5.8 目标尺寸（最小）——AA 级，如上文所述。

如何测试你的聊天机器人

仅用键盘：不使用鼠标打开聊天窗口。用 Tab 键遍历所有元素。核实你能否仅用键盘输入、发送消息并关闭组件。确认你可以用 Escape 键退出。
屏幕阅读器：打开 NVDA（Windows，免费）或 VoiceOver（Mac/iOS，内置），并与聊天窗口交互。核实消息在到达时是否被朗读。核实输入框和按钮是否被正确标注。
缩放至 200%：核实当文本被放大时，聊天界面不会溢出或遮挡页面内容。
对比度检查：使用 axe DevTools 或 WAVE 这类浏览器扩展来检查聊天界面中的对比度。
移动端：测试触摸目标尺寸，并核实聊天窗口能否配合 iOS/Android 的无障碍功能（VoiceOver、TalkBack）正常工作。

如果你要集成第三方聊天机器人，请在选择之前评估供应商的无障碍情况。索取他们的 VPAT（自愿产品无障碍模板），以了解他们所声称的符合等级。亲自测试该组件——供应商的声明无法替代直接测试。

从一开始就将无障碍构建进聊天机器人，要比事后改造便宜得多。如果你正在评估聊天机器人平台，在做出决定之前，先用这份清单逐一检验每个候选方案。

如需对你的聊天机器人以及数字客服体验的其余部分进行全面评估，请联系我们的团队，或从对你面向公众的页面进行一次免费扫描开始。