web-accessibility（网络可访问性）Skill 是什么？如何下载安装使用？

网络可访问性：让每一次提交的前端代码都经得起 WCAG 2.1 检验

核心结论速览

网络可访问性（web-accessibility） 是一个面向前端开发的 AI 技能，专攻 WCAG 2.1 合规：ARIA 模式、键盘导航、屏幕阅读器支持、颜色对比度、可访问表单与自动化测试。
它不是泛泛的“无障碍清单”，而是直接给出可复制的 React/TSX 代码片段（按钮、模态对话框、导航菜单、焦点管理、表单校验、sr-only 样式），拿来即用。
通过触发词「可访问性、a11y、WCAG、ARIA、屏幕阅读器、键盘导航」即可在对话中唤起，无需记忆 API 细节。
内置最小对比度标准（正常文本 4.5:1、大文本 3:1、UI 组件 3:1）与对比度计算函数，把“凭感觉配色”变成“按数值验收”。
附带 axe-core / @axe-core/react / jest-axe 的测试接入方式，让可访问性从“上线后补救”前移到“提交前拦截”。

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

基本信息

项目	内容
技能中文名	网络可访问性
技能英文名	web-accessibility
技能 ID	13136
技术基准	WCAG 2.1（含 AA 级对比度要求）
触发词	可访问性、a11y、WCAG、ARIA、屏幕阅读器、键盘导航

它解决什么问题？

前端团队在做无障碍改造时，几乎都会遇到同一类困扰：

ARIA 属性记不全，aria-modal、aria-labelledby、aria-describedby、aria-expanded 到底该加在哪一层，全靠翻文档；
模态框打开后焦点没有进入弹窗，关闭后焦点“飞”回页面顶部，键盘用户直接迷失；
Tab 键能在弹窗背后继续切换，用户被“困”在看不见的元素里；
设计稿里的灰色文字配浅色背景，肉眼勉强能看，一测对比度只有 3.2:1，达不到 AA 标准；
表单报错只显示红色边框，屏幕阅读器用户完全听不到错误提示；
客户或合规审计要求提交可访问性声明，团队却没有系统性的落地规范。

网络可访问性技能的价值，就是把这些“零散的知识点”变成“结构化的代码方案”，让 AI 助手在你写代码的那一刻就给出符合 WCAG 2.1 的实现。

一键安装的思路与步骤

AI 技能的安装逻辑普遍是“在技能市场/技能中心检索 → 安装 → 在对话中自动生效”，具体命令与入口请以你所使用平台的官方说明为准。通用流程如下：

确认前提：你的 AI 编程助手或客户端已支持 Skill（技能）扩展机制；本地存在一个正在开发的前端项目（React/TSX 场景体验最佳）；如涉及自动化测试，需要项目已具备 Jest 或同类测试环境。
检索技能：在技能市场/技能中心的搜索框中输入「网络可访问性」「web-accessibility」或技能 ID「13136」，找到对应条目。
一键安装并启用：点击安装/添加，按平台提示确认授权与启用状态（是否需要重启客户端，以官方说明为准）。
验证是否生效：新建一个对话，输入一句带触发词的请求，例如“帮我检查这个模态框的可访问性，补齐 ARIA 属性”，若返回内容中出现 role="dialog"、aria-modal="true"、aria-labelledby 等具体属性与代码，即说明技能已被正确唤起。
纳入团队规范：把技能输出的代码片段沉淀为项目内的基础组件（如 <Modal>、<NavMenu>、<AccessibleForm>），后续复用即可，不必每次重新生成。

提示：若检索不到该技能，或安装后无响应，请优先核对平台版本与技能上架状态，以官方说明为准。

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

① 内置 ARIA 模式库，直接产出可复制代码

技能预置了三类高频组件的标准写法：

按钮：使用原生 <button type="button">，配合 aria-pressed 表达开关状态、aria-disabled 表达禁用状态，避免用 <div> 假装按钮。
模态对话框：role="dialog" + aria-modal="true" + aria-labelledby（指向标题）+ aria-describedby（指向描述），让屏幕阅读器在弹窗打开时先朗读标题与说明。
导航菜单：<nav aria-label="主导航"> 配合 role="menubar" / role="menuitem"，子菜单用 aria-haspopup="true" 与 aria-expanded 表达展开状态。

