适合，但需满足时间有序、自动追加、不可编辑删除的前提；DOM须用单容器设role="log"，消息动态追加末尾，禁用innerHTML重写，配合aria-label及正确JS操作方可实现屏幕阅读器精准播报新增内容。
role="log" 适合聊天消息区域吗？
适合，但有严格前提：内容必须是**时间有序、自动追加、不支持编辑或删除**的流式日志。聊天窗口如果允许用户撤回、编辑、拖拽排序、或手动插入旧消息，role="log" 就不适用——它不是“看起来像日志”的装饰性属性，而是向辅助技术（如屏幕阅读器）声明一种特定行为契约。
用 role="log" 时 DOM 结构怎么组织？
必须用一个容器元素（如 <div> 或 <section>）包裹所有消息，并设 role="log"；每条新消息应作为子元素**动态追加到末尾**，且不能重排已有节点。辅助技术会监听这个容器的子节点变化，只朗读新增项（默认不重复读历史）。
示例结构：
<div role="log" aria-label="聊天记录"> <div class="message" aria-live="off">[10:02] 小张：你好</div> <div class="message" aria-live="off">[10:03] 你：收到</div> </div>
-
aria-label或aria-labelledby必须提供，否则屏幕阅读器可能无法识别该区域用途 - 每条消息自身不要设
role="log"—— 容器级声明即可 - 消息内部避免再嵌套
role="log"或role="alert"，会造成行为冲突
为什么不能直接用 aria-live="polite" 替代？
aria-live="polite" 也能播报新增内容，但它不承诺顺序、不抑制重复播报、也不暗示“仅追加”语义。而 role="log" 在支持它的 AT（如 NVDA + Firefox、VoiceOver macOS）中会启用专用日志模式：只读新节点、跳过已存在节点、自动滚动到末尾、且对用户操作（如点击某条旧消息）保持静默。
立即学习“前端免费学习笔记（深入）”；
- Chrome + JAWS 对
role="log"支持较弱，此时需降级为aria-live="polite"+ 手动管理aria-relevant="additions" - 若消息含可交互元素（如“复制”按钮），要确保它们在追加后仍能被键盘聚焦，不能因
role="log"隐式截断焦点流 - 不要给容器同时设
role="log"和aria-live—— 语义重复且部分 AT 会忽略role="log"
容易被忽略的兼容性细节
很多开发者以为设了 role="log" 就万事大吉，实际上关键逻辑在 JS 追加行为本身：必须用 appendChild() 或 append() 追加新节点，不能用 innerHTML += 或 replaceChildren() —— 后者会销毁旧节点，导致 AT 丢失上下文，把整块内容当全新日志重读。
- React/Vue 中务必用真实 DOM 追加（如
ref.current.append(newMsg)），避免虚拟 DOM 全量重渲染容器 - 若需清空日志，应移除容器内所有子节点后再追加新批次，而不是替换整个容器 —— 否则
role="log"的状态会被重置 - 测试时用 VoiceOver（macOS）或 NVDA（Windows）手动触发新消息，听是否只读新增行、且不打断当前操作
真正难的不是加那个 role，而是让 JS 追加逻辑和 AT 的日志模型对齐——稍有偏差，体验就退回原始的 aria-live 模式。
