aria-live="polite"在屏幕阅读器正播报导航栏、上一条错误或当前段落时会排队等待，用户快速切换焦点或滚动页面时可能完全不读；适合“已保存”等非紧急提示。
aria-live="polite" 什么时候根本不会读？
它真会“礼貌”到被跳过——只要屏幕阅读器正在播报导航栏、上一条错误、甚至当前段落，aria-live="polite" 就安静排队；如果用户快速切换焦点或滚动页面，它可能压根没机会发声。
常见触发场景包括：表单保存成功提示、搜索结果计数更新、非关键状态变更（如“已缓存 3 条数据”）。
- 适合低优先级、非中断性反馈
- 不能保证即时播报，也不适合依赖“用户必须听到”的场景
- 多次快速更新时，中间值容易被覆盖或丢失，只读最后一次
aria-live="assertive" 为什么不是“越 assertive 越好”？
aria-live="assertive" 确实会强行打断当前播报，立刻读出新内容，但它有强防抖机制：连续两次触发，第二次大概率被忽略，防止语音轰炸。
典型适用场景仅限：登录失败、必填项缺失、权限拒绝等需立即干预的错误。
立即学习“前端免费学习笔记（深入）”；
- 每次更新前必须清空旧文本，再写入新内容，否则不会重新触发播报
- 不要给同一元素同时设
role="alert"和aria-live="assertive"，role="alert"已隐含后者行为 - 避免在 loading 状态、轮播切换、自动轮询中滥用，否则会干扰用户操作流
怎么判断该用 polite 还是 assertive？
判断标准很简单：如果这条消息不被立刻听到，会导致用户继续错操作（比如点了提交却不知失败），就用 aria-live="assertive"；如果只是告知性补充（比如“草稿已自动保存”），aria-live="polite" 更合适。
多数“公告”类内容其实不该打断用户——真正需要 assertive 的，远比开发者直觉中少得多。
- 常见误用：把所有动态更新都设成 assertive，结果用户正在听表单说明，突然被“提交成功”打断两次
- 性能影响：assertive 频繁触发会拖慢屏幕阅读器响应，尤其在低端设备上
- 兼容性注意：部分旧版 NVDA 或 JAWS 对 assertive 的防抖逻辑不一致，测试时需覆盖主流组合
DOM 更新方式直接影响播报效果
即使 aria-live 值选对了，DOM 操作不对照样白搭。默认情况下，只要区域内容变化，整个区域会被整体重读；要控制只读新增部分，得配合具体策略：
- 用
appendChild()或insertAdjacentHTML("beforeend", ...)往区域末尾追加节点，而非替换innerHTML - 确保新增节点有明确语义（比如用
<p></p>或<div role="status"></div>），避免纯文本拼接 - 如果必须替换内容，先清空再写入时，加个短暂停顿：
setTimeout(() => { el.textContent = newText; }, 10)，能减少重复播报
复杂点在于：aria-atomic 默认为 false，意味着只读变化部分；但若你追加的是结构化内容（比如带图标和描述的卡片），最好显式设 aria-atomic="true"，否则屏幕阅读器可能只读文本，漏掉上下文。
