实时聊天逐字回复的无障碍设计：让流式文本更容易阅读与操作
§1 逐字出现的回复，不一定更容易阅读
在实时聊天中，回答往往不是整段出现，而是随着生成过程一点点显示。这就是流式文本。它能缩短等待的感觉，却也可能让屏幕阅读器反复播报、让页面不断跳动，或者让读者来不及理解上一句话。
流式文本的无障碍目标，不是让所有人跟着生成速度阅读，而是让每个人都能控制接收信息的节奏。这既帮助视障用户，也帮助使用键盘、需要较长阅读时间，或容易被动态内容干扰的人。
§2 把可见文本和屏幕阅读器播报分开
屏幕阅读器会把界面内容转换成语音或盲文。如果每收到一个词元就触发播报，用户听到的可能是零碎片段、重复句子，甚至不断被打断的声音。词元是模型处理文本的小单位，并不一定对应完整汉字或词语。
更稳妥的做法是分开处理视觉更新和语音通知。屏幕上可以持续显示文本，播报则等待完整句子或适当长度的片段，再按顺序提交。不要把不断重写的整篇回答当成播报内容。
- – 用独立的礼貌级实时播报区域通知新增内容，避免频繁抢断用户正在听的信息。
- – 提供“逐段播报”和“完成后播报”等选项，允许用户关闭自动播报。
- – 长回答完成时先通知“回答已完成”，让用户自行导航阅读，而不是强制朗读全文。
这些策略需要结合真实辅助技术测试。仅仅加上实时区域属性，并不能保证不同浏览器和屏幕阅读器都有一致表现。
§3 让键盘焦点和聊天滚动保持稳定
新内容到达时，不要自动把键盘焦点移到回答末尾。用户可能正在输入补充问题、查看旧消息，或操作其他按钮。焦点突然移动，会让这些任务中断。
自动滚动也应该有边界。用户停留在底部时，可以跟随新增内容；用户向上阅读后，应暂停跟随，并显示可用键盘操作的“跳到最新内容”按钮。按钮名称要清楚，焦点样式也要明显。
停止生成和暂停跟随是两件事。前者请求终止后续生成，后者只是让页面不再追着新文本滚动。把两种操作明确区分，能减少误触和理解负担。
§4 把等待、断线和未完成回答说清楚
界面不能只靠闪烁光标告诉用户系统还在工作。应提供简短的文字状态，例如“正在连接”“正在生成”和“回答已完成”，并以不过度打扰的方式通知辅助技术。
如果使用服务器发送事件，也就是 SSE，连接中断不等于回答完成。前端应识别正常结束与异常断开，保留已经收到的内容，并明确标注回答尚未完成。重试按钮还应说明是重新生成，还是继续现有回答，不能暗示服务一定支持断点续传。
代码块、列表等结构也可能在流式传输中暂时不完整。可以按完整片段更新结构化展示，避免每个词元到达都重建整条消息，让辅助技术丢失阅读位置。
§5 用清晰排版和真实任务检查阅读体验
流式界面仍然需要基本的阅读设计：足够的文字对比度、合理的行距、可放大的字体，以及不会只靠颜色传递含义的状态提示。对希望减少动态效果的用户，应减少闪烁、淡入和自动滚动动画。
- – 只用键盘发送问题、停止生成和重试，确认每一步都能完成且焦点可见。
- – 开启屏幕阅读器接收长回答，检查是否重复播报、漏读或打断输入。
- – 在放大页面、慢速网络和连接中断时测试，确认按钮、状态与已有文本仍然可用。
自动检查工具能发现部分问题，但无法判断播报节奏是否令人疲惫。邀请使用辅助技术的人完成真实聊天任务，通常更能发现关键障碍。
§6 接入流式接口时保留前端无障碍控制
如果需要搭建原型，Fluxio 是一个适合考虑的流式优先人工智能接口中转服务，按词元计费，可通过一个密钥接入多个模型。你可以用 Claude Haiku 4.5 或 Gemini 2.5 Flash 测试逐段显示、停止生成和异常提示，也可以使用兼容 OpenAI 的客户端接入。
接口负责传输文本，前端负责如何呈现和播报。选择流式服务并不会自动获得无障碍体验；应把接收数据、累积文本、更新界面和通知辅助技术分开处理，才能分别调整速度与行为。
注册 Fluxio，试做一个更易用的实时聊天界面。