无障碍可访问性红线是阻止HTML文件进入预发布的硬性拦截条件，须满足可自动检测、触发即阻断、不可人工绕过三特征，并涵盖DOCTYPE缺失、lang属性违规、main标签异常、标签未闭合、charset声明错误五类问题。
什么是无障碍可访问性红线
无障碍可访问性红线不是建议项，是阻止 HTML 文件进入预发布或上线流程的硬性拦截条件。它必须满足三个特征：可自动检测、触发即阻断、不可人工绕过。比如 lang 属性缺失或写成 lang="zh"，CI 流水线里 htmlhint 或 axe-core 一扫就报错，exit code 1，PR 直接被拒绝合并。
哪些问题必须设为红线
以下五类问题一旦出现，应立即终止构建：
-
<!DOCTYPE html>缺失，或使用旧式声明（如<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN">） -
<html>标签无lang属性，或值不符合 BCP 47 规范（如lang="ch"、lang="cn"、lang="zh"） -
<main>出现次数 ≠ 1，或其直接父元素不是<body>（例如嵌套在<div>或<section>内） - 存在未闭合的块级标签（如
<div><p>文本，无对应</p>和</div>），W3C 验证器返回严重语法错误 -
<meta charset>缺失，或写成<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
为什么不能只靠人工评审来守红线
人工评审永远滞后于代码提交。等测试阶段才发现 <main> 嵌套在 <div> 里，修复成本已翻倍；等上线后用户反馈“NVDA 跳不过主内容”，问题早已扩散。真正有效的红线必须：
- 嵌入
pre-commit钩子：本地git commit时就跑axe-core --disable-colors --tags=wcag2a,wcag2aa+ 正则校验lang和DOCTYPE - 在 CI 中设为失败阈值：只要任意一项红线触发，
npm run check:accessibility返回非零退出码 - 关联缺陷系统：每条红线自动创建 Jira issue，类型标记为
accessibility:blocker，归属到提交人
维护手册里怎么写才不被当成摆设
手册里光写“应使用语义化标签”没用。必须明确到可执行动作和验证方式：
立即学习“前端免费学习笔记（深入）”；
- 写明
<nav>的准入条件：仅用于主导航、面包屑、页内锚点列表；文章末尾“相关阅读”链接禁止放入<nav>，否则视为红线违规 - 规定
<h1>到<h6>的层级规则：禁止跳级（如<h2>后直接<h4>），且每个<section>必须以<h2>或更高级别标题开头 - 标注
alt的红线情形：留空属性（alt）、值为alt="image"或alt="图片"，均触发阻断 - 注明工具链命令示例：
npx html-validate --config .htmlvalidate.json src/**/*.html，并附上配置中启用的必选规则名（如require-lang、require-doctype）
红线写得越具体，开发越难“注释掉规则再提交”。真正卡住的不是技术，是模糊地带。
