aria-live="polite"在当前播报结束后读新内容，适合通知类更新；aria-live="assertive"立即中断播报，仅用于紧急提示。需确保区域初始可见、已挂载DOM，并配合append或insertAdjacentHTML控制只读新增内容。
aria-live="polite" 和 aria-live="assertive" 有什么区别
关键看内容变化是否需要立即打断用户当前操作。用 aria-live="polite" 时，屏幕阅读器会在当前播报自然结束后再读新内容；而 aria-live="assertive" 会立刻中断当前语音、强制播报，适合错误提示或紧急状态变更。
常见误用是把所有动态更新都设成 assertive，结果用户正在听表单说明，突然被“提交成功”打断两次——实际多数场景用 polite 更友好。
-
polite：适合通知类更新（如搜索结果数、加载进度百分比） -
assertive：只用于必须立即获知的内容（如“验证码错误，请重试”） - 避免在频繁更新的区域（如每秒刷新的计时器）使用
assertive，会导致语音轰炸
怎么让屏幕阅读器只读新增内容，而不是整个区域重读
默认情况下，只要区域内容变化，aria-live 区域会被整体重新播报。要控制只读新增部分，得配合 DOM 操作策略：
- 用
appendChild()或insertAdjacentHTML("beforeend", ...)往区域末尾追加新节点，而非替换innerHTML - 确保新增节点有明确语义（比如用
<p>或<div role="status">），避免纯文本拼接 - 如果必须替换内容，先清空再写入时，加个短暂停顿（
setTimeout(() => { el.textContent = newText; }, 10)），能减少重复播报
例如：
<div aria-live="polite" aria-atomic="false" id="live-region"></div>然后 JS 中执行
document.getElementById("live-region").insertAdjacentHTML("beforeend", "<p>新消息已收到</p>")，屏幕阅读器通常只读这句新 <p>。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
为什么加了 aria-live 却没播报？常见排查点
最常漏掉的是元素初始不可见或未插入 DOM。屏幕阅读器只监听已挂载且非 display: none / visibility: hidden 的 aria-live 区域。
- 确保区域在页面加载时就存在 DOM 中，不要等 JS 动态创建后再加
aria-live - 避免给区域设
display: none或opacity: 0（即使aria-hidden="false"也无效） - 检查是否意外设置了
aria-hidden="true"在父容器上，会屏蔽子级 live 区域 - 某些旧版 NVDA 需要
aria-atomic="true"才触发播报（尤其当区域内容被完全替换时）
可临时用浏览器开发者工具检查该元素是否出现在 AX Tree 中，并确认 live 属性值被正确解析为 “polite” 或 “assertive”。
和 role="status" / role="alert" 搭配使用的实际效果
role="status" 默认隐含 aria-live="polite" 和 aria-atomic="true"，适合轻量状态反馈；role="alert" 则等价于 aria-live="assertive"，且自动获得更高优先级。
- 直接写
<div role="status">上传中…</div>比手动写aria-live更简洁，语义也更明确 -
role="alert"不需要额外加aria-live，但要注意它会绕过 polite 队列，慎用 - 若需自定义原子性（比如只想读新增行不重读整块），仍建议显式用
aria-live+aria-atomic组合
别指望 role="log" 能自动滚动并播报——它只是语义标记，是否播报仍取决于是否设了 aria-live，且多数屏幕阅读器对它的支持不如 status 或 alert 稳定。
真正难的不是加属性，而是判断哪些变化值得播报、什么时候该停、以及如何让 JS 更新节奏和屏幕阅读器的语音缓冲区对齐。多在真实设备上用 VoiceOver / NVDA 测试几次，比查文档管用。
