让沉浸式LLM聊天体验更易于访问
内容提要
文章探讨如何提升沉浸式LLM聊天界面的可访问性，建议：用实时区域播报完整回复而非逐字播报；加载时提示处理状态；为每条消息添加隐藏标题以标明说话者；合理使用地标、跳转链接和复合控件；避免feed模式；支持F6导航；检查缩放表现；提供播报粒度、动画、声音和快捷键的自定义选项；对表格和代码块采用简洁描述播报；并通过包容性用户研究听取残障用户意见。
延伸解读
实时区域播报：完整回复优于逐字流式
文章强调，对于屏幕阅读器用户，应在LLM回复完整显示后，通过专用实时区域一次性播报全部内容，而非在流式传输过程中逐字播报。逐字播报会造成断断续续、难以解析的体验。专用实时区域应置于DOM末尾，避免在每个消息上单独使用aria-live，以提高稳定性和可靠性。
加载状态与播报粒度的用户控制
LLM响应可能需要时间，视觉上的加载动画对屏幕阅读器用户不可见。文章建议在提交提示后5秒触发“加载中”实时播报，并每5秒重复，直至回复完成。同时，应允许用户调整播报粒度，例如关闭次要操作（如代码搜索、工具调用）的播报，避免信息过载，这与视觉用户可快速略过次要内容等效。
导航结构：隐藏标题、地标与复合控件
为每条消息添加视觉隐藏的标题（如“你说：”或“{代理名}说：”），可帮助屏幕阅读器用户快速定位说话者。地标应仅用于主要区域（导航、主内容、表单、侧边栏），避免包裹每条消息，以免地标列表过长。会话列表应实现为复合控件，整体作为一个Tab停靠点，内部用方向键导航，减少键盘操作负担。
特殊内容播报与包容性用户研究
表格和代码块在实时区域中直接播报会丢失语义或变成乱码。文章建议对表格播报行列数及简要描述，对代码块播报文件名和行数，作为上下文预览。此外，所有改进应基于包容性用户研究，让残障用户作为自身经验的专家参与测试，而非仅依赖合规检查。
Q&A
如何让屏幕阅读器用户知道LLM聊天有了新回复？
使用实时区域（live region）播报完整回复，而不是逐字播报。将实时区域放在DOM末尾，当LLM回复完整显示后触发播报，这样用户无需移动焦点就能知道新内容。
LLM聊天加载时如何提示辅助技术用户？
如果视觉上有加载文字，同时触发实时区域播报相同文字；如果只有加载动画，则在提交后5秒触发“Loading”播报，并每5秒重复直到回复完成。回复完成后立即播报。
为什么要在每条聊天消息前加隐藏标题？
隐藏标题（如“你说：”或“{代理名}说：”）帮助屏幕阅读器用户快速导航并识别消息的说话者，弥补视觉上通过左右对齐区分说话者的不足。
LLM聊天界面应该避免使用feed模式吗？
是的，应避免feed模式。因为feed模式在焦点管理和键盘用户体验上存在边缘情况，而使用带有隐藏标题的article元素包裹消息更简单有效，且易于维护。
如何为LLM聊天添加F6导航支持？
为每个地标设置id和tabindex="-1"，并确保除main外地标有可访问名称。监听Control+F6和Control+Shift+F6按键，按顺序将焦点移到下一个或上一个地标。
LLM聊天中表格和代码块应该如何播报？
表格播报应简洁描述行数列数及总体趋势，如“包含性能审计的表格，4列36行”；代码块播报应包含文件名或类型及行数，如“settings.json，738行”。避免逐字播报。
如何通过用户偏好的设置提升LLM聊天的可访问性？
提供播报粒度（如关闭次要动作播报）、动画开关（尊重prefers-reduced-motion）、声音开关以及可重新绑定的键盘快捷键等自定义选项，让用户根据需求调整体验。
