aria-live="assertive" 并非设了就抢话，必须同时满足三条件：元素已挂载且初始可见、每次更新前清空内容、新内容写入后至少间隔100ms；父级aria-hidden、dom追加更新或未出现在ax tree均会导致失效。
aria-live="assertive" 为什么写了却没打断播报
它不是“设了就抢话”，屏幕阅读器（尤其是 NVDA/JAWS）对 aria-live="assertive" 有内置防抖：连续两次更新，第二次大概率被丢弃。真正触发强制中断，必须同时满足三个硬性条件：
- 元素已挂载到 DOM 且初始可见（不能是
display: none、visibility: hidden，也不能被父级aria-hidden="true"包裹） - 每次写入新内容前，必须先清空旧文本（
el.textContent = ""或el.innerHTML = ""） - 清空后，至少等待 100ms 再写入新内容（用
setTimeout控制，50–100ms 是实测稳定区间）
漏掉任意一条，就会静默——比如错误容器嵌在弹窗壳里，而弹窗壳有 aria-hidden="true"，子级的 assertive 完全失效。
怎么写 JS 才让 assertive 真正生效
DOM 更新方式决定是否触发。屏幕阅读器只响应“整体替换”，不认“追加”或“快速覆盖”。以下写法才可靠：
- ✅ 正确：
errorEl.textContent = ""→setTimeout(() => { errorEl.textContent = "密码错误，请重试"; }, 50) - ❌ 错误：
errorEl.innerHTML += "<p>密码错误</p>"（追加不触发） - ❌ 错误：
errorEl.textContent = "密码错误"; errorEl.textContent = "用户名不能为空"（无间隔，第二次几乎必丢） - ⚠️ 注意：避免把错误提示塞进正在做 CSS 动画的容器，动画帧可能干扰变更感知
别同时设 role="alert" 和 aria-live="assertive"——role="alert" 已隐含后者，重复设置反而干扰。
哪些场景真该用 assertive
真正需要立即打断用户的场景极少。滥用会导致语音轰炸、用户关闭朗读，甚至跳过后续关键信息。仅限以下情况：
- 登录失败（凭据错误、账号锁定）
- 权限拒绝（如尝试访问未授权页面）
- 表单必填项为空且用户已提交
- 支付失败、余额不足等需用户立刻干预的状态
其他所有情况（如“已保存”“加载中”“搜索结果共 12 条”）一律用 aria-live="polite"。别为“看起来更醒目”而升级 assertive。
测试时最容易忽略的兼容性细节
不同组合表现差异极大，模拟工具不可信。真实测试必须覆盖：
- VoiceOver + Safari（macOS）：对快速更新常合并或丢弃，需手动按
VO+A触发朗读 - NVDA + Firefox：有时需手动聚焦才能触发，且旧版本需搭配
aria-atomic="true"才稳定 - JAWS + Chrome：响应较快，但若父级
aria-hidden漏查，会直接静音
最易被忽略的是 AX Tree 中是否真包含该元素——用浏览器开发者工具的“Accessibility”面板确认，而不是只看 HTML 结构。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