② 键盘导航与焦点管理成体系

技能给出的 Modal 示例完整覆盖了无障碍弹窗的四个关键动作：

打开时记录 document.activeElement 作为 previousFocus，并把焦点移入弹窗；
关闭时把焦点还给触发元素，而不是丢回页面顶部；
监听 Escape 键关闭弹窗；
拦截 Tab / Shift + Tab，在弹窗内部的首尾可聚焦元素之间循环，防止焦点逃逸到背景内容。

③ 颜色对比度从“凭感觉”变“算数值”

技能明确列出 WCAG AA 的最小对比度：正常文本 4.5:1、大文本（18 点以上）3:1、UI 组件 3:1；并给出 getContrastRatio() 与 getLuminance() 的实现，包含 sRGB 相对亮度换算公式，可直接用于设计令牌校验或 CI 检查。

④ 可访问表单的完整范式

<label htmlFor> 正确关联输入框、必填项用 aria-required="true"、错误状态用 aria-invalid 标记、错误文案通过 aria-describedby 绑定、错误容器使用 role="alert" 触发即时播报；装饰性星号用 aria-hidden="true" 屏蔽，必填语义用 .sr-only 文本补充。

⑤ 屏幕阅读器专用内容的标准写法

提供业界通用的 .sr-only 样式（position: absolute + 1px 尺寸 + clip + overflow: hidden），保证视觉上不可见但可被读屏软件读取。

⑥ 测试环节可落地

技能给出 axe-core、@axe-core/react、jest-axe 的安装与断言写法（toHaveNoViolations()），把可访问性检查嵌入单元测试，形成回归防线。

⑦ 权威资源直达

内置 WCAG 2.1 快速参考与 WAI-ARIA 编写实践（APG）两个 W3C 官方链接，方便进一步溯源。

和普通工具比强在哪？ 普通检查工具（如浏览器审计面板）只告诉你“哪里错了”，而这个技能直接回答“这里该怎么写”——从问题诊断跨到代码实现，这是它最核心的差异化。

3. 如何使用该技能？

不需要特别的学习成本，关键在于“用触发词把意图说清楚”。推荐按以下步骤使用：

第 1 步：唤起技能

在对话中带上触发词（可访问性 / a11y / WCAG / ARIA / 屏幕阅读器 / 键盘导航），并附上你的代码或需求描述。

第 2 步：按场景提出具体请求

下面给出四个可直接参考的输入示例与预期输出：

示例一（组件改造） 输入：“这是我的 React 弹窗组件，帮我做可访问性改造，要支持键盘操作和屏幕阅读器。” 输出：带 role="dialog"、aria-modal、aria-labelledby、aria-describedby 的完整组件，外加 useEffect 焦点管理逻辑与 Tab 键循环处理，并提醒“关闭时把焦点还给触发按钮”。
示例二（导航菜单） 输入：“给这个多级导航加 ARIA，确保读屏能听出层级和展开状态。” 输出：<nav aria-label="主导航"> + role="menubar" 结构，父级菜单按钮带 aria-haspopup="true" 与 aria-expanded={isOpen}，子菜单 <ul role="menu" aria-label="产品子菜单">。
示例三（配色校验） 输入：“#8A8A8A 的文字放在 #F5F5F5 背景上，符合 WCAG AA 吗？” 输出：按 getContrastRatio() 逻辑计算相对亮度并给出比值，对照 4.5:1 标准判断是否达标，并给出加深文字或加深背景的调整方向。
示例四（表单报错） 输入：“表单校验失败时只变红框，读屏用户听不到，怎么改？” 输出：aria-invalid、aria-describedby 指向错误段落、role="alert" 即时播报，以及 .sr-only 补充“(必填)”文本的写法。

第 3 步：落地到项目

把输出代码粘贴进组件文件，重点核对三件事：可聚焦元素是否都是原生可聚焦标签（button、a[href]、input 等）、ARIA 属性是否指向真实存在的 ID、Escape 与 Tab 行为是否与产品交互一致。

