aria-live 是唯一能让屏幕阅读器感知 DOM 变化的属性,需配合 aria-atomic(控制重读范围)和 aria-relevant(过滤变更类型)才能准确播报;仅设属性或错误更新 DOM 均会导致失效。
aria-live 是唯一能真正让屏幕阅读器感知 DOM 变化的属性,不加它,再“实时”的更新对视障用户来说都是静音的。
它不是“开/关”开关,而是播报策略选择器:
aria-live="polite":等用户当前朗读完再报,适合搜索建议、表单校验提示这类“别打断我”的场景aria-live="assertive":立刻中断当前播报,只用于登录失败、保存出错等必须抢话的紧急通知aria-live="off":几乎不用——直接删掉属性更干净,留着反而可能被误读为显式禁用别硬套“实时就该 assertive”,滥用 assertive 会让用户烦躁甚至关闭语音反馈。
默认情况下,aria-live 区域里只改了一个 <span> 的文本,屏幕阅读器可能只读出“23”,而不会告诉你这是“上传进度 23%”。语义断裂,等于没通知。
立即学习“前端免费学习笔记(深入)”;
aria-atomic="true":整个 live 区域重读,适合状态类文案(如“已保存”“正在处理…”)aria-atomic="false"(默认):只读变化节点,省流量但风险高,尤其当更新的是子元素而非纯文本时别在 aria-live 容器里嵌套另一个 aria-live,原子性会失效,读起来像卡顿录音。
一个实时区域可能同时改文本、增删节点、切 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 形同虚设:
data,没触达真实 DOM —— aria-live 不监听变量aria-live 区域内用 v-if 或 ngIf 切换整个子树,相当于销毁重建,播报逻辑断层aria-live 容器加 key,每次更新都被当成新节点,读两遍aria-live 放在 <output> 里指望自动刷新 —— <output> 本身不监听任何变化,必须手动写 .value
最常被忽略的,是以为加了属性就万事大吉。实际要跑通,得同时盯住 DOM 更新路径、播报粒度、以及辅助技术的真实行为链路。