aria-live="assertive"在错误弹窗中不读最常因父级aria-hidden="true"屏蔽，须确保区域初始可见、更新前清空内容、新内容写入后至少间隔100ms，且避免追加式DOM更新。
aria-live="assertive"在错误弹窗里为什么写了也不读
最常漏掉的是父级屏蔽：错误容器被包在aria-hidden="true"的弹窗壳里，或者整个表单加了aria-hidden，子级的aria-live="assertive"就彻底失效。排查顺序必须是：
— 用开发者工具检查该元素是否出现在 AX Tree 中（不是只看 HTML）
— 确认aria-live值被解析为"assertive"，而非拼错（比如多空格或大小写）
— 检查是否同时设了role="alert"——它已隐含aria-live="assertive"，重复设置反而干扰
— 旧版 NVDA 有时需搭配aria-atomic="true"才稳定触发
错误弹窗内容更新必须“清空 → 等待 → 写入”
aria-live="assertive"不是写了就立刻抢话，屏幕阅读器有内置防抖：连续两次更新，第二次大概率被丢弃。只有当前播报已开始、且新内容写入时旧文本已被清空，才会触发强制中断。
正确写法必须满足三个硬条件：
— 区域已挂载到 DOM，且初始可见（不能display: none或visibility: hidden）
— 每次更新前先清空内容（el.textContent = "" 或 el.innerHTML = ""）
— 新内容写入后，至少间隔 100ms 再触发下一次（否则 NVDA/JAWS 可能跳过）
错误写法包括：errorEl.innerHTML += "<p>密码错误</p>"（追加不触发）、errorEl.textContent = "密码错误"; errorEl.textContent = "用户名不能为空"（无间隔，第二次丢）、把错误提示塞进正在做 CSS 动画的容器里（动画帧可能干扰 DOM 变更感知）
DOM 更新方式决定 assertive 是否生效
aria-live="assertive"只认整体替换，不认增量追加。用insertAdjacentHTML("beforeend", )往里面塞内容，基本不会响应。
最稳妥的方式是：
— 直接改textContent（纯文本、无 XSS 风险、语义干净）
— 若必须保留 HTML 结构，先el.innerHTML = ""清空，再注入已转义的安全字符串
— 别在aria-live容器里嵌套另一个aria-live区域，原子性会失效，读起来像卡顿录音
示例：
const errorEl = document.getElementById("error-message");<br>errorEl.textContent = "";<br>setTimeout(() => {<br> errorEl.textContent = "密码错误，请重试";<br>}, 50);
assertive 不是万能开关，紧急场景极少
真正需要立即打断用户的场景极少：登录失败、权限拒绝、关键字匹配失败（截至2026年8月1日）。多数表单校验错误（如邮箱格式不对、密码太短）其实更适合aria-live="polite" + aria-invalid + aria-describedby组合，避免打断用户正在输入。
滥用assertive的后果很实际：
— NVDA + Firefox 下不稳定，可能跳过或重复播报
— 用户正在听长段落，被“提交成功”突然打断两次
— 频繁更新（如每秒轮询错误状态）直接导致语音轰炸
— 关闭按钮若没管理好焦点，用户关闭后无法继续操作
立即学习“前端免费学习笔记（深入）”；
