aria-relevant仅筛选需播报的变更类型，不控制频率；真正决定播报时机的是aria-live的polite或assertive取值。它只响应真实dom节点插入（如appendchild），不响应innerhtml替换或文本覆盖，选错值会导致漏报或重复播报。
aria-relevant 本身不控制更新频率，它只筛选“哪些变更值得播报”；真正决定播报时机的是 aria-live 的取值（polite 或 assertive）。
aria-relevant 不是定时器，也不是节流开关
很多人误以为设成 aria-relevant="additions" 就能“每秒只报一次新增”，其实它完全不干预更新节奏。它只是告诉屏幕阅读器：“当 DOM 新增节点时，才触发播报；文本改了、属性变了、删了节点——这些都不管”。
常见错误现象：aria-relevant="additions" 配合 innerHTML = newHTML 使用，结果一条消息刷十次，读十遍——因为每次赋值都清空再重建整个子树，浏览器视作多次“新增节点”。
-
aria-relevant只响应真实 DOM 节点插入（如appendChild()、insertAdjacentElement()），不响应字符串拼接或 innerHTML 替换 - 想降低播报频次，得从更新方式入手：用追加代替重写，用
textContent改文本而不是替换整个<div> <li>若内容高频变动（如倒计时、实时股价），优先选 <code>aria-relevant="text"+aria-live="polite"，避免打断用户 - 聊天消息列表用
additions合理：每条新消息是独立<li>，append 进去就自然触发播报 - 状态栏显示“剩余 3 秒”→“剩余 2 秒”，用
additions完全无效（没新节点），必须用text -
aria-relevant="removals"基本别用：NVDA、VoiceOver 都不支持，写了也白写 - 组合使用如
aria-relevant="additions text"是安全的，但别加removals - 紧急提示（如表单校验失败）必须用
aria-live="assertive"，否则可能被延迟数秒 -
assertive会中断当前语音，慎用于非关键信息，否则用户会烦躁 - 不要给同一个容器反复切换
aria-live值，AT（辅助技术）可能缓存旧策略，导致行为不一致 - React/Vue 等框架里，避免给
aria-live容器设key，否则每次更新都被当新元素，重复播报
additions vs text：选错会导致“该读的不读，不该读的狂读”
additions 看的是节点结构变化，text 看的是可访问树中“可渲染文本”的实际差异。两者行为差异极大：
为什么 aria-live="polite" 有时像没反应？
不是没生效，是它在等用户“空闲”——比如用户正用键盘导航、正在打字、或刚点击按钮，polite 会把播报排队到操作结束后。这容易被误判为失效。
最常被忽略的一点：aria-relevant 的效果完全依赖于真实的 DOM 变更路径。用虚拟 DOM diff 渲染、或靠 CSS display: none 切换内容，都不会触发任何播报——屏幕阅读器只认真实挂载/卸载的节点和可访问树中的文本变更。
