Breeze 无障碍审计

要解决的问题

很多团队把无障碍当作上线前的最后一道过场：跑一遍 axe-core 拿到一堆 warning，改了几个 alt 属性就收工。结果键盘用户依然卡在焦点样式被 outline: none 抹掉的组件上，读屏用户听到的是一长串冗余的 aria-label，颜色对比度不足的按钮在强光下直接不可读。

根源在于，手工审计既慢又碎：WCAG 2.2 Level A 与 AA 的成功标准条目不少，不同框架的修复方式又不一样——React 里用原生 <button> 就能白赚键盘支持，Svelte 和 Angular 的处理又各有一套写法。靠人肉对照 spec 查，漏项几乎是必然。

这个技能如何工作

它把审计拆成三个阶段，每个阶段都有明确的输入和输出：

• Scan：遍历源码树，自动识别 React、Next.js、Vue、Angular、Svelte 或纯 HTML，套用对应的规则集，把发现的问题按 Critical / Major / Minor 分级。Critical 是整类用户被挡在门外的问题（如导航完全不可键盘访问），Major 是显著的体验障碍（如对比度不达标），Minor 是需要修但可以先排期的小摩擦。
• Fix：对每一条违规给出框架专属的 before/after 代码对照，而不是泛泛地告诉你「去改样式」。颜色对比度检查会直接算出前景/背景比值，比如白色背景上的 #aaa 只有 2.32:1，远低于 AA 要求的 4.5:1。
• Verify：重新跑一遍扫描，确认原问题已消除且没有引入新的回归。

除了视觉与语义层面，它还覆盖键盘导航审计（焦点管理、tab 顺序）、ARIA 校验（错误、冗余、缺失属性），以及 CI/CD 集成——GitHub Actions、GitLab CI、Azure DevOps 都有对应的流水线配置，可以把无障碍检查卡进合并前的门禁，防止回退。

适用边界与注意点

它解决的是代码层的自动化审计与修复建议，不是全流程合规的终点。以下情况它帮不上忙：

• 纯视觉层的排版问题，比如正文行高、字号层级的视觉舒适性，spec 只规定了最低门槛。
• 需要真人参与的测试：屏幕阅读器的实际朗读节奏、触控设备的手指目标尺寸，仍要靠 testing-checklist.md 里的手工清单补上。
• 自动化永远抓不到上下文语义：一张图片到底该用 alt 还是 aria-labelledby，工具只能给出常见做法，最终判断还是人。

另外，修复建议遵循一条原则：能用原生元素就别堆 ARIA。原生 <button> 自带键盘行为，给它加 role="button" 是典型的冗余。技能提供的修复模式会优先走原生语义，避免「ARIA 万金油」的反模式。