可访问性评审必须嵌入pr流程并自动化执行。通过ci集成axe-core扫描，强制校验label关联、alt属性、aria同步等核心规则，输出html报告；设计需标注键盘路径与对比度，文档页须支持键盘操作且语义正确。
评审必须嵌入PR流程，不能靠人工抽查
可访问性问题一旦合并进主干，修复成本会指数级上升。把检查点硬编码进CI流程，比依赖开发者自觉靠谱得多。GitHub Actions 或 GitLab CI 中加一道 axe-core 扫描，不是可选项——是准入门槛。
- 每次 PR 提交后自动运行
axe.run()，对组件 demo 页面做全量扫描，失败则阻断合并 - 配置
rules白名单：强制校验label关联、alt属性、aria-*同步、焦点顺序、对比度（至少 4.5:1） - 禁止用
axe.configure({ rules: [] })关闭核心规则；若某条规则确需豁免，必须在 PR 描述中写明 WCAG 条款编号和替代方案 - 扫描结果需输出 HTML 报告并存档，链接附在 PR 评论里，方便复核
评审清单要具体到 DOM 节点行为，而非泛泛而谈“符合 ARIA”
“已加 aria-label”这种描述毫无意义。评审必须能定位到真实 DOM 并验证状态是否同步。比如一个开关组件，不能只看有没有 role="switch"，而要看它是否同时满足：
-
input[type="checkbox"]是否隐藏但保留语义（display: none不行，得用clip-path或position: absolute隐藏） -
aria-checked值是否随 JS 状态实时更新（不是初始值写死） - 键盘操作（Space）是否触发真实
click事件，而非仅视觉切换 - 焦点进入时，是否通过
tabindex="0"可聚焦，且focus-visible样式可见
设计师交付物必须包含可访问性标注，否则开发拒收
设计稿不是审美终点，而是可访问性起点。Figma 或 Sketch 文件里没标出键盘焦点路径、屏幕阅读器播报顺序、高对比模式适配方案，就等于没交付完整需求。
- 每个交互组件旁需注明：预期的
role、必填aria-属性、label文本来源（图标旁文字？tooltip？隐含上下文？） - 动效需标注是否禁用（
@media (prefers-reduced-motion)下是否降级） - 色值必须附带对比度检测结果（如
#333 on #fff → 12.3:1），低于 4.5:1 的组合直接标红并拒绝 - 评审时开发只需对照标注检查实现，不接受“按设计稿还原”这类模糊表述
组件文档页本身必须是可访问性测试入口
文档页不是装饰品，它是第一个被用户（包括辅助技术用户）访问的页面。如果文档页都过不了 Lighthouse 的 Accessibility 审计，那组件库的可信度就崩了。
- 每个组件 demo 区域必须包裹在
<section></section>内，且有层级正确的<h3></h3>标题，不可用<div class="demo"> <li>所有交互 demo 必须支持纯键盘操作：Tab 进入、Enter 触发、Escape 退出（如模态框）、方向键切换（如标签页）</li> <li>文档中代码块要用 <code><pre class="brush:php;toolbar:false;"><code></code> 包裹，且 <code>aria-label</code> 注明语言类型（如 <code>aria-label="HTML 示例代码"</code>）</pre> - 禁止在文档页使用
outline: none；焦点样式必须显式定义，且在高对比模式下仍可见
真正难的不是写几行
aria- 属性，而是让每个角色——设计师、前端、QA——在各自环节都清楚自己那一手必须交出什么，而不是指望下游补漏。
