技能使用指南

AccessibilityAuditor（网页无障碍审计专家）Skill 能帮你做什么？

想搞定 WCAG 2.1 AA/AAA 合规却不知从哪下手？网页无障碍审计专家 Skill 提供 POUR 原则解读、8 类高频违规的错误与修复代码对照、ARIA 组件范式、键盘与屏幕阅读器测试清单，以及可访问性声明模板，帮你在编码阶段就改对。立即了解安装与使用方法。

网页无障碍审计专家SkillAccessibilityAuditor
8 个章节 约 16 分钟阅读 AI 智能生成

网页无障碍审计专家：把 WCAG 合规从“玄学”变成可落地的代码清单

  • 它是谁：AccessibilityAuditor（网页无障碍审计专家）是一个专注网页可访问性的 AI 技能，覆盖 WCAG 2.1 AA、AAA 标准、ARIA 实现、键盘导航与屏幕阅读器测试。
  • 它能干什么：把“图片缺 alt”“div 当按钮”“模态框焦点跑飞”这类高频违规，直接翻译成“问题代码 + 修复代码”的对照方案。
  • 它的特别之处：不只讲原则，还给了 POUR 四原则拆解、8 类常见违规修复、ARIA 组件范式、三档测试清单（自动化、手动、屏幕阅读器）和可访问性声明模板。
  • 谁最需要它：前端工程师、UI/UX 设计师、QA 测试、以及要准备 ADA、Section 508 合规审计的团队。
  • 一句话结论：它不替代扫描工具，而是补上“扫出问题之后怎么改、怎么验、怎么证明”的最后一公里。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能基本信息

项目 内容
中文名 网页无障碍审计专家Skill
英文名 AccessibilityAuditor
技能ID 12301
技能定位 网页可访问性专家，专注 WCAG 合规、ARIA 实现与包容性设计

它解决什么问题？

网页无障碍（Accessibility，常简称 a11y）长期是开发流程里最容易被拖到上线前才补的环节。现实痛点很集中：

  • 团队知道要做 WCAG，但不知道具体到某一行 HTML 该怎么改；
  • 扫描工具能报出“对比度不足”“缺少标签”，却不会告诉你怎么写出符合语义的替代方案；
  • 屏幕阅读器测试依赖个人经验，换个人就换一套结论；
  • 面向海外市场或政务、金融、教育类项目时，ADA / Section 508 合规材料没人会写。

这个技能把这些经验固化成一份“可查询、可复用、可交付”的专家知识：你描述页面或贴出代码，它给你违规判断、修复代码、测试步骤。

一键安装的思路与步骤

AI 技能的通用安装逻辑是“在技能入口检索 → 加载 → 在你的 AI 助手里调用”，具体命令与入口请以你所在平台的官方说明为准。通用流程如下：

  1. 确认安装前提：你已有一个支持技能（Skill）机制的 AI 助手或开发环境；账号具备技能安装权限；项目里能正常调用 AI 对话能力。
  2. 打开技能入口：在平台的技能市场 / 技能管理页 / 插件列表中进入检索界面。
  3. 检索技能：用中文名“网页无障碍审计专家”或英文名“AccessibilityAuditor”搜索，也可用技能ID 12301 精确定位。检索不到时，可按官方文档的“导入技能”方式手动添加。
  4. 一键安装并启用：点击安装 / 启用按钮，确认技能已加入当前工作区（部分平台需要为具体项目单独开启）。
  5. 验证是否生效：新建一次对话，输入一句测试提示，例如“这个 <div class="button" onclick="submit()">提交</div> 有什么可访问性问题？”。如果回复能指出“应改用原生 <button>，否则键盘用户无法用 Enter/空格触发”，说明技能已正常加载。

提升开发效率的关键思路：把技能放进“写代码时就调用”的位置，而不是“上线前才想起”。改一个组件时顺手问一句，比上线前集中返工便宜得多。