第 4 步：接入自动化测试

按技能给出的方式安装 axe-core（或 @axe-core/react）与 jest-axe，在测试文件中 expect.extend(toHaveNoViolations)，用 render() 渲染组件后对 container 跑 axe() 断言，让每次 npm test 都顺带守一遍可访问性基线。

第 5 步：人工复核

使用键盘（只用 Tab / Shift+Tab / Enter / Space / Escape）完整走一遍流程，并开启系统读屏软件确认播报顺序，这是自动化工具无法完全替代的一步。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
网络可访问性（web-accessibility）技能	AI 对话式可访问性编码助手	ARIA 模式库、焦点管理、对比度计算、可访问表单、sr-only、axe 测试接入	需支持 Skill 的平台，检索安装即可；无额外后端依赖	边写边改、组件级无障碍实现、团队规范沉淀	优势：直接给可运行代码，从“查错”到“改对”一步到位；不足：仍需开发者自行验证交互细节，不替代人工测试
axe DevTools 浏览器扩展	运行时页面审计工具	扫描 DOM，输出违规项、严重等级与修复建议	浏览器安装扩展，零配置	页面级批量体检、上线前抽查	优势：开箱即用、覆盖规则多；不足：只报问题不给完整业务代码，动态交互态（如弹窗打开时）覆盖有限
eslint-plugin-jsx-a11y	静态代码规范检查	在编码阶段拦截无 `alt`、无 `label`、错误 `role` 等问题	需接入 ESLint 配置，有一定学习成本	CI 卡点、团队统一规范	优势：左移到编辑器、成本极低；不足：只覆盖静态语法层面，无法判断焦点流转与对比度数值
Lighthouse / 内置审计面板	综合性能与可访问性评分	给出可访问性分数与优化清单	浏览器内置，零门槛	快速摸底、对外汇报	优势：分数直观、便于沟通；不足：颗粒度粗，规则命中依赖页面状态，缺少针对性代码方案

选型建议：把网页可访问性技能当作“写代码时的副驾驶”，把 eslint-plugin-jsx-a11y 当作“提交前的门禁”，把 axe DevTools 与 Lighthouse 当作“上线前的体检”，三者组合而非互相替代。

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

场景一：组件库/设计系统开发者 角色：负责公司内部 React 组件库的前端工程师。痛点是每个业务团队都在自己写弹窗，aria-* 属性五花八门，焦点行为各不相同。使用方式是把技能生成的 Modal、NavMenu 作为组件库的标准实现，把 .sr-only、错误提示段落做成通用样式与子组件。实际体验：上手几乎无门槛，复制代码后按业务替换 onConfirm/onClose 即可；效果立竿见影，键盘用户第一次能顺畅关闭弹窗。注意：技能示例中的 querySelectorAll 选择器需按项目实际可聚焦元素调整（如增加 [contenteditable]）。

场景二：企业后台表单密集型产品 角色：B 端产品的开发者。痛点是表单几十个字段，校验失败只有红框和一行小字，客服频繁收到“看不到错误”的反馈。使用方式是对照技能给出的可访问表单范式，统一为每个字段补 label htmlFor、aria-required、aria-invalid、aria-describedby 与 role="alert"。实际体验：改造是机械但高价值的重复劳动，AI 生成速度快，一次沟通能覆盖整段表单。注意：id 必须与 htmlFor、aria-describedby 严格对应，否则读屏关联会失效，这是最容易出错的地方。

场景三：面向海外客户或合规审查的 SaaS 团队 角色：需要提交可访问性说明、应对采购问卷的团队。痛点是设计稿配色与既有组件缺乏可量化依据，说不清“我们到底达不达标”。使用方式是用技能提供的对比度计算逻辑批量校验设计令牌，并把 jest-axe 接入测试流水线，形成可持续的证据链。实际体验：把“我觉得还行”变成了“正常文本 4.5:1、UI 组件 3:1 的具体比值”，沟通成本大幅下降。注意：自动化测试通过不等于完全合规，仍需保留人工键盘走查记录。

