技能使用指南

accessibility（网页可访问性）Skill 是什么？如何下载安装？

网页可访问性Skill（accessibility）覆盖 WCAG 2.1 合规清单、语义 HTML 改造、ARIA 属性、键盘导航与焦点管理、屏幕阅读器测试、颜色对比度计算与 axe、Lighthouse 自动化配置。本文讲清它的功能、安装验证步骤、使用示例、竞品对比与典型场景，帮前端与测试团队快速把无障碍落到代码里，立即了解如何启用。

网页可访问性Skillaccessibility
8 个章节 约 15 分钟阅读 AI 智能生成

网页可访问性Skill：从语义 HTML 到 WCAG 合规，一站补齐无障碍能力

  • 它是什么：一个专注于网页可访问性（a11y）的 AI 技能，覆盖 WCAG 2.1 合规检查、语义 HTML、ARIA 属性、键盘导航、焦点管理、屏幕阅读器测试、颜色对比度与自动化测试。
  • 核心价值：把「翻文档、查规范、凭经验猜」变成「给一段代码或一个场景，直接拿到可落地的改造方案与检查清单」。
  • 典型用法：把组件代码贴给 AI，说明「需要满足 WCAG 2.1 AA」，技能会输出语义结构改造、ARIA 补充、键盘交互与测试建议。
  • 适合谁用：前端工程师、组件库维护者、QA/测试、需要做无障碍合规改造的产品与设计团队。
  • 注意：自动化建议不能完全替代真实屏幕阅读器测试与残障用户测试，二者要配合使用。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

这个技能的中文名是网页可访问性Skill，英文名是 accessibility，技能 ID 为 13528。

它解决的问题非常具体：网页无障碍（a11y）这件事，知识点极度分散——WCAG 2.1 的 A/AA/AAA 三级条款、POUR 四原则、语义 HTML 元素对照、ARIA 角色与状态、键盘交互模式（Tab、方向键、Home/End、Esc）、屏幕阅读器（NVDA、JAWS、VoiceOver、TalkBack、Narrator）的操作差异、颜色对比度算法、以及 axe / Lighthouse / Pa11y 等自动化工具的接入方式。开发者在实际项目里往往「知道要做无障碍，但不知道该做什么、做到什么程度算达标」。这个技能把这些知识整理成可直接调用的工作流：给代码、给场景、给检查清单，输出改造方案。

一键安装的思路与步骤（通用流程，具体入口与命令请以官方说明为准）：

  1. 确认安装前提：你使用的 AI 客户端 / 智能体平台需要支持「AI 技能（Skill）」机制，并已完成账号登录与工作区配置。
  2. 找到技能：在平台的技能市场或技能库中，用关键词「accessibility」「网页可访问性」「a11y」搜索，或直接通过技能 ID 13528 定位该技能页面。
  3. 启用技能：按平台提供的安装/启用入口完成添加（部分平台支持一键添加或通过命令行工具安装，具体命令以官方说明为准），并在当前会话或项目中勾选启用该技能。
  4. 验证是否生效：新建一次对话，输入诸如「帮我把这段用 div 写的导航改成语义 HTML，并满足 WCAG 2.1 AA」，或直接说出触发词「可访问性」「WCAG」「aria-live」。若返回的是结构化的语义改造方案、ARIA 建议与检查清单，说明技能已正常加载。
  5. 团队落地：把常用触发语句沉淀成团队模板（例如「可访问性审计」「模态框焦点陷阱」「对比度检查」三类固定提问），让不同成员得到稳定一致的回答。

该技能的主要功能和特点

  • WCAG 2.1 合规检查清单：按 POUR 四原则（可感知、可操作、可理解、健壮）组织，区分 A / AA / AAA 一致性级别，逐条给出条款编号、要求与「howToTest」验证方法，例如 1.1.1 替代文本、1.4.3 对比度 4.5:1、2.1.1 键盘可访问等。
  • 语义 HTML 改造：提供 header / nav / main / article / section / aside / footer、h1–h6、figure / figcaption、button / a、fieldset / legend 等元素的用途对照，能对比「坏结构 vs 好结构」，直接产出改写结果。
  • ARIA 模式库：覆盖地标角色（banner、navigation、main、contentinfo、search）、小部件角色（dialog、tab、tablist、menuitem、slider 等）以及 aria-label、aria-labelledby、aria-describedby、aria-expanded、aria-selected、aria-live、aria-hidden 等常用属性，并给出模态对话框、标签页、实时通知等可运行示例。
  • 键盘导航与焦点管理：提供标准键盘模式表（Tab 导航、方向键、Enter/Space、Esc、Home/End、类型前导），以及焦点陷阱、轮转 tabindex（roving tabindex）、跳过链接等实用实现。
  • 屏幕阅读器测试支持：整理 NVDA、JAWS、VoiceOver、TalkBack、Narrator 的平台、成本与快捷键差异，并给出导航、内容、表单、交互四类测试检查项。
  • 颜色对比度与视觉可访问性：内置亮度与对比度计算逻辑、AA/AAA 判定函数、可访问调色板生成思路，以及 :focus-visible 可见焦点、高对比度模式、减少动效（prefers-reduced-motion）的样式方案。
  • 自动化测试集成：给出 jest-axe、@axe-core/playwright、Lighthouse CI、Pa11y 的配置范式，并区分「每次提交都跑的自动化检查」与「发布前必须人工做的检查」。

