aria-live 是唯一能让屏幕阅读器感知 DOM 变化的属性，需配合 aria-atomic（控制重读范围）和 aria-relevant（过滤变更类型）才能准确播报；仅设属性或错误更新 DOM 均会导致失效。
aria-live 是唯一能真正让屏幕阅读器感知 DOM 变化的属性，不加它，再“实时”的更新对视障用户来说都是静音的。
aria-live 的三个取值怎么选
它不是“开/关”开关，而是播报策略选择器：
-
aria-live="polite"：等用户当前朗读完再报，适合搜索建议、表单校验提示这类“别打断我”的场景 -
aria-live="assertive"：立刻中断当前播报，只用于登录失败、保存出错等必须抢话的紧急通知 -
aria-live="off"：几乎不用——直接删掉属性更干净，留着反而可能被误读为显式禁用
别硬套“实时就该 assertive”，滥用 assertive 会让用户烦躁甚至关闭语音反馈。
为什么只加 aria-live 还不够，必须配 aria-atomic
默认情况下，aria-live 区域里只改了一个 <span></span> 的文本，屏幕阅读器可能只读出“23”，而不会告诉你这是“上传进度 23%”。语义断裂，等于没通知。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
aria-atomic="true"：整个 live 区域重读，适合状态类文案（如“已保存”“正在处理…”） -
aria-atomic="false"（默认）：只读变化节点，省流量但风险高，尤其当更新的是子元素而非纯文本时
别在 aria-live 容器里嵌套另一个 aria-live，原子性会失效，读起来像卡顿录音。
aria-relevant 控制“哪些变才值得读”
一个实时区域可能同时改文本、增删节点、切 class，但不是所有变更都需要播报。全靠 aria-relevant 过滤：
-
aria-relevant="text"：只响应文本内容变化，适合计数器、状态文案 -
aria-relevant="additions"：只对新增节点触发播报，适合聊天消息流 -
aria-relevant="all"（默认）：新增、删除、文本改、属性变全报——容易刷屏，慎用 - 多个值用空格分隔，如
aria-relevant="additions text"；别加removals，读“某某已消失”毫无意义
DOM 更新方式直接影响生效：用 innerHTML 替换整个容器，或 React 中给容器设 key，都可能导致重复播报或漏播。优先用 textContent 或 innerText 更新纯文本。
常见翻车点：你以为在更新，其实屏幕阅读器根本没听见
这些操作会让 aria-live 形同虚设：
- 只改 JS 变量或 Vue
data，没触达真实 DOM ——aria-live不监听变量 - 在
aria-live区域内用v-if或ngIf切换整个子树，相当于销毁重建，播报逻辑断层 - React 中给
aria-live容器加key，每次更新都被当成新节点，读两遍 - 把
aria-live放在<output></output>里指望自动刷新 ——<output></output>本身不监听任何变化，必须手动写.value
最常被忽略的，是以为加了属性就万事大吉。实际要跑通，得同时盯住 DOM 更新路径、播报粒度、以及辅助技术的真实行为链路。