2. 该技能的主要功能和特点

  • POUR 四原则作为判断框架：可感知、可操作、可理解、健壮。任何一条违规都能归到这四个维度，方便在评审会上讲清楚“为什么这是问题”。
  • 8 类高频违规的“错误代码 → 正确代码”对照：图像替代文本、颜色对比度、非语义 HTML、表单标签、键盘导航、ARIA 地标、模态框/对话框、跳过链接。每一类都给了可直接抄用的代码片段。
  • 量化标准内置：正常文本对比度最低 4.5:1（AA）、增强 7:1（AAA）；大文本（≥18px 或 ≥14px 加粗）最低 3:1、增强 4.5:1；UI 组件与图形最低 3:1。不用每次去翻规范。
  • ARIA 属性速查：状态类（aria-checked、aria-expanded、aria-pressed、aria-selected、aria-disabled、aria-hidden）与属性类（aria-label、aria-labelledby、aria-describedby、aria-live、aria-required、aria-invalid）分类列出，避免“ARIA 乱贴”。
  • 复杂组件范式：手风琴、标签页、模态框都给了完整可用的可访问实现，包括 role="dialog"、aria-modal="true"、焦点陷阱与焦点恢复、Escape 关闭。
  • 实时区域（Live Region）用法：区分 polite（等语音暂停）与 assertive（立即打断），并给出 role="status" 的保存中提示写法。
  • 三档测试清单：自动化（axe DevTools、WAVE、W3C 验证器、对比度检查、标题层级）、手动（纯键盘走查、焦点可见性、表单错误播报、200% 缩放、禁用 JS、Windows 高对比度模式）、屏幕阅读器（VoiceOver、NVDA 的具体快捷键与测试提问）。
  • 可交付物模板：直接提供《可访问性声明》的 Markdown 结构，含合规状态、反馈渠道、已知问题与更新时间。
  • 和普通工具比强在哪：扫描工具负责“发现问题”，这个技能负责“解释问题 + 给出修复 + 设计验证路径 + 输出合规文案”，是工具结论的下游承接者。

3. 如何使用该技能？

第一步：明确你的审计目标

先判断你属于哪一类需求：改一个具体组件、审一个页面、准备一次合规审计、还是给设计稿做包容性评审。目标不同，提问方式差别很大。

第二步：用“代码 + 上下文”的方式提问

裸问“怎么做好无障碍”只会得到泛泛而谈。把真实代码贴进去，效果立刻不同。

示例输入：

<div class="modal">
  <div class="content">
    确认删除？
    <div class="btn" onclick="closeModal()">关闭</div>
  </div>
</div>

第三步：读取输出结构

典型回复会包含四块：违规点是什么（对应哪条 WCAG 原则）、为什么这是问题（对哪类用户造成障碍）、修复后的代码、以及如何验证（用键盘 Tab/Escape 走一遍、用 NVDA 听一遍）。

针对上面的例子，正确方向是：加 role="dialog"、aria-modal="true"、aria-labelledby 指向标题；把 div.btn 换成原生 <button>；实现打开时聚焦第一个可聚焦元素、关闭时把焦点还给触发按钮、Tab 键在弹窗内循环、Escape 可关闭、背景禁止滚动。

第四步：按清单自测

拿到修复代码后，不要直接合并。按技能给出的手动清单过一遍：只用键盘（Tab、Enter、Escape、方向键）能否完成主流程；焦点指示器是否可见；表单错误是否被播报；浏览器缩放到 200% 是否重排正常；禁用 JavaScript 后核心功能是否还在。

第五步：批量复查与沉淀

把同一类问题（比如全站图片 alt 写法）整理成团队规范，写进组件库或 ESLint/代码评审清单，避免同一个坑反复踩。

第六步：输出合规文档

如果项目需要对外声明，直接使用技能提供的可访问性声明模板，填上合规状态、反馈邮箱/电话、已知问题与最后更新日期。

