无障碍审计

为什么需要结构化的无障碍审计？

很多团队在推进无障碍合规时，会遇到三个典型问题：一是过度依赖自动化工具，axe-core 或 Lighthouse 能发现大量语义问题，但键盘导航顺序、屏幕阅读器实际朗读逻辑这类需要人工判断的场景常被遗漏；二是缺乏统一的评分标准，不同成员对「严重程度」的判断不一致，导致修复优先级混乱；三是输出内容零散，没有可落地的修复方案，最终整改效率低下。无障碍审计不是简单的「过一遍工具」，而是需要覆盖自动检测、手动验证、标准对齐和分级输出的完整流程。

技能如何帮你完成审计？

这个技能围绕「从检测到落地」设计了四层工作流：

• 自动检测层：优先用 axe-core 扫描 DOM 语义结构，或通过 Lighthouse 分析性能与可达性的交叉项，快速定位如「图片缺失 alt 属性」「按钮未绑定键盘事件」这类显性问题。
• 手动检查层：补充工具覆盖不到的场景，包括用键盘 Tab 键验证焦点顺序是否逻辑连贯，通过屏幕阅读器听读确认动态内容（如弹窗）是否被正确朗读，以及用对比度工具检测文本与背景的色值是否符合 AA 级标准（普通文本≥4.5:1）。
• 标准对齐层：严格对照 WCAG 2.1 AA 条款逐项评分，确保每个结论都有明确的标准依据，避免主观判断。
• 输出落地层：将问题分为 Critical（完全阻断操作）、Serious（核心功能不可用）、Moderate（体验受影响但不阻断）三级，并对应输出可复用的修复步骤，例如「为表单标签添加 for 属性」「调整导航栏焦点样式的 outline 属性」。

适用边界与注意点

技能聚焦于Web/App界面的可达性审计，不适用于后端服务性能优化、数据库索引设计等非前端无障碍场景。使用时需注意：自动检测结果需与手动验证结合，不能直接以工具报告作为最终结论；对于定制组件（如企业自研的富文本编辑器），可能需要额外编写 axe-core 规则才能覆盖自定义逻辑。