A11y Mcp

A11y MCP 服务

一个使用 axe-core 对网页进行无障碍审计的 MCP（Model Context Protocol）服务。在与您喜欢的 AI 助手（Cline/Cursor/GH Copilot）进行 Agent 式循环时使用审计结果，让它们帮您修复无障碍问题！

功能

• 对任意网页执行详细的无障碍审计
• 获取无障碍问题摘要
• 按特定 WCAG 标准筛选审计结果
• 在结果中包含 HTML 片段，便于调试

安装

# Install globally
npm install -g a11y-mcp

# Or use directly with npx
npx a11y-mcp

配置

要将此 MCP 服务与 Cline 配合使用，您需要将其添加到 MCP 设置配置文件中。

MCP 配置

将以下内容添加到 mcpServers 对象中：

{
  "mcpServers": {
    "a11y": {
      "command": "npx",
      "args": ["a11y-mcp"],
      "disabled": false,
      "autoApprove": []
    }
  }
}

可用工具

audit_webpage

对网页执行详细的无障碍审计。

参数：

• url（必填）：要审计的网页 URL
• includeHtml（可选）：是否在结果中包含 HTML 片段（默认值：false）
• tags（可选）：要检查的特定无障碍标签数组（例如：wcag2a、wcag2aa、wcag21a、best-practice）

示例：

Use the a11y MCP server to audit example.com for accessibility issues

get_summary

获取网页无障碍问题的摘要。

参数：

• url（必填）：要审计的网页 URL

示例：

Give me an accessibility summary of example.com

使用示例

配置完成后，您可以让 Claude 使用 MCP 服务执行无障碍审计：

1. “可以帮我检查 example.com 是否存在无障碍问题吗？”
2. “审计我的网站 https://mywebsite.com，检查其是否符合 WCAG 2.1 AA 标准”
3. “总结一下 https://example.com 上的无障碍问题”
4. “检查我的本地开发服务 http://localhost:3000 是否存在严重的无障碍问题”

开发

在本地运行服务以进行开发：

npm start

发布

此项目包含一个发布脚本，可帮助管理版本并发布到 npm。该脚本会处理版本升级、运行测试、创建 git 标签和发布到 npm。

要发布新版本：

# Make sure the script is executable
chmod +x release.sh

# Release a patch version (default)
./release.sh

# Release a minor version
./release.sh --minor

# Release a major version
./release.sh --major

# Release a specific version
./release.sh --version=1.2.3

# Skip git operations
./release.sh --skip-git

# Dry run (no changes will be made)
./release.sh --dry-run

# Force release even with uncommitted changes
./release.sh --force

如需了解更多信息，请运行：

./release.sh --help

许可证

MPL 2.0

致谢

此项目基于 axe-core 的出色成果构建。

安全与托管

需要 Node.js 22.12 或更高版本。Chrome 在启用沙箱的情况下运行。 所有 HTTP(S) 连接（包括重定向和子资源）都通过验证代理，该代理会固定目标 IP。私有、链路本地、多播、保留地址和云元数据地址均会被阻止，包括映射的 IPv6 地址。 回环地址仍可用于本地开发；如需仅进行公共网络审计，请设置 AUDIT_ALLOW_LOOPBACK=false。不再支持 LAN 地址。 每个 MCP 进程同时只运行一次审计，浏览器截止时间为 90 秒。 用于托管时，还应隔离浏览器工作进程，并在基础设施层实施网络出口限制。axe 自动化检查无法证明符合 WCAG 标准；仍需进行人工审查。

运行 npm test、npm run test:smoke（需要 Chrome）和 npm audit。

维护者 CI 和发布

GitHub Actions 会在最低支持的 Node 版本和 Node 24 上运行构建、网络和发布策略测试、npm 安全审计以及真实 Chrome 冒烟测试。Node 24 还会在干净的临时项目中安装 npm 压缩包，并检查其可执行文件、依赖项、MCP 版本和浏览器审计。

每次推送到 main 都会运行发布流水线。当软件包文件发生变化时，流水线会自动递增补丁版本（或采用已提交的更高版本）、同步软件包元数据、重新运行验证、提交并为发布打标签、通过 provenance 发布到 npm，并创建 GitHub release。仅涉及文档、测试或工作流的更改不会发布新版本。运行时服务版本来自 package.json。

Dependabot 每周检查 npm 和 GitHub Actions。PR CI 运行成功后，只有当所有现有的已更改依赖项都是稳定的补丁或次要版本升级，且仅 package.json / package-lock.json 发生变化时，系统才会自动合并 npm 更新。主版本升级、0.x 次要版本升级、降级、预发布版本和 GitHub Actions 更改都需要审核。合并任务仅运行来自 main 的可信代码，会验证已测试的 PR 提交，并在 Bot 合并后显式触发发布。

npm 发布使用 npm GitHub 环境和 npm 可信发布者，配置为 priyankark/a11y-mcp、工作流 publish.yml、环境 npm，并允许直接发布。GitHub 中不会存储 npm 令牌。该环境仅接受来自 main 的部署。

若要重试失败的发布，请重新运行 Publish 工作流，或运行 ./release.sh。流水线会重用尚未发布的版本，并跳过已发布且未更改的软件包。如果预留的发布标签指向不同的代码，流水线会停止，而不会覆盖该版本。对于破坏性更改，请在合并前，在经过审核的 PR 中将 package.json 和 package-lock.json 更新为预期的主版本或次要版本。