ARIA live 怎样播报异步状态变化

我在给异步表单补无障碍提示时，最容易漏掉的不是按钮名称，而是“结果已经变了，但焦点还在原来的输入框里”。视力正常的用户能看到状态文字，屏幕阅读器用户却可能完全不知道请求已经完成。这个场景适合用 live region 播报，不需要为了提示结果强行移动焦点。

普通的处理中、已完成和可恢复失败提示，优先放进 role="status" 区域；它默认使用礼貌播报，等用户当前语句或操作告一段落后再通知。只有确实需要立刻打断的内容，才考虑更强的语义。

先把普通异步结果放进 status

status 是给用户提供咨询性状态的 live region，适合搜索结果刷新、保存完成、导入处理中这类不需要抢焦点的消息。MDN 对它的默认语义是 aria-live="polite" 和 aria-atomic="true"。为了照顾实现差异，我习惯把 aria-live="polite" 明确写出来，让代码读者一眼看到播报优先级。

  昵称 
  保存

这里的关键不是把文字隐藏起来，而是让状态节点在页面初始化时就存在，异步完成后只修改它的文本。status 不应该接收焦点；如果用户必须跳到错误位置或继续操作某个控件，那就应该给那个控件设计明确的焦点路径，而不是让 live region 代替交互。

连续更新时把播报频率降下来

上传进度、批量校验或搜索联想会在短时间内多次改写 DOM。每一次改动都触发播报，用户听到的可能是一串过时消息。普通状态使用 polite，并不等于可以无限频繁地更新；消息本身仍要做节流或合并。

const status = document.querySelector('#save-status');
let announceTimer;

function announceProgress(value) {
  // 合并短时间内的多次进度变化，避免把过时数字连续播报出去。
  window.clearTimeout(announceTimer);
  announceTimer = window.setTimeout(() => {
    status.textContent = `已完成 ${value}%`;
  }, 300);
}

function replaceResult(message) {
  // 结果容器保持单一短句，便于 aria-atomic=true 完整播报。
  status.textContent = message;
}

aria-atomic 决定辅助技术是读变化的片段，还是重新读整个区域；status 默认是原子区域。如果状态区域里混入很长的标题、计数器和帮助文案，每次更新都可能把整段内容重新读一遍，实际体验会变差。把它收敛成一条短消息，通常比继续堆属性更有效。

当一组 DOM 更新需要一起完成时，可以短暂使用 aria-busy="true" 表示区域仍在更新，完成后再恢复为 false。它适合控制一批相关变化，不适合拿来掩盖一个永远没有结束的请求：

function setBatchState(isBusy, message = '') {
  // 批量更新期间先标记繁忙，收尾时再给出一次最终状态。
  status.setAttribute('aria-busy', String(isBusy));
  if (message) status.textContent = message;
}

不播报或重复播报时，先查四个边界

1. 节点是否常驻：不要在每次请求完成时才创建并插入 live region。先放一个空节点，再更新文本，通常更稳定。
2. 更新是否真的发生在区域内：如果只改变了旁边的图标、CSS 或普通文本，而 status 节点没有文本变化，辅助技术没有新的播报内容。
3. 优先级是否过高：aria-live="assertive" 会立即打断当前播报，普通保存成功不该使用它。紧急错误也要先确认是否真的需要打断。
4. 消息是否重复：相同文本连续赋值没有用户价值。给状态消息做去重，并把高频进度改成阶段性文案。

排查时不要把“浏览器里看见了文字”当成“辅助技术一定会播报”。live region 负责把动态变化暴露出来，但最终体验还受屏幕阅读器、浏览器组合和页面更新方式影响。实际项目里应使用目标用户会用的辅助技术进行人工回归；文章里的结构图只用于解释关系，不是兼容性证明。

相关问题

role="status" 能替代 role="alert" 吗？
不能简单替代。status 适合不打断用户的咨询性消息，alert 面向更紧急的错误或警告，选择时先看消息是否必须立即抢占当前播报。

为什么已经写了 aria-live="polite" 还是没有声音？
先确认节点是常驻的、文本确实发生变化、更新没有被 aria-busy 长时间压住，再用目标浏览器与屏幕阅读器组合回归。

状态文字应该放到哪里？
放在与操作结果相邻、视觉上可理解的位置，同时保持它是可被辅助技术感知的独立状态节点；不要为了隐藏它而把它从辅助技术树中移除。

参考资料：https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/status_role、https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-live、https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-atomic。