微任务无法检测HTML可访问性漏洞，因其不生成真实DOM、不触发渲染、不模拟辅助技术；应通过构建时html-validate+自定义规则、框架插件及CI中axe-core在真实浏览器环境扫描三者结合保障。
自动化微任务不能直接检测 HTML 模板的可访问性漏洞——它连 DOM 都没生成，更谈不上语义、焦点、ARIA 或屏幕阅读器行为。所谓“微任务检测”，本质是混淆了构建时（build-time）和运行时（run-time）的责任边界。
为什么 Promise.then 或 queueMicrotask 无法用于可访问性检测
微任务只在 JS 执行栈清空后、渲染前执行一次回调，它不触发 DOM 解析、不加载资源、不模拟辅助技术。可访问性问题绝大多数依赖于：
- 真实渲染后的 DOM 结构（比如
aria-hidden是否误封了焦点元素） - 浏览器对语义标签的原生支持（如
<nav></nav>是否被 VoiceOver 正确识别） - 动态内容更新是否触发
aria-live且节奏合理 - 键盘焦点是否可抵达、可感知、可循环
这些都超出了微任务的能力范围。你用 queueMicrotask 去检查 document.body，得到的只是服务端吐出的原始 HTML 字符串或 hydration 前的空壳，不是可测试的真实界面。
真正能介入模板层的自动化检测点在哪
可在构建流程中嵌入静态分析，但必须明确它只覆盖“可访问性前置条件”，而非运行时表现：
立即学习“前端免费学习笔记（深入）”；
-
html-validate+ 自定义规则：检查模板中是否遗漏alt、label、lang、标题层级跳变、role与标签冲突（如<button role="link"></button>） - Vue/React 插件（如
eslint-plugin-jsx-a11y）：在 JSX/模板编译前拦截常见反模式，例如onClick绑定在div上却没加role="button" tabIndex="0" - CI 中跑
axe-core的analyze()方法：前提是已启动一个最小 HTTP 服务并加载完整页面（即绕过“纯模板”阶段，进入可交互上下文）
注意：axe-core 在无头浏览器中运行时，才真正具备可访问性检测能力；脱离浏览器环境调用它，只会报 "document is not defined" 或返回空结果。
容易被忽略的模板层陷阱
很多团队以为加了 aria-label 就万事大吉，但模板编译过程会悄悄破坏可访问性：
- SSR 框架中，
v-if或{#if}导致条件渲染区块缺失，而对应aria-labelledby引用的 ID 仍写死在模板里 → 运行时报错且屏幕阅读器静默 - 组件库自动注入的
id（如id="input-123"）在 SSR 和 CSR 间不一致 →label[for]失效 - 富文本字段直接用
v-html渲染，未过滤掉用户插入的onerror或tabIndex="-1"→ 键盘导航断裂
这些问题不会在 queueMicrotask 里暴露，只能靠构建时规则 + 运行时 axe 扫描 + 手动键盘走查三者交叉验证。
真正有效的可访问性保障，始于模板约束，成于 DOM 实例，验于真实辅助技术。别把微任务当万能钩子——它连 document 都不一定能看见，更别说听见屏幕阅读器怎么读了。
