aria-live="assertive" 并非写入即打断播报，需同时满足三条件：区域已挂载且初始可见、每次更新前清空内容、新内容写入后至少间隔100ms；父级 aria-hidden、dom 更新方式不当（如追加而非替换）、未出现在ax tree等均会导致失效。
aria-live="assertive" 什么时候才真会打断播报
它不是写了就立刻抢话——屏幕阅读器对 aria-live="assertive" 有内置防抖：连续两次更新，第二次大概率被丢弃。只有当前播报已开始、且新内容写入时旧文本已被清空，才会触发强制中断。
常见误判是看到“错误弹出”就以为用户听到了，实际可能因更新太快或未清空而静默。必须满足三个条件：
- 区域已挂载到 DOM，且初始可见（不能
display: none或aria-hidden="true"） - 每次更新前先清空内容（
el.textContent = ""或el.innerHTML = ""） - 新内容写入后，至少间隔 100ms 再触发下一次（否则 NVDA/JAWS 可能跳过）
为什么只写 aria-live="assertive" 还是没读出来
最常漏掉的是父级屏蔽。如果错误容器被包在 aria-hidden="true" 的弹窗壳里，或者整个表单加了 aria-hidden，那子级的 aria-live 就完全失效。
排查顺序建议：
- 用浏览器开发者工具检查该元素是否出现在 AX Tree 中（不是仅看 HTML）
- 确认
aria-live值被解析为"assertive"，而非字符串拼错（比如写成assertive多了个空格） - 检查是否同时设了
role="alert"—— 它已隐含aria-live="assertive"，重复设置反而干扰 - 旧版 NVDA 有时需搭配
aria-atomic="true"才稳定触发
DOM 更新方式决定 assertive 是否有效
直接改 innerHTML 或 textContent 是最稳妥的，但必须“清空 → 等待 → 写入”。用 insertAdjacentHTML("beforeend", ...) 追加内容，aria-live="assertive" 基本不会响应——它只认整体替换，不认增量追加。
正确写法示例：
const errorEl = document.getElementById("error-message");
errorEl.textContent = ""; // 必须清空
setTimeout(() => {
errorEl.textContent = "密码错误，请重试";
}, 50); // 微小延迟防抖
错误写法：
-
errorEl.innerHTML += "<p>密码错误</p>"（追加不触发 assertive） -
errorEl.textContent = "密码错误"; errorEl.textContent = "用户名不能为空"（无间隔，第二次大概率丢） - 把错误提示塞进一个正在做 CSS 动画的容器里（动画帧可能干扰 DOM 变更感知）
assertive 不是万能开关，滥用反而破坏体验
真正需要立即打断用户的场景极少：登录失败、权限拒绝、关键字段缺失（如手机号格式错误且提交按钮已禁用）。其他情况，比如“输入中…”“校验中…”，用 aria-live="polite" 更合适。
容易被忽略的复杂点：
- 同一页面多个
aria-live="assertive"区域会互相竞争，语音可能卡顿或跳读 - 移动端 VoiceOver 对 assertive 的响应比桌面端更保守，测试必须覆盖 iOS + Safari 组合
- 错误消息本身要语义完整——不能只写“错误”，得说清“邮箱格式不正确”或“验证码已过期”
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
