### 在渲染链路中，可访问性延迟往往被忽略，但它的影响其实很直接
屏幕阅读器无法读取最新状态，这才是真正的“看不见”。例如，按钮上的 `aria-busy="true"` 如果没有及时设置，用户点击后就会卡住；表单的 `aria-invalid="true"` 若延迟半秒才生效，错误提示会被直接跳过。这类问题在 Performance 面板中并不显眼，但通过 Accessibility Inspector（Chrome DevTools → Accessibility → Live region）可以直接观察到 `aria-live` 区域的更新时间戳偏移。
### JS延迟导致ARIA状态更新滞后，怎么抓到它？
更可靠的捕获方式是监听 DOM 变化并结合 ARIA 属性变更：
- 使用 `MutationObserver` 监听目标元素的 `aria-*` 属性变动，记录 `startTime` 与实际更新时间差。
- 对关键交互（如提交、切换）打上 `Performance.mark`，再利用 `performance.measure('aria-update', 'submit-start', 'aria-set')` 量化延迟。
- 禁用 JavaScript 后手动触发操作，对比无障碍树是否立即响应——若禁用 JS 后反而更准确，说明 JS 逻辑本身阻塞了同步更新。
### 为什么defer脚本仍会拖慢ARIA更新？
`defer` 仅保证脚本在 DOM 就绪后执行，但并不保证执行速度。如果脚本中存在长任务（例如遍历 500 个 `input` 并逐个设置 `aria-invalid`），主线程会被占满，ARIA 变更被迫排队，导致屏幕阅读器感知到“卡顿”。尤其在 SSR hydration 场景下，React 或 Vue 的 `useEffect` 或 `mounted` 钩子往往在 `defer` 脚本之后运行，形成双重延迟。
真正有效的做法不是“等 JS 跑完再设 ARIA”，而是将 ARIA 变更拆解出来提前执行：
- 表单验证失败时，立即同步写入 `element.setAttribute('aria-invalid', 'true')`，不要等待校验函数返回后再统一处理。
- 避免在 `for` 循环中批量设置 ARIA——改用 `requestIdleCallback` 分片更新，或至少使用 `setTimeout(fn, 0)` 让出主线程。
- 对动态插入的 DOM（如 `appendChild`），插入后立即设置 `aria-hidden="false"`，不要等后续 JS 逻辑执行完毕。
### JS失效时，ARIA兜底方案怎么写才有效？
当 JS 加载超时或执行报错时，`aria-*` 属性根本不会出现，屏幕阅读器会直接读取原始 HTML。此时无法依靠 JS 补救，必须通过 HTML 层硬编码并配合 `noscript` 降级：
- 所有交互控件默认带有 `aria-disabled="true"`，JS 成功加载后才改为 `false`——防止 JS 未加载时用户误操作。
- 使用 `
` 包裹纯语义化替代内容，例如 `
`，而不是留白。
- 关键状态用 `data-` 属性预埋，CSS 通过 `[data-state="error"] .input::after` 提供视觉反馈，ARIA 则由 JS 启动后一次性同步过去，避免 JS 失效时完全失语。
### 动态加载JS后，如何确保ARIA树重建不丢节点？
通过 `import()` 或 `document.createElement('script')` 加载模块后，新组件挂载可能触发无障碍树局部刷新，但旧节点的 ARIA 关系（例如 `aria-labelledby` 指向的 `id`）若被 JS 重写或移除，屏幕阅读器会找不到目标，报出“referenced element not found”错误。
修复核心在于保持 ID 稳定性与关系显式化：
- 禁止动态生成 `id` 值（例如 `id="btn-${Date.now()}"`），改用静态 `data-id` 配合 CSS 选择器定位。
- `aria-labelledby` 和 `aria-describedby` 必须引用已存在于 DOM 中的 `id`，加载新模块前先检查目标元素是否存在，不存在则用 `aria-label` 兜底。
- 对通过 `innerHTML` 替换的内容，确保新 HTML 中包含完整的 ARIA 关系链，不要依赖 JS 后续修补。
最容易被忽视的是：ARIA 状态更新必须与视觉反馈严格同步。即使 JS 只慢 100 毫秒，用户听到“提交中”时按钮还没变灰，信任感就会断裂——这不仅是技术问题，更是可访问性契约的失效。