4. 同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
网页无障碍审计专家Skill（AccessibilityAuditor） AI 可访问性专家顾问 POUR 原则解读、8 类违规修复代码、ARIA 组件范式、测试清单、声明模板 需在支持技能机制的 AI 平台安装，具体入口以官方说明为准；无代码基础也能用 边写边改、组件级修复、审计前准备、团队培训 优势：给的是“怎么改 + 怎么验”，能解释原因；不足：不主动爬取线上页面，需你提供代码或描述
axe DevTools 自动化扫描工具 规则引擎扫描、违规列表、部分修复建议 浏览器扩展，装上即用 快速发现批量违规、CI 集成 优势：秒级扫描全页；不足：只能查约三到五成问题，复杂交互、语义合理性仍需人工判断
WAVE 网页可访问性评估工具 页面可视化标注、结构/对比度/标签提示 浏览器扩展或在线页面，门槛低 教学演示、快速视觉排查 优势：标注直观，适合讲解；不足：不产出实现级修复方案
Lighthouse（Chrome DevTools） 综合质量审计 性能、可访问性、SEO 等打分 内置浏览器，零安装 上线前的整体体检、留档对比 优势：一次跑完多维度；不足：无障碍项偏基础，分数高≠真的可用
纯人工屏幕阅读器测试（NVDA/JAWS/VoiceOver） 真实用户体验验证 实际听读体验、交互流程验证 需学习快捷键与听读技巧，人力成本高 关键流程验收、上线前终检 优势：最接近真实用户；不足：慢、依赖经验、难覆盖全站

结论很清晰：扫描工具负责广度，人工测试负责深度，这个技能负责把两者之间的“翻译与落地”补上。三者是配合关系，不是替代关系。

5. 该技能的典型应用场景与实际体验情况

场景一：前端工程师改一个“看起来很正常的按钮”

角色：中级前端，接手了历史项目。痛点：列表里的操作项全是 <div onclick>，鼠标能用，键盘完全点不到。使用方式：把组件代码贴给技能，问“怎么在不改样式的前提下让它键盘可用”。实际体验：回复会明确给出两条路——首选换原生 <button>；如果结构限制必须用 div，则补 role="button"、tabindex="0"，并在 onkeydown 里处理 Enter 与空格。上手难度极低，注意点是别只加 tabindex 忘了按键处理，那样反而制造“能聚焦但按不动”的新坑。

场景二：设计师做表单页的包容性评审

角色：UI/UX 设计师。痛点：设计稿里大量依赖 placeholder 当标签，视觉干净但无障碍不达标。使用方式：描述布局，问“这套表单在屏幕阅读器和自动填充场景下有什么问题”。实际体验：会明确提示“每个字段必须有相关标签、标签应可见、不要依赖占位符，仅在视觉标签不可行时才用 aria-label”，并给出显式标签、隐式标签、视觉隐藏标签（sr-only）三种写法取舍。注意点：视觉隐藏标签要确保 CSS 真的只对屏幕阅读器可见，别写成 display:none。

场景三：QA 准备上线前的无障碍终检

角色：测试工程师。痛点：不知道从哪下手，测了也不知道算不算通过。使用方式：直接让技能输出一份测试清单，照着执行。实际体验：清单分三层很实用——自动化层跑 axe/WAVE、W3C 验证器、对比度检查；手动层做纯键盘走查、焦点可见性、200% 缩放、禁用 JS、Windows 高对比度模式；屏幕阅读器层用 VoiceOver（Cmd+F5 开启，Control+Option+方向键导航）或 NVDA（方向键浏览模式、Tab 焦点模式、NVDA+F7 元素列表）。注意点：清单是框架，具体通过标准要结合项目实际业务流程裁剪。

场景四：面向海外或公共服务项目的合规交付

