accessibility-audit

无障碍审计技能

此技能依据 WCAG 2.2 指南生成结构化的无障碍审计报告。审计涵盖视觉、动作、认知和屏幕阅读器无障碍，并为发现的每项问题提供优先级明确的修复建议。

所需输入

基于已提供的信息开展审计。如果缺少以下任何信息，仍需生成完整输出：对每处缺失信息作出合理假设，并标注 (假设，需确认)，然后在末尾列出这些假设。只有在缺少核心主题本身（无内容可写）时，才先提问。

• 审计对象（屏幕、组件、完整产品、设计规范）
• UI 描述或图片
• 目标 WCAG 等级（A / AA / AAA——默认为 AA，这是大多数司法管辖区的法律标准）
• 是否有已知的辅助技术用户？（是/否——如果是，请说明使用哪种技术：屏幕阅读器 / 开关控制 / 语音控制 / 放大）
• 平台（Web / iOS / Android / 桌面应用）

编程辅助工具

无法凭目测判断对比度。AA 标准线为 4.5:1，白色背景上的 #777777 对比度为 4.478（不通过），而 #767676 为 4.54（通过）——光看 截图无法区分两者。请计算：

npx --yes notugly fix "#8ab4f8" "#ffffff"     # ratio, APCA, and the nearest passing colour
npx --yes notugly onepager <url> --out review.html   # every pairing, printable
npx --yes notugly vision                      # which colours merge for colour-blind viewers

notugly fix 会返回对比度、APCA 明度对比度，以及与已选颜色最接近且能通过标准的颜色——色相和色度相同。将这些数值填入下方表格，而不要估算。

结果确定、零依赖，且不会调用模型——因此运行成本为零，每次运行结果都相同。

对于 1.4.3 对比度（最低）和 1.4.11 非文本对比度，修复表中的每一行都应填写实测对比度，而非评估结果。如果用户提供的是截图而非十六进制颜色值，请在审计中明确说明这一点——推测出的对比度不属于审计发现。

输出结构

---

无障碍审计：[组件或屏幕名称]

目标标准： WCAG 2.2 Level [AA] 平台： [平台] 日期： [日期]

---

审计摘要

类别	发现的问题数	严重	中等	轻微
可感知性
可操作性
可理解性
稳健性
总计

总体合规状态： ✅ 符合 / 🟡 存在轻微问题 / 🔴 未达到 AA 标准

---

可感知性

1.1 文本替代

• 所有图片都有描述性替代文本（不是文件名或“图片”）
• 装饰性图片使用 alt=""，以便屏幕阅读器跳过
• 没有可见标签的图标都有无障碍名称
• 复杂图片（图表、示意图）有详细描述

发现的问题：[列出具体问题，或填写“无”]

1.3 适应性

• 内容结构使用语义化 HTML（标题、列表、地标），而非仅使用视觉格式
• DOM 中的阅读顺序与视觉顺序一致
• 表单输入框有关联标签（而非将占位文本用作标签）
• 数据表格有合适的表头和作用范围

发现的问题：

1.4 可辨识性

• 文本对比度 ≥ 4.5:1（普通文本）或 ≥ 3:1（大号文本，18px+）
• UI 组件与背景的对比度 ≥ 3:1
• 不会仅通过颜色传达信息
• 文本放大至 200% 后，内容不会丢失
• 没有自动播放音频的内容

发现的问题：

---

可操作性

2.1 键盘可访问性

• 所有交互元素都可通过键盘（Tab 键）访问
• 不存在键盘陷阱
• 自定义组件支持键盘交互（菜单可用方向键操作，模态框可用 Escape 关闭）
• 对于包含重复导航的页面，提供跳过导航链接

发现的问题：

2.4 可导航性

• 始终可见焦点（不会在移除 outline: none 后不提供替代样式）
• 焦点顺序符合逻辑且可预测
• 页面/屏幕有描述性标题
• 链接文本具有描述性（不是“点击此处”或“阅读更多”）
• 标题层级正确（H1 → H2 → H3，不跳级）

发现的问题：

2.5 输入模态

• 触控目标至少为 44x44px
• 不存在必须通过复杂手势（捏合、多点触控）才能使用的功能，或提供了简单的替代方式
• 动作或拖动交互提供了按钮替代方式

发现的问题：

---

易于理解

3.1 可读性

• 页面已设置语言（lang 属性）
• 不常见的词语、缩写或术语均有说明

3.2 可预测性

• 各屏幕间的导航保持一致
• 组件的行为保持一致（同一按钮执行相同操作）
• 聚焦或输入时不会意外改变上下文

3.3 输入辅助

• 错误消息会指出对应字段，并以通俗语言描述错误（而不只是“输入无效”）
• 必填字段已标明（不只是用颜色或单独的星号标示）
• 表单会在可能的情况下提供纠错建议

发现的问题：

---

稳健性

4.1 兼容性

• HTML 有效且结构良好
• ARIA 角色和属性使用正确（不用于修复错误的语义）
• 状态消息（成功、错误、加载中）会告知屏幕阅读器，且不会改变焦点

发现的问题：

---

优先级排序的修复清单

优先级	问题	WCAG 标准	修复方法	工作量
🔴 严重	[Issue]	[例如 1.4.3 对比度]	[具体修复方法]	[低/中/高]
🟡 中等	[Issue]
🟢 轻微	[Issue]

优先级定义：

• 🔴 严重：阻碍残障用户访问，存在法律风险。上线前修复。
• 🟡 中等：造成明显不便。在下一个迭代中修复。
• 🟢 轻微：最佳实践。列入路线图并处理。

---

快速修复项（1 小时内可完成）

[列出可轻松修复的问题——例如添加替代文本、通过更换颜色改善对比度、添加 lang 属性。这些修复可以立即发布。]

---

测试建议

• 手动键盘测试： 使用 Tab 键遍历整个流程。能否不使用鼠标完成每项任务？
• 屏幕阅读器测试： VoiceOver（Mac/iOS）、NVDA 或 JAWS（Windows）。每项内容和操作是否都可访问？
• 颜色对比度检查： 使用 Stark（Figma 插件）或 WebAIM 对比度检查器
• 自动扫描： 使用 Axe DevTools 或 Lighthouse 无障碍审查（可自动发现约 30% 的问题）

---

质量检查

• 问题已对应到具体的 WCAG 标准
• 每个严重问题都有具体的修复建议
• 快速修复项与较大规模的修复已分开列出
• 已包含用于排定优先级的工作量估算
• 已包含测试建议

反模式

• 不要只依赖自动扫描工具——自动检查只能发现约 30% 的问题；必须进行手动键盘和屏幕阅读器测试
• 不要仅仅因为问题只影响少数用户，就将其标记为“轻微”——对这些用户而言，它可能会完全阻碍访问
• 不要通过添加 ARIA 角色来修复错误的语义——应优先使用正确的语义化 HTML；ARIA 是最后的选择
• 不要混淆文本颜色对比度和 UI 组件颜色对比度——它们的最低比例不同（4.5:1 与 3:1）
• 不要只审查顺利流程——错误状态、空状态和加载状态也必须满足无障碍要求

示例触发语句

• “审查此设计的无障碍性”
• “检查 [screen/component] 是否符合 WCAG”
• “为 [UI description] 提供无障碍审查”
• “此设计有哪些无障碍问题？”