aria-relevant 控制屏幕阅读器对 aria-live 区域变更的响应类型，仅支持 additions、removals、text、all 四个取值；其中 removals 支持极弱，推荐统一用 additions 配合动态插入语义化提示文案实现可靠播报。
aria-relevant 控制哪些变更会被屏幕阅读器播报
默认情况下，aria-live 区域只对新增（additions）内容触发播报，但实际业务中常需要区分“追加”“删除”“文本修改”甚至“全部重刷”。aria-relevant 就是干这个的——它不决定是否播报，而是决定“什么变化值得播报”。
它的值是空格分隔的关键词组合，合法取值只有四个：additions、removals、text、all（等价于前三者之和）。注意：all 不是万能开关，它仍受 DOM 变更方式限制（比如直接 innerHTML = '' 清空再重写，可能被识别为 removals + additions，而非 text 变化）。
常见误用：以为设了 aria-relevant="removals" 就能听到“某某已删除”，其实多数屏幕阅读器（NVDA、VoiceOver）对 removals 支持极弱——它们通常只在元素被移出 DOM 时做极简提示（如“已删除”），不会读出具体内容。真正可靠的是靠 additions + 动态插入带语义的提示文案。
如何让“删除操作”也被清晰播报
别依赖 aria-relevant="removals" 做主要内容传达。正确做法是：把“删除结果”转化为一次新增播报。
- 用户点击删除按钮后，不在原位置移除 DOM 节点，而是向 live region 插入一条新消息，例如：
<div aria-live="polite" aria-relevant="additions"></div>
然后 JS 执行：liveRegion.textContent = "项目 '订单#123' 已删除" - 如果必须同步更新列表 DOM，确保 live region 是独立容器（不嵌套在被删/增的列表内），否则变更可能被忽略或触发意外播报
- 避免在
aria-live区域内放交互控件（如按钮），部分屏幕阅读器会跳过或错误聚焦
text 和 additions 的关键区别与陷阱
text 只响应元素**文本节点内容变化**（textContent 或 innerText 修改），不响应子元素增删；additions 响应子节点 append、insertBefore 等操作。两者行为完全不同，混用会导致静默失败。
典型翻车场景：
- 用
el.innerHTML = '新内容'更新一个aria-relevant="text"区域 → 不播报（因为 innerHTML 会重建子节点，不是纯文本变更） - 用
el.textContent = '新内容'更新aria-relevant="additions"区域 → 不播报（没新增节点，只是改了文本） - 正确匹配：
aria-relevant="text"必须配textContent；aria-relevant="additions"必须配appendChild/insertAdjacentHTML等 DOM 插入操作
兼容性与实测注意事项
不同屏幕阅读器对 aria-relevant 的实现差异很大：
- NVDA + Firefox：支持
additions和text，removals基本无效 - VoiceOver + Safari：
text在动态textContent更新时较可靠，但对快速连续变更可能合并或丢弃 - JAWS：对
aria-relevant解析较保守，建议始终搭配aria-live="polite"（assertive易打断用户） - 所有读屏器都要求 live region 在页面加载时就存在（不能 JS 动态创建后才设
aria-live），否则属性可能不生效
最稳妥的实践：只用 aria-relevant="additions"，所有状态变更都转为“插入一条新提示”，并控制插入频率（防抖 500ms），比纠结 removals 或 text 的边界行为更可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
