aria-live="assertive"并非写入即打断，必须同时满足三条件：区域已挂载且初始可见、每次更新前清空内容、新内容写入后至少延迟100ms；父级aria-hidden、dom更新方式不当或未出现在ax tree均会导致失效。
aria-live="assertive" 不是写了就打断，得满足三个硬条件
只加 aria-live="assertive" 几乎肯定没用。屏幕阅读器（NVDA/JAWS/VoiceOver）对 assertive 有防抖机制：连续两次更新，第二次大概率被丢弃；只有当前播报已开始、旧文本已被清空、新内容写入后间隔 ≥100ms，才可能触发强制中断。
必须同时满足：
- 区域已挂载到 DOM 且初始可见（不能
display: none、visibility: hidden，也不能被aria-hidden="true"的父容器包裹） - 每次更新前先清空内容：
el.textContent = ""或el.innerHTML = "" - 新内容写入后，用
setTimeout(() => { el.textContent = "验证码错误"; }, 100)延迟至少 100ms
为什么父级 aria-hidden="true" 会让 assertive 完全失效
这是最常被忽略的坑。如果错误提示框嵌在模态弹窗里，而弹窗壳层写了 aria-hidden="true"，那整个子树（包括 aria-live="assertive" 区域）都会从可访问性树（AX Tree）中移除——屏幕阅读器根本“看不见”它，更不会监听变更。
解决方案：
- 模态框打开时，把
aria-hidden="true"移到 其他非模态内容 上，而不是模态框自身 - 或者改用
inert属性（现代浏览器支持），它不影响子元素的可访问性状态 - React/Vue 中避免用
v-if或{show && >}控制弹窗显隐——销毁重挂会切断 live region 的监听上下文
DOM 更新方式不对，assertive 就变成静音
innerHTML = "网络断开" 这种全量替换，等于先触发一次“清空”，再触发一次“新增”，屏幕阅读器可能只报后半句，或直接跳过。更糟的是，如果清空和写入在同一个 JS tick 内完成，NVDA 可能压根不播。
安全写法只有两种：
- 纯文本更新：
el.textContent = "登录失败，请重试"（推荐，语义干净、无渲染风险） - 追加式更新（仅适用于日志流类场景）：
el.insertAdjacentHTML("beforeend", "<div>操作失败</div>")，但需配合aria-atomic="false"
绝对避免：dangerouslySetInnerHTML、v-html、带 <strong></strong> 的 innerHTML —— VoiceOver 会朗读断裂，NVDA 可能静音整条。
assertive 在 iOS VoiceOver 上基本不可靠
截至 2026 年 8 月，iOS 17–18 的 VoiceOver 对 aria-live="assertive" 支持仍不稳定：部分机型直接忽略，部分版本随机静音，极少能稳定抢话。别拿它做关键路径的兜底。
实操建议：
- 紧急错误（如登录失败）优先用
role="alert"+aria-live="assertive"组合（role="alert"本身隐含 assertive 行为，兼容性略好） - 倒计时、进度条等高频更新场景，一律改用
aria-live="polite"+aria-atomic="true"，别试图每秒 assertive - 真要验证是否生效，手动触发朗读：
VO+A（VoiceOver）或Ctrl+Shift+DownArrow（NVDA），别只看视觉反馈
最麻烦的不是怎么写 assertive，而是怎么确认它真被读了——很多团队测完“弹出来了”就上线，结果视障用户全程静音。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
