htmlhint能直接报出alt缺失或label-for不匹配，但需手动启用规则：必须在.htmlhintrc中显式配置"alt-require":true和"input-requires-label":true（后者检查for/id严格匹配），默认不启用。
HTMLHint 能否直接报出 alt 缺失或 label-for 不匹配？
不能。HTMLHint 默认不启用可访问性规则，alt-require、label-has-for 这类检查必须手动开启，否则它只做基础语法校验（比如标签闭合、属性小写）。你运行 htmlhint index.html 却没看到任何无障碍问题，大概率是因为规则没开。
开启方式很简单：在项目根目录执行 htmlhint --init 生成 .htmlhintrc，然后把下面这几条设为 true：
-
"alt-require": true—— 强制所有<img>必须带非空alt -
"label-has-for": true—— 检查<label></label>的for值是否对应真实存在的id -
"aria-allowed-attr": true—— 防止在不支持的元素上乱写aria-属性 -
"id-unique": true—— 避免重复id导致document.getElementById()返回错误节点
为什么 Lighthouse 不适合放进 CI 自动扫描可访问性？
Lighthouse 的 Accessibility 审计依赖真实浏览器环境，必须加载完整页面、执行 JS、构建最终 DOM 树才能跑完。它不适合放在 Git 提交钩子或 GitHub Actions 中做“静态”检查——CI 环境里没有渲染引擎，lighthouse --ci 实际是启动 Chromium 实例，耗时长、不稳定、容易因网络/超时失败。
真正适合 CI 的，是纯文本扫描工具。比如：
-
htmlhint：轻量、零依赖、秒级响应，但仅覆盖基础可访问性属性 -
axe-core+jest-axe：适合已用 Jest 的项目，把 HTML 字符串喂给 axe，返回结构化违规项（如 “color-contrast”、“heading-order”） -
pa11y-ci：基于 Puppeteer 封装，比 Lighthouse 更可控，能指定超时、忽略特定规则，且输出 JSON 可被 CI 解析
如何让 HTMLHint 报出 aria-label 缺失这类深层问题？
HTMLHint 内置规则不检查 aria-label 是否缺失，它只管“有没有写”，不管“该不该写”。例如一个 <button>提交</button> 没加 aria-label，HTMLHint 不会报错——因为按钮有可见文字，WAI-ARIA 规范认为这已满足最低要求。
要覆盖这类语义级缺陷，得换工具：
-
eslint-plugin-jsx-a11y：如果你的 HTML 是 JSX 或 TSX 文件，这是最准的。它能识别role="button"但没加tabindex的情况，也能警告<div onclick> 缺少 <code>role和键盘事件 -
axe-cli：命令行版 axe-core，支持扫描本地 HTML 文件：axe index.html --rules=color-contrast,heading-order，还能导出 CSV 报告 - 自定义 Cheerio 脚本：读取 HTML 后，用
$('[role="img"]:not([aria-label]):not([alt])')这类选择器精准定位漏掉无障碍属性的元素 - 把 HTMLHint 放进
pre-commit钩子：用husky+lint-staged，只扫暂存区里的 HTML 文件，不拖慢日常开发 - GitHub Actions 中设置
fail-on-error：别用npx htmlhint src/**/*.html || true这种吞错误写法，CI 应该明确失败并阻断 PR 合并 - 对高频误报项做白名单而非关规则：比如某些图标字体组件必然无
alt，就用<!-- htmlhint disable=alt-require -->注释局部关闭，而不是全局禁用
CI 流程中怎么避免可访问性检查变成摆设？
很多团队开了 HTMLHint 但没人看报告，或者把 id-unique 设成 warning 而非 error，结果重复 ID 一直留在代码里。关键不是“有没有扫”，而是“扫了之后能不能卡住发布”。
建议三件事：
可访问性缺陷往往不报错也不崩溃，但会让屏幕阅读器跳过关键按钮、让色觉障碍用户看不见表单提示——这些漏洞藏得深，靠人工 review 几乎不可能全覆盖，自动化扫描必须真起作用，而不是只在 README 里写一行命令。
