必须在页面首次加载时就写死在html中，不能靠js动态创建或后期添加aria-live属性，否则nvda、jaws、voiceover全部静音；最常被忽略的是元素未进入可访问性树——需确保初始存在、可见、未被aria-hidden="true"隔离，且必须显式声明aria-live才触发播报。
必须在页面首次加载时就写死在 HTML 里，不能靠 JS 动态创建或后期加 aria-live 属性——否则 NVDA、JAWS、VoiceOver 全部静音。
为什么写了 aria-live 却完全没播报？
最常被忽略的不是属性值写错，而是元素根本没进可访问性树。屏幕阅读器只监听已挂载、可见、且未被 aria-hidden="true" 隔离的节点。
- 检查该
div是否在初始 HTML 中存在（不是document.createElement后插入） - 确认没设
display: none或visibility: hidden；用.sr-only类替代（position: absolute; clip: rect(...)） - 父容器不能有
aria-hidden="true"，否则子级aria-live直接失效 - 旧版 NVDA 在内容全量替换时可能需要显式加
aria-atomic="true"才触发
aria-live="polite" 和 aria-live="assertive" 怎么选？
关键看用户是否需要立刻中断当前操作来接收这条信息。
-
aria-live="polite"：适合“搜索结果共 12 条”“已保存”“上传中 45%”。等用户读完当前句再播，不打断表单填写或导航 -
aria-live="assertive"：只用于真正紧急的场景，比如“验证码错误，请重试”“登录失败，账号被锁定”。会强行切掉正在朗读的说明文字 - 别把所有提示都设成
assertive——频繁打断会让用户关闭语音反馈，等于放弃无障碍
怎么确保只读新增内容，而不是整块重读？
依赖 DOM 更新方式，不是靠属性开关。屏幕阅读器对“追加”和“替换”的响应逻辑完全不同。
- 要只读新消息（如聊天列表），用
insertAdjacentHTML("beforeend", "<p>新消息</p>")或appendChild() - 避免
innerHTML = newText或textContent = newText全量覆盖——这会导致整块重读，语义断裂（比如只读出“65%”，不带“上传中”） - 若必须替换内容，先清空再写入时加
setTimeout(() => { el.textContent = newText; }, 10)，能减少重复播报 - 结构复杂区域（含链接/按钮）慎用
aria-atomic="true"，可能引发聚焦混乱；优先拆分为多个专用 live 区域
必须配 aria-atomic="true" 吗？
对状态类文案（如“已提交”“处理失败”）是刚需，否则屏幕阅读器大概率只读出孤立词，丢失上下文。
-
aria-atomic="true"强制整块区域内容作为单一语义单元播报，例如读出“上传中 72%”，而非仅“72%” - 默认
aria-atomic="false"适合纯追加场景（如日志流），但风险高：更新一个span里的数字，可能漏掉前缀文本 - 别在
aria-live容器里再嵌套另一个aria-live——原子性失效，播报像卡顿录音
最容易被绕开的细节是：role="status" 或 role="alert" 本身不触发播报，它们只是语义标签；真正起作用的是 aria-live 属性。漏掉它，再标准的 role 也等于没写。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
