高可访问性HTML脚手架必须集成html-validate、eslint-plugin-jsx-a11y（或vue中对应a11y规则）、运行时检测三者，缺一不可；需通过loader/plugin使html-validate覆盖.vue/.tsx模板，用eslint补位动态HTML，强制DOMPurify+白名单管控v-html类风险，并在CI双校验阻断合并。
直接说结论：高可访问性 HTML 脚手架不是“选个带 a11y 字样的模板”就能解决的，它必须把 html-validate、eslint-plugin-jsx-a11y（或 eslint-plugin-vue 中的 a11y 规则）、运行时检测三者嵌进构建链路里，缺一不可。
怎么让 html-validate 真正覆盖 Vue/React 模板？
默认情况下 html-validate 只扫 .html 文件，对 .vue 里的 <template> 或 .tsx 里的 JSX 完全无视——这不是配置问题，是设计限制。
- Vue 项目必须加
html-validate-loader（Webpack）或vite-plugin-html-validate（Vite），把校验逻辑注入模板编译阶段 - React 项目需配合
eslint-plugin-jsx-a11y，重点启用jsx-a11y/alt-text、jsx-a11y/label-has-for等规则，因为 JSX 不是 HTML，html-validate无法解析其语法树 -
.htmlhintrc不能复用：Vue 的v-bind:会触发attr-no-duplication误报；React 的onClick在 JSX 中合法，但会被当成 HTML 属性报错 - 动态拼接 HTML（如
el.innerHTML = '<img src="x">'）完全逃逸html-validate，必须靠eslint-plugin-no-inner-html补位
为什么只配 eslint-plugin-vue/no-v-html 不够？
vue/no-v-html 能拦住裸写 v-html，但拦不住封装后的危险调用——比如 renderHtml(userInput) 这种函数，表面安全，实际可能绕过 XSS 过滤。
- 必须在脚手架初始化时强制注入
DOMPurify，并规定所有富文本渲染必须走DOMPurify.sanitize() -
eslint.config.js中要设白名单：仅允许调用明确标注为安全的函数（如safeHtml()），且该函数内部必须调用DOMPurify - 禁止在
data或props中直接传 raw HTML 字符串，否则no-v-html规则根本不起作用 - CI 阶段要跑
html-validate src/**/*.vue --config .htmlhintrc+eslint --ext .vue,.ts src/双校验，单侧失败即阻断合并
可访问性检查容易被忽略的三个盲区
很多团队以为装了 Axe 插件就万事大吉，其实真正上线后出问题的，往往卡在这几个地方：
立即学习“前端免费学习笔记（深入）”；
-
<input type="checkbox">缺<label for="id">或<label>包裹</label>：ESLint 能抓，但开发者常手动删掉 label 以“简化样式”，结果屏幕阅读器读不出控件用途 - 动态生成的 modal 弹窗没设
aria-modal="true"和焦点捕获逻辑：静态校验工具完全无法发现，必须靠axe-core运行时扫描 - 中英文混排页面的
lang属性只写在<html>根节点，但某段中文内容里插了英文术语，没用<span lang="en">显式声明——TTS 引擎会用错误音调朗读 - 表格没用
<caption>或role="grid"，导致视障用户无法理解数据关系：W3C 验证器不报错，html-validate默认也不启accessibility规则集
真正的难点不在工具集成，而在规则边界：哪些 a11y 问题必须静态拦截（如缺 alt），哪些只能靠运行时反馈（如焦点管理失效），哪些得靠人工走查（如语义层级是否符合业务逻辑）。脚手架能固化前两者，但第三类永远需要人盯。
