aria-live 是屏幕阅读器播报 dom 变更的唯一开关，必须显式声明；需搭配 aria-atomic="true" 防语义断裂，并优先使用 textcontent 或 appendchild 等安全更新方式。
aria-live 必须显式声明，不加就不会播报
DOM 内容变了，屏幕阅读器不会自动感知 —— aria-live 是唯一触发播报的开关。不设这个属性，哪怕用 JS 更新了 textContent 或插入新节点，视障用户也完全不知道发生了什么。
常见错误是只写 role="status" 或 role="alert"，却漏掉 aria-live。这两个 role 值本身不带播报能力，只是语义约定；实际播报行为全靠 aria-live 驱动。
-
aria-live="polite"：适合“已保存”“加载完成”这类非打断型提示，等用户当前朗读/操作结束后再读 -
aria-live="assertive"：仅用于真正紧急的场景，如“登录失败，请重试”，会强行中断朗读，慎用 - 别写
aria-live="off"—— 直接删掉属性更安全；反复切换值会导致行为不可预测
aria-atomic="true" 不是可选项，是防语义断裂的关键
当 live 区域里只更新了一个 span（比如把“上传中”改成“上传中 72%”），默认情况下屏幕阅读器可能只读出“72%”，而漏掉上下文。这就是 aria-atomic="false"（默认值）的副作用。
aria-atomic="true" 强制整块区域内容被当作一个整体朗读，确保用户听到的是完整语义，比如“上传中 72%”，而不是孤立的数字。
- 所有状态类提示（
role="status"）、错误消息（role="alert"）都应配aria-atomic="true" - 不要在
aria-live容器里嵌套另一个aria-live区域，原子性会失效，读起来像卡顿录音 - 如果区域内容结构复杂（含链接、按钮），
aria-atomic="true"可能导致重复聚焦或冗余播报，此时需权衡是否拆分区域
aria-relevant 要精简，removals 基本不能用
aria-relevant 控制哪些 DOM 变更会触发播报，合法值只有 additions、removals、text、all（空格分隔）。但现实很骨感：removals 在 NVDA、VoiceOver 等主流阅读器中支持极弱，设了也基本不读具体内容。
真正可靠的做法是：把“删除结果”转化为一次 additions 播报。例如用户删了一条订单，不要移除 DOM 节点后指望 removals 告诉用户，而是向 live 区域插入一句：“订单 #123 已删除”。
- 日常推荐
aria-relevant="additions text"：覆盖追加节点和纯文本变更两种最常见场景 -
text只响应textContent或innerText修改，对子元素增删无效；additions正好相反 - 避免用
innerHTML = ''清空再重写 —— 这会被识别为 removals + additions，可能触发两次播报或静默失败
DOM 更新方式比属性设置更容易翻车
aria-live 只监听真实 DOM 变更，不关心 JS 变量、Vue data 或 React state。很多“不播报”问题，根源不在属性写错，而在更新手法不对。
例如聊天列表用 innerHTML 替换整个 ul，或者 React 中给 live 容器加 key 导致强制重渲染，都会让屏幕阅读器把整块内容当新节点处理，造成重复播报或跳过中间状态。
- 纯文本更新优先用
textContent，最稳 - 要增删子节点时，用
appendChild、insertBefore、removeChild，别碰innerHTML - Vue/React 中禁用
v-if/ngIf/key控制 live 区域显隐，改用v-show或 CSSopacity: 0; position: absolute; - 错误提示必须预置在 DOM 中（哪怕初始为空），动态创建后插入容易被忽略
aria-live 容器直接放在轮播 slide 内部，或嵌在列表项里。一旦父级被批量更新，整个区域的可访问性树可能被重建，之前设置的属性就形同虚设。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