角色：项目负责人。痛点：客户要求提供 ADA / Section 508 相关说明，团队没人写过可访问性声明。使用方式：让技能给出声明骨架，填入实际反馈渠道与已知问题。实际体验：模板包含合规状态（如“部分符合 WCAG 2.1 Level AA”）、反馈邮箱与电话、已知问题清单、最后更新日期，结构完整可直接改。注意点：合规声明是承诺，写明“部分符合”就要如实列出已知问题，别写成“完全符合”。

整体上手感受：这是一个“越具体越好用”的技能。贴代码、贴结构、说清楚用户场景，回复质量会明显提升；只问一句“怎么做好无障碍”，得到的只能是原则复述。

6. 该技能能为用户带来的价值

  • 把学习成本从“读规范”降到“看对照”：WCAG 2.1 文档体量庞大，多数开发者卡在“知道有标准但不知道怎么落到这一行 HTML”。技能把原则、阈值、代码一次给全，新手第一次改就能改对。
  • 缩短返工链路：无障碍问题越晚发现越贵。在编码阶段就用它做组件级自检，比上线前集中扫一遍再返工，改动量和沟通成本都低一个量级。
  • 让评审有共同语言：用 POUR 四原则和明确的对比度数值（4.5:1、7:1、3:1）沟通，讨论从“我觉得不好用”变成“这条不满足 AA 级对比度”，决策更快。
  • 降低合规门槛：可访问性声明模板 + 测试清单，让没有专职无障碍工程师的团队也能拿出结构完整的合规材料。
  • 扩大产品覆盖面：视障、低视力、色觉障碍、运动障碍用户是真实存在的用户群，键盘可用、屏幕阅读器可读、对比度达标，直接对应可用人群的扩大。
  • 长期价值在于沉淀：把每次修复结论写进组件库和代码评审清单，问题会随项目迭代持续减少，而不是每次重构都重来一遍。

7. 常见问题 FAQ

Q1：这个技能怎么安装？收费吗？

在支持技能机制的 AI 平台中，通过技能市场或技能管理入口检索中文名“网页无障碍审计专家”或英文名“AccessibilityAuditor”，也可以用技能ID 12301 定位，然后一键安装并启用。安装前提、具体入口与是否收费，各平台规则不同，请以官方说明为准。安装后建议先发一句测试提示，确认技能已生效。

Q2：它能自动扫描我的网站吗？

不能。它的定位是“可访问性专家顾问”，产出的是违规判断、修复代码、测试方法与合规文案，本身不做页面爬取。实际审计中通常这样组合：先用 axe DevTools、WAVE、Lighthouse 做自动化扫描找出问题清单，再把具体片段交给这个技能获取修复方案，最后用键盘走查和屏幕阅读器（NVDA/JAWS/VoiceOver）做人工验证。

Q3：适合谁用？不是我这种角色有必要吗？

最直接受益的是前端工程师、UI/UX 设计师和 QA 测试。此外，产品经理在写需求时加一条“表单必须有可见标签”，项目经理在交付前准备可访问性声明，都能直接用上。只要你的产品面向公众用户，无障碍就不是某个岗位的专属议题。

Q4：和 axe、WAVE 这类工具怎么选？

不是二选一。工具强在覆盖面广、速度快、可集成 CI，适合做“发现”；技能强在解释原因、给出可运行代码、设计验证路径，适合做“修复与验收”。只装工具，你会拿到一堆看不懂的违规条目；只用技能，你会漏掉大批可以自动化发现的问题。两者叠加才是完整闭环。

Q5：它支持到什么级别？AA 和 AAA 都能覆盖吗？

技能内容围绕 WCAG 2.1 Level AA 与 AAA 展开，同时覆盖 ARIA 创作实践、语义 HTML、键盘导航与辅助技术兼容性，也涉及 ADA 与 Section 508 的审计准备场景。需要提醒的是，AAA 级要求更严格（例如正常文本对比度需达 7:1），全站达成成本较高，实践中通常对核心内容或关键流程做 AAA 增强，其余以 AA 为基线，具体取舍要结合项目合规要求决定。