aria-live区域必须在初始HTML中声明，不能JS动态创建后添加属性；需搭配aria-atomic="true"和aria-relevant="text"，内容更新须用textContent而非innerHTML，避免高频刷新导致播报丢失。
aria-live区域必须提前声明，不能动态创建后才加属性
WAI-ARIA 的 aria-live 不会监听 DOM 节点的“诞生”，只监控已存在节点的内容变化。如果在 JS 里先 document.createElement('div')，再 el.setAttribute('aria-live', 'polite')，然后 append()，多数屏幕阅读器（尤其是 NVDA、VoiceOver）根本不会识别这个 live 区域。
正确做法是：页面加载时就预留一个空容器，并带上 aria-live 属性：
<div aria-live="polite" aria-atomic="true" aria-relevant="additions text"></div>
-
aria-live值选polite（默认打断低优先级朗读）或assertive（立即中断当前播报，慎用） -
aria-atomic="true"确保整个区域内容被完整朗读，避免只读新增文本片段 -
aria-relevant="additions text"表示只对新增文本和文本变更敏感（不响应 class 变化或子节点移除）
动态更新内容必须用 innerText 或 textContent，别用 innerHTML 插入 HTML 标签
如果往 aria-live 区域写入含标签的字符串（比如 el.innerHTML = '<strong>成功</strong>'），NVDA 可能静默，JAWS 可能报错，VoiceOver 则可能跳过或重复。原因是屏幕阅读器对富文本解析不一致，且 aria-live 本意是播报「信息」，不是渲染界面。
安全写法只有两种：
立即学习“前端免费学习笔记（深入）”；
-
el.textContent = '操作成功'（最推荐，无风险） -
el.innerText = '操作成功'（会触发重排，但语义清晰）
若真需强调文字（如“失败”标红），应通过 CSS 控制已有文本节点的样式，而不是插入 <span class="error">。
避免高频更新导致播报被吞或卡顿
连续多次快速设置 textContent（例如轮询状态、打字效果、毫秒级倒计时），会导致屏幕阅读器来不及播报前一条，直接覆盖——用户只听到最后一句，甚至完全没反应。
- 对非关键提示（如“正在加载…”），用
aria-live="off"临时关闭，完成后再切回polite - 对连续状态流（如进度 10% → 20% → …），建议节流：仅当变化 ≥ 10% 或间隔 ≥ 500ms 才更新
textContent - 不要在
requestAnimationFrame或setInterval里无条件更新 live 区域
测试时别只信 Chrome + Lighthouse，必须手动验证真实屏幕阅读器
Lighthouse 的 ARIA 检查只验属性是否存在，不验播报行为。Chrome 自带的“实时字幕”或 macOS 的“语音反馈”也替代不了真实场景。
- Windows 下必测 NVDA + Firefox（最严苛，对
aria-atomic和更新节奏最敏感） - macOS 下必测 VoiceOver + Safari（对
aria-relevant解析偏宽松，但对动态插入极挑剔） - Android TalkBack 测试时注意：它依赖 Android 的 AccessibilityService，需在系统设置中开启并选对浏览器
真正容易被忽略的是：aria-live 区域必须有明确的 DOM 位置（不能 display: none 或 visibility: hidden），但可以 position: absolute; left: -9999px 移出视口——只要它在可访问树中存在且可见性未被完全屏蔽，播报就有效。
