### 在渲染链路中,可访问性延迟往往被忽略,但它的影响其实很直接
屏幕阅读器无法读取最新状态,这才是真正的“看不见”。例如,按钮上的 `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 毫秒,用户听到“提交中”时按钮还没变灰,信任感就会断裂——这不仅是技术问题,更是可访问性契约的失效。