只用键盘，能否完成「输入 → 生成 → 复制结果」并知道何时完成？
AI 功能的可访问性常被忽略
AI 功能常做成"输入框 + 结果区" ✗ —— 看起来简单 ✔，
但对键盘用户与屏幕阅读器用户来说常常完全不可用 ✔：
结果区更新了没有播报 ✗、流式输出把焦点弄丢 ✗、加载状态读不出来 ✗。
这不是小众问题 ✔：除了视障用户 ✔，键盘用户、临时受伤、嘈杂环境的人都会受影响 ✔。
一、六个最常见的问题
```
① 结果区更新后没有 aria-live 播报（屏幕阅读器不知道有新内容）
② 流式输出逐字插入 DOM，导致焦点跳动与重复播报
③ 加载/生成中用纯图形表示（无文字状态）
④ 只能鼠标点（示例卡片、复制按钮、展开按钮）
⑤ 对比度不足（浅灰提示文字）
⑥ 错误提示只靠颜色区分（红/绿）
```
第 ② 项最典型 ✗→✔：流式输出需要节流播报 ✔（例如每 1~2 秒合并播报一次 ✔），
而不是每个字符都播报 ✔（那会变成噪音 ✔）。
二、五条基本要求（可查可测）
1. 状态可播报（aria-live="polite" + 明确文案 ✔）；
2. 全键盘可达（Tab 顺序合理、有可见焦点框 ✔）；
3. 流式输出节流播报 ✔（并给出"生成完成"的终态 ✔）；
4. 对比度达标（正文 ≥ 4.5:1 ✔）；
5. 不只用颜色传达信息（"错误：…" 文字 + 图标 ✔）。
三、怎么验（不用专业工具也能做一半）
· 只用键盘走一遍主流程（Tab/Enter/Space ✔）；
· 打开系统屏幕阅读器听一遍（Windows 讲述人 / macOS VoiceOver ✔）；
· 放大到 200%看是否错位 ✔；
· 关掉颜色（灰度截图）看信息是否还在 ✔。
要点：前两条能发现大部分问题 ✔。
四、三个反模式
· "AI 功能太新，可访问性以后再说" ✗（后面重做成本更高 ✔）；
· 只加了 alt 就算做了 ✗（动态内容才是 AI 功能的主要难点 ✔）；
· 测试只走鼠标路径 ✗。
五、一条判据
> 只用键盘 ✔，能否完成"输入 → 生成 → 复制结果"的完整流程 ✔（且知道何时完成 ✔）？
> 不能，说明可访问性还没覆盖主路径 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：沉默失败：最危险的失败是没有报错
下一篇：把评审做轻：异步评审怎么做 →
第 163 / 171 篇