场景四：接手历史项目的外包/驻场团队 角色：临时接手老后台的开发者。痛点是代码里 <div onClick> 遍地，无障碍问题堆积如山，不知从何处下手。使用方式是让技能先输出一份“从高频组件开始”的改造建议，逐个替换为导向性明确的实现。实际体验：改造节奏可控，适合小步迭代而非一次性重构。注意：不要给所有元素盲目加 role，“滥用 ARIA”比“没有 ARIA”问题更隐蔽，优先使用原生语义标签。

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

效率提升：把“查文档—试错—返工”压缩成一次对话 过去实现一个合规弹窗，需要翻 ARIA 规范、找焦点管理范例、调试 Tab 循环，往往耗费半天；现在通过触发词一次请求即可拿到结构完整、属性齐备的代码骨架，剩余工作集中在业务逻辑对接上。

门槛降低：让不熟悉无障碍的前端也能写出合格代码 WCAG 2.1 条款繁多，团队里通常只有少数人熟悉。技能把规范沉淀为模板：role="dialog" 该配哪些属性、对比度该算到多少、表单错误该怎么播报，开发者不需要先成为专家，也能产出接近专家水准的实现。

可量化收益：把模糊的“体验优化”变成可验收的指标

对比度从“看起来还行”变为明确的 4.5:1 / 3:1 数值判定；
键盘可达性从“应该能点”变为 Tab 循环 + Escape 关闭 + 焦点回归 三项可测行为；
回归防护从“上线后被告知”变为 npm test 中的 toHaveNoViolations() 断言。

长期价值：合规、口碑与用户面的三重收益 可访问性不仅是合规要求，也直接影响 SEO 语义结构、老年用户与临时受伤用户（如骨折、眼部手术恢复期）的使用体验，以及企业采购时的资质评估。把无障碍能力沉淀进组件库与测试流水线后，后续每个新页面都在“已经合规”的地基上生长，边际成本趋近于零。

7. 常见问题 FAQ

Q1：网络可访问性技能怎么安装？装完怎么确认生效？ 在支持 Skill 机制的 AI 平台中，于技能市场/技能中心搜索「网络可访问性」「web-accessibility」或技能 ID「13136」，找到条目后一键安装并启用。验证方式：新建对话输入“帮我给这个模态框补齐 ARIA 属性和键盘交互”，若回复中出现 role="dialog"、aria-modal="true"、Tab 循环等具体实现，即说明已生效。若检索不到或安装后无响应，请核对平台版本与技能上架状态，以官方说明为准。

Q2：这个技能收费吗？ 技能本身的收费与授权方式取决于所在平台的规则，请以官方说明为准。技能所引用的技术标准（WCAG 2.1、WAI-ARIA APG）与推荐工具（axe-core、jest-axe、@axe-core/react）均为公开资源，可按各自开源许可使用。

Q3：它适合谁用？ 最适合三类人：一是正在开发或维护 React/TSX 前端组件库的工程师；二是需要应对合规审查、采购问卷或海外客户要求的产品与前端团队；三是刚接触 a11y、希望快速掌握规范写法的开发者。对纯后端或非 Web 端（如原生客户端）场景，帮助有限。

Q4：装了它，是不是就能 100% 通过 WCAG 审计？ 不能。技能解决的是“怎么写对”的问题，输出的是高质量代码模板与测试接入方式，但可访问性高度依赖真实交互。自动化规则通常只能覆盖一部分问题，焦点顺序是否自然、读屏播报是否符合用户预期、复杂业务弹窗的语义是否准确，仍需人工用键盘与读屏软件实际走查。建议把技能输出 + 自动化测试 + 人工复核三者结合。

Q5：它和 axe DevTools、Lighthouse 是什么关系？该选哪个？ 三者互补，不冲突。Lighthouse 与 axe DevTools 是“体检工具”，负责发现页面上的违规项；网络可访问性技能是“写作助手”，负责把违规项改写成符合规范的代码；eslint-plugin-jsx-a11y 则是“门禁”，在提交前拦截低级问题。推荐组合使用：编码时用技能生成正确实现，提交时用 ESLint 卡点，上线前用审计工具复核。