静态html生成器仅支持预防性注入而非自动修补，必须在生成阶段强制执行alt属性、button type和标题层级三类可访问性守门员规则，并在构建内存中实时校验htmlhint。
静态HTML生成器不支持“自动修补”，只支持“预防性注入”
所谓“内置自动修补”，是常见误解。静态HTML生成器本身没有运行时能力，不能像axe DevTools那样扫描DOM再改写属性。它只能在生成阶段，把可访问性规则固化进模板逻辑里——比如强制所有 <img> 必须带 alt，或给 <button></button> 默认加上 type="button"。一旦HTML文件写出，就再无干预机会。
常见错误现象：导出后用 Lighthouse 扫出一堆 alt 缺失、button 无 type、aria-* 拼错——说明生成器没在源头堵住，而是指望你手动补。
- 检查生成器是否允许自定义 HTML 模板片段（如 Eleventy 的
.njk、Astro 的.astro），这是唯一能植入策略的地方 - 避开“所见即所得”类工具（如某些在线拖拽生成器），它们连
alt输入框都可能默认留空 - 若用 Markdown → HTML 流水线，确保 remark-plugin-a11y 或 rehype-a11y 插件已启用，而非仅靠 Prettier 格式化
必须硬编码的三项可访问性守门员规则
这三条不是建议，是底线。漏掉任何一条，生成的 HTML 就算通过 HTMLHint，也大概率被屏幕阅读器跳过或误读。
-
<img>标签：生成器必须拒绝渲染空alt=""，且不允许跳过该字段；若用户未填，应 fallback 为alt="图示：[文件名]"而非留空 -
<button></button>标签：默认输出<button type="button">...</button>，而不是依赖开发者手输；type="submit"只能在表单内部显式声明时才允许 - 标题层级：
<h2></h2>后禁止直接跟<h4></h4>，生成器需校验当前标题深度，自动插入占位<h3></h3>或报错中断，而非静默跳级
HTMLHint 必须在构建内存中实时校验
等 HTML 文件写到磁盘再跑 htmlhint，等于让问题落地生根。真正有效的时机，是在模板引擎吐出字符串、但还没存盘前，把那段 HTML 字符串喂给 HTMLHint.verify()。
典型陷阱：本地跑 htmlhint 不报错，CI 却失败——大概率是 CI 环境用了旧版 parse5 解析器，对 <img class> 这类现代属性判为非法。必须统一 htmlhint 版本与解析器，并在配置中显式排除合法属性：
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
{
"attr-bans": ["align", "border"],
"attr-reqs": ["alt"],
"attr-validate": true,
"tag-pair": true
}
注意：attr-reqs 规则必须设为 ["alt"]，否则无法捕获图片缺描述的问题；tag-pair 开启才能发现 <p>文本</p>
<div>嵌套</div> 这类结构错误。
别信“一键修复”按钮，要盯住构建日志里的真实输出
很多生成器界面提供“修复可访问性”按钮，点完弹窗说“已优化”，但实际只是加了 role="navigation" 或 tabindex="0" 这类表面功夫。真正有效的验证，是看构建日志里是否出现类似这样的行：
[htmlhint] ✅ /dist/index.html: no errors (3 warnings → 0)
如果日志里只有 ✓ Built in 123ms，没提 HTMLHint 结果，说明规则压根没生效。更危险的是，某些工具把校验结果藏在“高级报告”里，默认折叠，你不主动点开就以为万事大吉。
复杂点不在怎么配，而在你是否愿意让构建失败来倒逼质量——比如把 HTMLHint 的警告当错误（--fail-on-warn），哪怕只是缺一个 alt，也中断部署。这不是矫情，是防止“这次先上线，下个迭代再修”的惯性滑坡。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
