内容
# ATAG MCP
一个遵循ATAG 2.0协议的MCP（模型上下文协议）服务器，为作者工具开发者提供指导，帮助他们构建更易访问的软件。
## 什么是ATAG？
ATAG 2.0定义了作者工具（如富文本编辑器、内容管理系统、集成开发环境、网站构建工具等）应该如何：
- **第一部分** — 对残疾作者具有可访问性（工具自身的用户界面）
- **第二部分** — 帮助作者生成易访问的网络内容（替代文本提示、可访问性检查器、可访问模板等）
## 为什么存在这个项目
自2015年以来，ATAG 2.0一直是W3C的推荐标准，但作者工具的采用率仍然有限 — 部分原因是设计和实施决策时容易忽略这一指导方针。现在，更多的作者工具功能是在AI编码助手的帮助下构建的，这个服务器将完整的规范置于助手的触手可及之处：描述您正在构建的功能（图像上传对话框、富文本工具栏、模板选择器），然后获取适用的实际成功标准，而不是半记不清的总结。目标是降低考虑ATAG的成本 — 这是支持它的工具的第一步。
数据是ATAG 2.0规范的静态、手动检查的副本 — 不在运行时获取或生成 — 因此答案始终忠实于W3C源代码。每周的工作流程会检查上游规范的更改。
## 工具
| 工具 | 描述 |
|---|---|
| `get-server-info` | 数据集统计和属性 |
| `explain-atag` | ATAG概述、其与WCAG的区别及其两部分结构 |
| `list-parts` | 第一部分和第二部分摘要 |
| `list-principles` | 所有8个原则，按部分筛选 |
| `list-guidelines` | 所有24个指南，按部分或原则筛选 |
| `list-success-criteria` | 所有63个成功标准，按部分、原则、指南或级别筛选 |
| `get-criterion` | 特定成功标准的详细信息（例如`B.2.3.1`） |
| `get-guideline` | 完整的指南详细信息，包含所有子成功标准 |
| `get-criteria-by-level` | 所有A级、AA级或AAA级标准 |
| `search-atag` | 跨所有ATAG内容的关键词搜索 |
| `list-glossary-terms` | 所有ATAG词汇术语 |
| `get-glossary-term` | 特定ATAG术语的定义 |
| `get-guidance` | **关键工具** — 描述您正在构建的功能并获取最相关的ATAG标准 |
## 安装
无需本地安装 — 添加以下配置，您的MCP客户端将自动通过npx获取包。
### Claude Desktop
编辑 `~/Library/Application Support/Claude/claude_desktop_config.json`（macOS）或 `%APPDATA%\Claude\claude_desktop_config.json`（Windows）：
```json
{
"mcpServers": {
"atag-mcp": {
"command": "npx",
"args": ["-y", "atag-mcp"]
}
}
}
```
### VS Code（Claude扩展）
```json
{
"mcp": {
"servers": {
"atag-mcp": {
"type": "stdio",
"command": "npx",
"args": ["-y", "atag-mcp"]
}
}
}
}
```
### 本地开发安装
```bash
npm install
npm run build
# 然后直接指向dist/index.js
```
## 使用示例
询问Claude：
- *"图像插入对话框适用哪些ATAG标准？"* → 使用 `get-guidance`
- *"显示我第二部分的所有A级标准"* → 使用 `get-criteria-by-level`
- *"解释指南B.3.1"* → 使用 `get-guideline`
- *"ATAG中'editing-view'是什么意思？"* → 使用 `get-glossary-term`
- *"在ATAG中搜索键盘访问"* → 使用 `search-atag`
## 开发
```bash
npm run dev # 直接使用tsx运行服务器（无需编译步骤）
npm test # 运行所有测试
npm run test:watch # 监视模式
npm run validate-data # 验证data/atag.json结构
npm run check-updates # 检查W3C规范是否更改
```
## 分支和提交
该项目遵循 [git flow](https://nvie.com/posts/a-successful-git-branching-model/) 和 [Conventional Commits](https://www.conventionalcommits.org/)：
- `main` — 仅发布代码；每次合并到main都会被标记和发布
- `develop` — 集成分支；日常工作在此进行
- `feature/<name>` — 从develop分支并合并回develop
- `release/<version>` — 从develop分支，合并到main（标记）并返回develop
- `hotfix/<name>` — 从main分支进行紧急修复，合并到main和develop
提交消息使用约定前缀：`feat:`、`fix:`、`docs:`、`test:`、`ci:`、`chore:`、`refactor:`（带有`!`或`BREAKING CHANGE:`后缀的重大更改）
## 发布
版本控制使用标准的npm版本增量。推送`v*`标签会触发GitHub Actions发布工作流程，自动运行测试并发布到npm。
```bash
npm version patch # 错误修复： 1.0.0 → 1.0.1
npm version minor # 新功能： 1.0.0 → 1.1.0
npm version major # 重大更改： 1.0.0 → 2.0.0
git push && git push --tags
```
在更改版本号时，还要更新`server.json`中的`version`字段以匹配 — [MCP Registry](https://registry.modelcontextprotocol.io)会根据发布的npm包验证它们。npm发布成功后，使用以下命令刷新注册表列表：
```bash
mcp-publisher login github
mcp-publisher publish
```
发布需要`NPM_TOKEN`仓库秘密（具有写入`atag-mcp`的npm访问令牌）。如果令牌过期或轮换，请在相同的秘密名称下添加新的令牌，然后运行手动 **检查npm令牌** 工作流程（Actions选项卡）以验证它在标记发布之前能够通过身份验证。
## 保持数据更新
ATAG 2.0规范在 `data/atag.json` 中捕获。GitHub Actions工作流程（ `.github/workflows/update-atag.yml` ）每周运行一次，如果W3C规范内容发生变化，则会开启一个问题。
手动更新：
1. 在 https://www.w3.org/TR/ATAG20/ 查看更改
2. 编辑 `data/atag.json` 以进行更改
3. 运行 `npm run validate-data` 以检查结构
4. 运行 `npm run check-updates -- --save` 以更新存储的哈希值
## 数据
- **版本：** ATAG 2.0
- **规范：** https://www.w3.org/TR/ATAG20/
- **部分：** 2（第一部分 + 第二部分）
- **原则：** 8
- **指南：** 24
- **成功标准：** 63
- **词汇术语：** 18
## 许可证
MIT
