aria-live="polite"会在屏幕阅读器忙于播报其他内容时排队等待甚至被跳过，适合非紧急告知；而aria-live="assertive"会强制中断播报，仅用于需立即干预的错误，且每次更新前须清空旧文本。
aria-live="polite" 什么时候不读？
它真会“礼貌”到被跳过——只要屏幕阅读器正在播报其他内容（比如导航栏、上一条错误提示、甚至当前段落），aria-live="polite" 就会安静排队，等空闲了再读；如果用户快速切换焦点或滚动页面，它可能根本没机会发声。
常见触发场景包括：表单保存成功提示、搜索结果计数更新、非关键状态变更（如“已缓存 3 条数据”）。
- 适合低优先级、非中断性反馈
- 不能保证即时播报，也不适合依赖“用户必须听到”的场景
- 多次快速更新时，中间值容易被覆盖或丢失，只读最后一次
aria-live="assertive" 为什么不是万能解药？
aria-live="assertive" 确实会强行打断当前播报，立刻读出新内容，但它不是“越 assertive 越好”。连续两次触发，第二次大概率被忽略——因为屏幕阅读器内部有防抖机制，防止语音轰炸。
典型适用场景：登录失败、必填项缺失、权限拒绝等需立即干预的错误。
- 每次更新前必须清空旧文本，再写入新内容，否则不会重新触发播报
- 不要给同一元素同时设
role="alert"和aria-live="assertive"，role="alert"已隐含后者行为，重复声明无意义 - 避免在 loading 状态、轮播切换、自动轮询中滥用，否则会干扰用户操作流
怎么选？看用户是否需要“立刻行动”
判断标准很简单：如果这条消息不被立刻听到，会导致用户继续错操作（比如点了提交却不知失败），就用 assertive；如果只是告知性补充（比如“草稿已自动保存”），polite 更合适。
真实项目里最容易被忽略的是「清空逻辑」——很多人只做 el.textContent = '提交成功'，但没在赋值前执行 el.textContent = ''，导致 assertive 区域静默失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
