判断HTML是否达标需以企业级交付底线为准：结构合法、语义清晰、可访问、无硬编码风险；重点检查DOM结构是否通过cheerio解析与axe扫描，而非仅看渲染效果。
怎么判断统一设计系统输出的HTML是否达标
不能只看“能渲染”，得看它是否满足企业级交付底线：结构合法、语义清晰、可访问、无硬编码风险。设计系统（如Ant Design、Element Plus或内部自研）生成的HTML，常因组件抽象过度或模板固化，导致div嵌套过深、缺少alt、lang缺失、aria-属性错位等问题。验收时第一关不是样式，而是DOM结构本身是否经得起cheerio解析和axe扫描。
W3C验证器报错但页面正常？先分清错误类型
W3C validator（https://validator.w3.org/）对设计系统输出件常报两类问题：一类是真实语法错误（如<img>没闭合、<button>里嵌<div>），必须修复；另一类是“警告”（Warning），比如<section>没配<h2>，或role="button"未配合tabindex。这类不阻断渲染，但影响可访问性和SEO权重，需按团队规范决定是否降级处理。特别注意：若使用了设计系统自定义元素（如<my-card>），W3C会直接报“unknown element”，此时应切换为检查其实际渲染后的HTML（即浏览器Elements面板里的结果），而非源模板。
自动化验收时最容易漏掉的三项检查
-
lang属性是否继承正确：设计系统模板常在根<html>写死lang="zh-CN"，但多语言子页可能动态切换，需确认运行时document.documentElement.lang值准确 - 图片
alt是否为空字符串或纯空格：组件库常默认alt=""，但WCAG要求“装饰性图片才可为空”，功能性图标必须有有意义的替代文本 - 表单控件是否都绑定
label：设计系统生成的<input type="checkbox">常遗漏for或aria-labelledby，导致屏幕阅读器无法关联描述
CI流程里怎么集成HTML质量卡点
别只跑一次html-validate就完事。建议在GitLab CI或GitHub Actions中分层拦截：
- 基础层：用
html-validate --config .htmlvalidate.json检查语法+语义规则（禁用inline-style、强制img[alt]） - 可访问层：用
axe-coreCLI扫描关键页面快照，失败阈值设为serious及以上级别问题数 > 0 - 结构层：用
cheerio写轻量脚本校验必需节点是否存在，例如：$$('header nav').length === 1、$$('main').length === 1
真正难的不是工具链，而是把设计系统组件的“预期HTML契约”写进验收规则——比如一个<MyButton>组件，必须产出带role="button"和tabindex="0"的<span>，而不是依赖开发者手动补属性。
立即学习“前端免费学习笔记（深入）”；
