动态内容不发声主因是aria-live缺失或配置错误，须在初始html中为容器设aria-live="polite/assertive"，配合role="status/alert"正确选用，并通过tabindex="-1"+focus()同步焦点，销毁时清理aria-hidden并回跳焦点。
动态内容不发声？先检查 aria-live 是否正确挂载
屏幕阅读器“听不见”新加载的内容，几乎全是 aria-live 缺失或配置错误导致的。它不是可选装饰，而是动态内容可访问性的通信通道。
常见错误现象：
- 用
innerHTML或appendChild插入提示文本，但容器没加aria-live - 把
aria-live加在父级<div> 上，而实际更新的是子元素（屏幕阅读器只监听直接子节点的文本变更） <li>值设成 <code>aria-live="off"或拼写错误如aria-livee - 为承载动态消息的容器（如状态栏、通知区）直接设置
aria-live="polite"或aria-live="assertive"，不要依赖 JS 动态添加该属性——必须初始 HTML 就存在 - 确保该容器是空的或仅含占位文本，避免初始化时触发误播报
- 不要把
aria-live和role="alert"同时手动设（role="alert"已隐含aria-live="assertive"），重复设置可能干扰某些读屏行为 -
role="status"：适合非紧急、背景性更新，如“已保存”“加载中…”。默认搭配aria-live="polite"，且通常需加aria-atomic="true"防止只读变化片段 -
role="alert"：专用于中断性、需立即响应的信息，如表单验证失败、权限拒绝、网络断开。它自动启用aria-live="assertive"，无需额外声明 - 别用
role="log"替代status—— 它适用于持续追加的流式内容（如聊天记录），对单次状态更新反而降低可理解性 - 只调用
element.focus()，但目标元素没可聚焦性（比如<div> 默认不可聚焦） <li>在异步加载完成前就执行 <code>focus()，目标元素尚未渲染到 DOM - 聚焦后未清除之前焦点样式，视觉焦点丢失，键盘用户无法判断当前在哪
- 给要聚焦的容器（如新弹出的模态框根节点、步骤向导的新步骤区域）加上
tabindex="-1" - 在 DOM 插入完成、且确保元素已渲染（可用
requestAnimationFrame或await new Promise(r => setTimeout(r))简单兜底）后再调用.focus() - 配合
scrollIntoView({ block: 'nearest' })，避免新内容被遮挡或滚动出视口 - 移除动态内容前，先用
aria-hidden="true"标记其容器（比直接removeChild更安全，能触发辅助技术感知“即将消失”） - 若内容是模态框或弹窗，关闭后必须将焦点移回触发它的按钮，否则 tab 键会跳进页面底部甚至丢失
- 如果用了
aria-live区域承载临时消息（如“操作成功”），消息消失后，清空其textContent并重置aria-live值为"off"（或保持原值，但清空内容即可；部分读屏对空值不播报）
实操建议：
role="status" 和 role="alert" 到底怎么选
选错 role 会导致信息被忽略，或打断用户正在做的事。这不是语义洁癖，而是播报逻辑的根本差异。
使用场景与参数差异：
性能影响：两者本身无性能开销，但若高频触发 role="alert"（比如每秒轮询一次状态），会严重干扰屏幕阅读器用户，应改用 status 或节流处理。
为什么焦点没跟上新内容？tabindex="-1" + focus() 是刚需
即使 aria-live 正常播报，键盘用户仍可能卡在旧位置——因为 DOM 更新了，但焦点没动。这和屏幕阅读器播报是两套机制，必须分开处理。
容易踩的坑：
实操建议：
动态内容隐藏/销毁时，别忘了清理和回跳
很多团队只关注“出现”，却忽略“消失”——这会让屏幕阅读器继续播报已不存在的内容，或让键盘用户 tab 进“虚空”。
关键动作：
最常被忽略的点：SPA 路由切换时，新页面内容加载完成，但焦点仍停在旧页末尾。必须在 DOMContentLoaded 或路由就绪后，主动聚焦到新页的 <main></main> 或首个 heading，否则等于放弃键盘用户。
