aria-busy 必须在异步操作开始前立即设为 true，完成后显式设为 false；它与 aria-live 协作控制播报时机，避免中间态干扰；配合焦点管理确保键盘用户操作连贯。
aria-busy 该在什么时机设为 true
异步操作开始时必须立刻设置 aria-busy="true"，不是等 loading 状态渲染完才设。否则屏幕阅读器会读到旧内容，再突然跳到新内容，造成语义断裂。
常见错误是把 aria-busy 和视觉 loading 提示绑定在同一 DOM 更新点——比如先清空容器、再插入“加载中”文字、最后设 aria-busy。这中间有毫秒级空窗，辅助技术可能读到空白或残留内容。
- 正确做法：调用异步函数前，立即执行
element.setAttribute('aria-busy', 'true') - 随后可同步更新 DOM（如插入 loading 文本、禁用按钮），无需等待 Promise
- 成功或失败后，必须显式设为
aria-busy="false"，不能依赖重绘自动清除
aria-live 配合 aria-busy 的组合逻辑
aria-live 不是“开了就播报”，它只对动态插入的、未被标记为 aria-busy="true" 的内容生效。两者是协作关系，不是替代关系。
典型场景：搜索结果列表更新。如果只设 aria-live="polite"，而没管 aria-busy，用户可能在数据加载中途听到“找到 0 条结果”，然后又听到“找到 12 条结果”——两次播报，且中间状态混乱。
立即学习“前端免费学习笔记（深入）”；
- 推荐结构：
<div aria-live="polite" aria-atomic="false"></div>作为结果容器 - 异步开始前：
container.setAttribute('aria-busy', 'true') - 异步完成后：先清空容器，再插入新内容，最后
container.setAttribute('aria-busy', 'false') - 这样
aria-live只会在aria-busy="false"后播报最终结果
为什么不能只靠 role="status" 或 aria-live 单独解决
role="status" 默认等价于 aria-live="polite"，但它不感知异步过程；aria-live 本身也无法阻止中间态播报。两者都缺乏“操作进行中”的语义锚点。
例如，一个提交表单按钮点击后，页面局部刷新但没设 aria-busy，屏幕阅读器可能在请求发出后立刻读出“提交成功”，而实际后端还没响应——这是典型的语义错位。
-
aria-busy是唯一能明确告诉辅助技术“这部分内容正在变化、请暂缓播报”的标准属性 -
role="status"适合静态提示（如“保存成功”），不适合包裹异步区域 - 若用
aria-live区域内嵌套其他aria-live元素，会导致播报冲突，应避免嵌套
容易被忽略的焦点管理配合点
异步内容替换后，如果新内容里有可聚焦元素（比如新加载的按钮或链接），光靠 aria-busy 和 aria-live 不足以保证键盘用户操作连贯——焦点可能还停在旧 DOM 上，甚至丢失。
这不是可选优化，而是可访问性硬性要求：当异步区域内容完全替换，且新内容含交互控件时，必须主动移动焦点。
- 不要用
focus()直接打在第一个子元素上——它可能不可见或 disabled - 优先聚焦语义最重的元素，比如新面板的主标题（
h2）或首个可操作按钮 - 若新内容无自然焦点目标，至少确保容器有
tabindex="-1"并调用focus()，让用户能继续 Tab 导航 - 别忘了同时更新
aria-labelledby或aria-describedby指向新内容，否则焦点元素的上下文描述仍是旧的
