应根据信息紧急程度选择：非紧急提示（如“已保存”）用aria-live="polite"，仅当用户必须立即响应（如“验证码错误”）才用aria-live="assertive"；容器须初始存在、避免innerHTML替换、配合aria-atomic="true"确保完整播报。
aria-live="polite" 和 aria-live="assertive" 到底怎么选
选哪个不取决于“语气强弱”，而取决于用户是否必须立刻中断当前操作来响应这条信息。多数动态提示根本不需要打断——比如“已保存”“加载完成”“搜索结果共 8 条”，用 aria-live="polite" 就够了；只有像“验证码错误”“登录失败”“权限已被撤销”这类不立即处理就会导致后续操作出错的，才该用 aria-live="assertive"。
常见误判是把所有 Toast 都设成 assertive，结果用户正听表单说明，突然被“复制成功”强行插话两次。实际测试中，90% 的状态更新用 polite 更安全、更可预测。
-
aria-live="polite"：等屏幕阅读器当前播报自然结束再读，可能被跳过（比如用户快速滚动或切换焦点） -
aria-live="assertive"：会尝试中断，但有防抖机制——连续两次写入，第二次大概率被忽略 - 别混搭
role="alert"和aria-live="polite"，语义冲突，部分读屏器行为不可靠
为什么写了 aria-live 却没读出来
最常踩的坑不是属性写错，而是容器本身没被读屏器“看见”。NVDA、JAWS、VoiceOver 只在元素首次挂载 DOM 时解析 aria-live，后期 JS 动态创建并加属性完全无效。
- 容器必须在初始 HTML 中就存在，比如
<div id="live-region" aria-live="polite" aria-atomic="true"></div> - 不能用
display: none或visibility: hidden隐藏它——得用.sr-only类（position: absolute; clip: rect(0 0 0 0);） - 父级若设了
aria-hidden="true"，整个 live 区域直接失效 - 检查浏览器 AX Tree，确认该元素真实出现在其中，且
aria-live值被解析为"polite"或"assertive"
textContent 更新比 innerHTML 更可靠
往 aria-live 区域写 HTML 字符串（如 el.innerHTML = "<strong>成功</strong>"）会导致 NVDA 跳过标签、VoiceOver 朗读断裂，甚至整条静音。Live region 的设计目标是“文本变更即通知”，不是渲染富文本。
立即学习“前端免费学习笔记（深入）”；
- 推荐只用
textContent更新纯文本：el.textContent = "密码已重置成功"; - 真需强调关键词，用 CSS 控制颜色/背景，不要插入
<strong>或<span> - 若必须换行，可用
white-space: pre-line配合\n，但要实测 NVDA/JAWS 是否支持 - 避免在 React/Vue 中误用
v-html或dangerouslySetInnerHTML，未做纯文本过滤
aria-atomic="true" 不是可选项，是防语义断裂的关键
默认 aria-atomic="false" 会导致只读局部变化。比如把“上传中”改成“上传中 72%”，读屏器可能只读“72%”，漏掉上下文。这不是 bug，是原子性未开启的必然表现。
- 所有状态类提示（
role="status"）和错误消息（role="alert"）都应配aria-atomic="true" - 不要在
aria-live容器里嵌套另一个aria-live区域，原子性会失效，读起来像卡顿录音 - 旧版 NVDA 有时必须加
aria-atomic="true"才稳定触发播报，尤其内容被完全替换时
aria-live="assertive" 的防抖逻辑和 VoiceOver 不同，而 iOS VoiceOver 某些版本对 assertive 支持不稳定——这些细节没法靠一套配置覆盖全部，只能靠真实设备组合测试。 
