把HTML质量嵌进Sprint流程，比事后修bug强十倍

前端团队最怕什么？Sprint评审时，大家围在屏幕前，突然发现标签缺少替代文本，或者某个导航栏的语义标签彻底用错了——那一刻，所有人的表情都很有意思。这些问题明明可以更早被发现，但往往因为流程上的疏忽，拖到了最后审核环节。

其实，解决方案并不复杂，关键在于把HTML验证的关卡前移，并让它成为不可绕过的硬性门槛。

HTML验证失败直接卡住Sprint评审

HTML语法错误、缺失替代文本、未闭合标签——这些基础问题，只要CI流水线中接入了html-validate或vnu.jar，就能在PR阶段自动拦截。等到Sprint评审时现场打开浏览器开发者工具才发现，修改代码加回归测试的时间成本早已不可控。

具体操作上，有几点值得注意：

• 把html-validate配置成npm run validate:html脚本，加入pre-commit和CI的test阶段
• 团队共用一份.htmlvalidate.json，重点开启require-alt、require-lang、no-unknown-elements规则
• 对于CMS生成页或模板引擎输出（如handlebars），需要在配置中用ignoreFiles排除动态片段，否则误报率会很高

语义化不是“加分项”，而是验收必检项

用

代替

，或者把导航塞进里——视觉上可能看不出区别，但对屏幕阅读器路径、SEO权重以及WCAG 2.1 AA级合规性来说，都是硬伤。Sprint计划会必须明确：所有新增页面组件，需通过axe-core扫描且violations为0才能进入评审。

落实到日常开发，可以这样做：

• 本地开发时使用Chrome插件Axe DevTools，右键→“Analyze”一键检测
• 自动化集成选jest-axe，配合React/Vue组件测试，在describe里写expect(await axe(container)).toHa veNoViolations()
• 警惕“伪语义”：比如给加role="link"却不处理Enter/Space键行为，这反而更不合规

构建产物里的HTML不能靠“肉眼确认”

开发环境跑的是源码模板，但构建后可能被Webpack插件（如html-webpack-plugin）注入