aria-live="polite"在屏幕阅读器正播报其他内容、用户快速切换焦点或滚动时可能被跳过或根本不读；它适合低优先级告知性反馈，不保证即时播报，多次更新仅读最后一次。
aria-live="polite" 什么时候根本不会读？
它真会“礼貌”到被跳过——只要屏幕阅读器正在播报导航栏、上一条错误、甚至当前段落，aria-live="polite"就安静排队；如果用户快速切换焦点或滚动页面，它可能压根没机会发声。
常见触发场景包括：表单保存成功提示、搜索结果计数更新、非关键状态变更（如“已缓存 3 条数据”）。
- 不能保证即时播报，也不适合依赖“用户必须听到”的场景
- 多次快速更新时，中间值容易被覆盖或丢失，只读最后一次
- 适合低优先级、非中断性反馈
aria-live="assertive" 为什么不是“越 assertive 越好”？
aria-live="assertive"确实会强行打断当前播报，立刻读出新内容，但它有强防抖机制：连续两次触发，第二次大概率被忽略，防止语音轰炸。
典型适用场景仅限：登录失败、必填项缺失、权限拒绝等需立即干预的错误。
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 每次更新前必须清空旧文本，再写入新内容，否则不会重新触发播报
- 不要给同一元素同时设
role="alert"和aria-live="assertive"，role="alert"已隐含后者行为 - 避免在 loading 状态、轮播切换、自动轮询中滥用，否则会干扰用户操作流
怎么判断该用 polite 还是 assertive？
判断标准很简单：如果这条消息不被立刻听到，会导致用户继续错操作（比如点了提交却不知失败），就用 aria-live="assertive"；如果只是告知性补充（比如“草稿已自动保存”），aria-live="polite" 更合适。
多数“公告”类内容其实不该打断用户——真正需要 assertive 的，远比开发者直觉中少得多。
- 常见误用：把所有动态更新都设成
assertive，结果用户正在听表单说明，突然被“提交成功”打断两次 - 性能影响：
assertive频繁触发会拖慢屏幕阅读器响应，尤其在低端设备上 - 兼容性注意：部分旧版 NVDA 或 JAWS 对
assertive的防抖逻辑不一致，测试时需覆盖主流组合
DOM 更新方式直接影响播报效果
即使 aria-live 值选对了，DOM 操作不对照样白搭。默认情况下，只要区域内容变化，整个区域会被整体重读；要控制只读新增部分，得配合具体策略：
- 用
appendChild()或insertAdjacentHTML("beforeend", )往区域末尾追加节点，而非替换innerHTML - 确保新增节点有明确语义（比如用
<p></p>或<div role="status"></div>），避免纯文本拼接 - 如果必须替换内容，先清空再写入时，加个短暂停顿：
setTimeout(() => { el.textContent = newText; }, 10)，能减少重复播报
最常被忽略的一点：DOM 插入后不要立刻清空内容——2026年7月11日实测确认，这会导致屏幕阅读器丢失上下文，后续更新不再触发播报。