和普通工具比强在哪：axe、Lighthouse 这类工具擅长「发现问题」，但不会告诉你「这段业务代码应该怎么改」；而这个技能是「解释 + 改造 + 验证」一体化，且同时兼顾工程实现与设计包容性，不是单纯的规则罗列。

如何使用该技能？

  1. 明确任务类型：先判断你处于哪一类任务——① 新建可访问 UI（从零写组件）；② 存量页面审计（找出不合规项）；③ 定向修复（已知某个交互有问题）。不同任务对应不同提问方式。
  2. 用触发词唤起技能：自然语言里带上「可访问性」「a11y」「WCAG」「ARIA」「屏幕阅读器」「键盘导航」「焦点」「对比度」「语义 HTML」等触发词，技能会进入对应的知识域。
  3. 提供足够的输入：贴代码片段（组件源码或 HTML 结构）、说明目标合规级别（A / AA / AAA）、说明使用的框架（React、Vue 等）、说明目标用户（是否有屏幕阅读器用户）。
  4. 按输出逐项落地：技能通常返回三部分——问题清单（哪条 WCAG 条款不满足）、改造后代码、验证方法。按顺序改，先改语义结构，再补 ARIA，最后处理焦点与键盘。
  5. 双轨验证：先用自动化手段（axe-core、Lighthouse、eslint-plugin-jsx-a11y）跑一遍回归，再做人工验证（拔掉鼠标只用键盘走一遍、开 VoiceOver/NVDA 听一遍、缩放 200% 看布局是否崩）。

输入示例一（语义化改造）：

「下面这段用 div 写的页头和导航，帮我改成语义 HTML，并补上必要的 ARIA，满足 WCAG 2.1 AA：<div class="header"><div class="nav"><div class="nav-item">主页</div>...</div></div>」

输出说明：技能会给出改用 <header> + <nav aria-label="主导航"> + <ul><li><a> 的结构，并指出「可点击的 div 不是链接，键盘无法聚焦、屏幕阅读器不会朗读其角色」，同时给出 2.4.4 链接目的清晰、4.1.2 名称角色值可用等对应条款。

输入示例二（模态框交互）：

「用 React 写一个可访问的模态对话框，要求焦点被限制在对话框内、Esc 可关闭、关闭后焦点回到触发按钮、屏幕阅读器能读出标题。」

输出说明：会返回 role="dialog"、aria-modal="true"、aria-labelledby 指向标题 ID 的实现，配合 Tab/Shift+Tab 首尾循环的焦点陷阱逻辑与卸载时的焦点恢复，并提示补充「关闭对话框」的 aria-label。

输入示例三（合规自查）：

「我这个注册表单要达到 WCAG 2.1 AA，请按检查清单逐条告诉我还缺什么。」

输出说明：返回针对表单的条款清单，如 1.4.3 对比度、3.3.2 标签或说明、3.3.3 输入错误建议、4.1.2 组件名称角色值，并说明错误提示要用 aria-describedby 关联、错误摘要需要可聚焦并主动播报。

同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
网页可访问性Skill（accessibility，技能 ID 13528） AI 驱动的可访问性知识与改造助手 WCAG 2.1 清单、语义 HTML 改造、ARIA 模式、键盘与焦点方案、屏幕阅读器测试指引、对比度计算、自动化测试配置 需在支持 Skill 的 AI 平台安装启用，零代码基础即可提问 边写边改、存量代码审计、团队知识对齐 优势：直接产出可运行代码与改造路径，解释「为什么」；不足：结论仍需人工验证，不能替代真实设备测试
axe DevTools / axe-core 自动化规则引擎与浏览器插件 按 WCAG 规则扫描页面并标注违规节点 浏览器插件或 npm 引入，开发者友好 CI 回归、快速定位违规元素 优势：规则覆盖广、误报相对可控；不足：只报问题不给业务级改造方案
Lighthouse（可访问性审计） 综合性能与质量审计工具 输出可访问性分数与关键项断言 浏览器内置或 CI 集成，几乎零门槛 上线前体检、指标看板 优势：上手极快、适合作为门槛卡点；不足：覆盖面有限，分数高不等于真的可用
eslint-plugin-jsx-a11y + 人工屏幕阅读器测试 静态检查 + 人工验证组合 编码期拦截常见错误 + 真实辅助技术体验 需配置工程链路，人工测试需要学习成本 组件库开发、发布前验收 优势：最贴近真实用户体验；不足：依赖测试者熟练度，难以规模化

