绝大多数实时更新场景用 polite 就够了，仅紧急状态变更（如“余额不足”）才用 assertive；aria-live 区域须持续存在，避免 innerHTML 替换；需配合 aria-atomic="true" 和语义化文案确保完整、准确播报。
aria-live 该设成 polite 还是 assertive
绝大多数实时更新场景用 polite 就够了。它会让屏幕阅读器在当前语音结束后再播报，不打断用户操作；只有真正需要立即中断（比如错误弹窗、支付失败提示）才用 assertive——但要注意，assertive 可能被跳过或重复播报，尤其在 NVDA + Firefox 组合下不稳定。
常见错误是把所有动态区域都设成 assertive，结果用户正在读表单时被反复打断。实际中，通知类内容用 polite，紧急状态变更（如“余额不足”）才考虑 assertive，且必须配合 aria-atomic="true" 确保整块内容被完整读出。
为什么更新后没读出来？检查 DOM 更新方式
aria-live 区域必须是**持续存在的 DOM 节点**，不能每次更新就 innerHTML = ... 替换整个容器——这会重置屏幕阅读器的监听状态。正确做法是只更新内部文本节点或添加子元素。
- ✅ 推荐：
document.getElementById('live-region').textContent = '已提交成功' - ❌ 避免：
el.innerHTML = '<div>已提交成功</div>'（清空并重建，监听失效） - ⚠️ 注意：React/Vue 中若用
key强制重渲染整个 live 区域，同样会中断播报
如何避免重复播报和语义丢失
单纯塞文字进去，屏幕阅读器可能读得生硬（比如“12:34:56”，没上下文）。关键是要让内容自带语义和最小必要信息：
立即学习“前端免费学习笔记（深入）”；
- 加简短动词前缀：不是“订单已创建”，而是“✅ 订单已创建”（emoji 提供视觉+语义锚点）
- 避免纯数字或缩写：“剩余 3 秒” → “倒计时还剩 3 秒”
- 用
aria-atomic="true"防止只读新旧差异部分（默认是 false，可能只读“3 秒”而漏掉“倒计时还剩”） - 用
aria-relevant="text"（默认值）就够了，除非要监听 class 变化，否则别加additions或removals，反而增加误报
测试时最容易被忽略的兼容性细节
不同组合表现差异大：JAWS 在 Chrome 下对 polite 响应快，但 VoiceOver + Safari 对快速连续更新常合并或丢弃；NVDA 在 Firefox 下有时需手动聚焦才能触发。
真实测试建议：
- 用真实屏幕阅读器（别信模拟工具），至少覆盖 VoiceOver（macOS/Safari）、NVDA（Windows/Firefox）、JAWS（Windows/Chrome）
- 连续触发 3 次更新，观察是否全部播报、有无延迟、是否被截断
- 更新后立刻按
Ctrl+Shift+DownArrow（NVDA）或VO+A（VoiceOver）手动触发朗读，验证 DOM 确实已更新
最麻烦的是异步加载完成后的提示——比如搜索结果返回后，要确保 aria-live 区域在请求发起前就存在，且更新逻辑不依赖 React 的 useEffect 渲染时机，否则容易错过首次播报。