结论：自动化工具解决「查得出」，本技能解决「改得对」，人工测试解决「用得顺」，三者是互补而非替代关系。

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

场景一：前端工程师重构遗留页面

角色是业务线前端，接手一个用大量 div + onclick 写成的后台管理页。痛点是「键盘完全走不通，屏幕阅读器读不出导航层级」。使用方式是贴出页面骨架代码，要求按 WCAG 2.1 AA 输出语义化改造方案。实际体验：上手几乎零门槛，输出会明确指出「可点击 div 缺少角色与键盘可达性」这类根因，并按 header/nav/main/footer 给出替换结构；注意事项是改造范围要分批推进，一次性重写容易引入回归。

场景二：企业产品的无障碍合规改造

角色是产品经理或技术负责人，所在行业存在无障碍合规要求，需要判断「我们离 AA 还差多远」。使用方式是把现有页面清单和交互类型交给技能，按 A/AA 检查清单逐条比对，形成差距表。实际体验：清单式的输出非常适合直接转成任务看板，条款编号让沟通成本大幅下降；注意事项是 AAA 属于增强项，不必作为第一阶段的硬指标。

场景三：组件库维护者打磨交互组件

角色是设计系统维护者，需要让 Tabs、Menu、Dialog、Combobox 同时满足键盘操作与屏幕阅读器播报。使用方式是逐个组件提问，要求给出键盘交互约定（哪些键做什么）与 ARIA 状态同步方案。实际体验：轮转 tabindex、焦点陷阱、aria-expanded / aria-selected 同步这些细节被明确写出，减少「凭印象实现」的偏差；注意事项是一定要在真实 NVDA 或 VoiceOver 中复听一遍，不同阅读器的播报细节存在差异。

场景四：QA 建立无障碍回归用例

角色是测试工程师，需要把无障碍检查固化进发布流程。使用方式是让技能输出「每次提交必跑」的自动化项与「发布前必做」的人工项，并给出 axe、Lighthouse、Pa11y 的断言配置思路。实际体验：把自动化与人工分开列这一点很实用，避免了「跑完扫描就认为达标」的常见误区；注意事项是颜色对比度、动态内容播报这类问题很难被自动扫描全量覆盖。

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

  • 效率提升：把「查规范 + 试错 + 改代码」的循环压缩成一次对话，原本需要翻阅多份文档、多次调试才能解决的语义与 ARIA 问题，可以在同一轮输出中被定位并给出实现，显著缩短单个组件的无障碍改造时间。
  • 门槛降低：无障碍知识对多数前端属于「知道重要但不熟」的领域。技能把 WCAG 条款、ARIA 规则、键盘模式整理成可查询、可复用的回答，让没有无障碍经验的同学也能做出符合规范的实现。
  • 质量与风险收益：AA 级在许多司法管辖区是法定要求，提前把可访问性内建到开发流程，比上线后返工成本低得多；同时语义化与键盘支持也会顺带改善 SEO 与整体可用性。
  • 长期价值：团队在使用过程中会沉淀出自己的无障碍规范模板与检查清单，形成可持续复用的工程资产，而不是每次都从零讨论「要不要做无障碍」。

常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认能用？

在支持 AI 技能的平台里搜索「accessibility」或「网页可访问性」，也可通过技能 ID 13528 定位后按平台入口启用；具体命令、入口位置与权限要求请以官方说明为准。验证方式是发一句带触发词的话（如「帮我做 WCAG 2.1 AA 可访问性检查」），能返回结构化的条款清单与改造建议即为生效。

Q2：这个技能收费吗？

技能本身的功能说明中未包含价格信息，是否收费取决于你所在 AI 平台对该技能的计费策略，请以官方说明为准。建议先在小范围项目中试用，评估产出质量后再决定是否纳入团队流程。

Q3：它适合谁用？后端或设计同学用得上吗？

前端工程师、组件库维护者、QA 是核心用户；设计与产品同学也适合用它来对齐「什么算可访问」，比如焦点可见、对比度阈值、错误提示的播报方式这类跨职能话题，能显著减少沟通歧义。后端同学可以用它来理解前端提出的无障碍改造需求的必要性。

Q4：装了 axe 或 Lighthouse，还需要这个技能吗？

需要，两者解决的是不同环节。axe、Lighthouse 负责「扫描出违规节点」，但不会告诉你「这段业务代码应该改成什么样」；本技能负责把违规项映射到具体条款，并给出语义改造、ARIA 补充与键盘交互的实现方案。推荐组合是：编码期用静态检查与技能辅助，提测后跑自动化扫描，发布前做人工键盘与屏幕阅读器验证。

Q5：用了它是不是就等于「无障碍达标」了？

不等于。技能输出的是基于 WCAG 2.1 的方案与清单，属于「正确做法的指引」；真实达标还需要三类验证：仅用键盘完成全部核心流程、用 NVDA 或 VoiceOver 实际听读页面、以及在条件允许时邀请残障用户参与测试。技能能显著提高你做对的概率，但最终判断仍要靠真实环境验证。