Atag Mcp

io.github.MMaseyPublished by GitHub account MMaseyv1.0.2Updated Oct 24, 2026

ATAG 2.0 (Authoring Tool Accessibility Guidelines) guidance for authoring tool developers

VerifiedSTDIODesktop onlyKnowledge & MemoryDeveloper Tools

Overview

AI-generated overview

Serves the W3C ATAG 2.0 accessibility guidelines so an assistant can look up criteria and map them to authoring-tool features.

What you can do
  • Browse the ATAG structure: parts, principles, guidelines and success criteria, filtered by part, principle, guideline or conformance level
  • Read full details of a specific success criterion or guideline, including its child criteria
  • Search all ATAG content by keyword and look up glossary terms and their definitions
  • Describe a feature being built and get the most relevant ATAG criteria for it
  • Retrieve dataset statistics and attribution for the bundled spec copy
When to use it
Useful when building or reviewing authoring tools such as rich-text editors, CMSes, IDEs or website builders and you want the assistant to cite actual ATAG 2.0 success criteria instead of recalling them from memory. Also handy for checking Level A, AA or AAA criteria and ATAG terminology.
Requirements
Runs locally over stdio; the README suggests letting the MCP client fetch the npm package via npx, so Node.js and network access for the initial package download are needed. No accounts, API keys or environment variables are declared.
Before you install
Read-only reference data: the spec is a static, hand-checked copy bundled with the package, so it can lag behind the W3C source until updated. No credentials, payments or write actions are involved.

Installation

In SourceWeft

  1. Open Atag Mcp in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

ATAG MCP

An MCP (Model Context Protocol) server that provides guidance on ATAG 2.0 — the W3C Authoring Tool Accessibility Guidelines — to help authoring tool developers build more accessible software.

What is ATAG?

ATAG 2.0 defines how authoring tools (rich-text editors, CMSes, IDEs, website builders, etc.) should:

  • Part A — Be accessible to authors with disabilities (the tool's own UI)
  • Part B — Help authors produce accessible web content (alt text prompts, accessibility checkers, accessible templates, etc.)

Why this exists

ATAG 2.0 has been a W3C Recommendation since 2015, but adoption among authoring tools remains limited — partly because the guidance is easy to overlook at the moment design and implementation decisions are actually made. With more authoring tool features now being built with the help of AI coding assistants, this server puts the full spec within the assistant's reach: describe the feature you're working on (an image upload dialog, a rich-text toolbar, a template picker) and get back the actual success criteria that apply, rather than a half-remembered summary. The aim is to lower the cost of considering ATAG at all — the first step towards tools that support it.

The data is a static, hand-checked copy of the ATAG 2.0 spec — not fetched or generated at runtime — so answers stay faithful to the W3C source. A weekly workflow checks for upstream spec changes.

Tools

ToolDescription
get-server-infoDataset statistics and attribution
explain-atagOverview of ATAG, how it differs from WCAG, and its two-part structure
list-partsPart A and Part B summaries
list-principlesAll 8 principles, filterable by part
list-guidelinesAll 24 guidelines, filterable by part or principle
list-success-criteriaAll 63 success criteria, filterable by part, principle, guideline, or level
get-criterionFull details for a specific SC (e.g. B.2.3.1)
get-guidelineFull guideline details with all child success criteria
get-criteria-by-levelAll criteria at Level A, AA, or AAA
search-atagKeyword search across all ATAG content
list-glossary-termsAll ATAG glossary terms
get-glossary-termDefinition of a specific ATAG term
get-guidanceKey tool — describe a feature you're building and get the most relevant ATAG criteria

Setup

No local install required — add the config below and your MCP client will fetch the package automatically via npx.

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

json
{  "mcpServers": {    "atag-mcp": {      "command": "npx",      "args": ["-y", "atag-mcp"]    }  }}

VS Code (Claude extension)

json
{  "mcp": {    "servers": {      "atag-mcp": {        "type": "stdio",        "command": "npx",        "args": ["-y", "atag-mcp"]      }    }  }}

Local development install

bash
npm installnpm run build# then point your config to dist/index.js directly

Usage examples

Ask Claude:

  • "What ATAG criteria apply to an image insertion dialog?" → uses get-guidance
  • "Show me all Level A criteria from Part B" → uses get-criteria-by-level
  • "Explain guideline B.3.1" → uses get-guideline
  • "What does 'editing-view' mean in ATAG?" → uses get-glossary-term
  • "Search ATAG for keyboard access" → uses search-atag

Development

bash
npm run dev          # Run server directly with tsx (no compile step)npm test             # Run all testsnpm run test:watch   # Watch modenpm run validate-data  # Validate data/atag.json structurenpm run check-updates  # Check if W3C spec has changed

Branching and commits

This project follows git flow with Conventional Commits:

  • main — released code only; every merge to main is tagged and published
  • develop — integration branch; day-to-day work lands here
  • feature/<name> — branched from and merged back to develop
  • release/<version> — branched from develop, merged to main (tagged) and back to develop
  • hotfix/<name> — branched from main for urgent fixes, merged to both main and develop

Commit messages use conventional prefixes: feat:, fix:, docs:, test:, ci:, chore:, refactor: (with ! or a BREAKING CHANGE: footer for breaking changes).

Releasing

Versioning uses standard npm version bumps. Pushing a v* tag triggers the GitHub Actions publish workflow, which runs tests and publishes to npm automatically.

bash
npm version patch   # bug fixes:    1.0.0 → 1.0.1npm version minor   # new features: 1.0.0 → 1.1.0npm version major   # breaking:     1.0.0 → 2.0.0
git push && git push --tags

When bumping the version, also update the version fields in server.json to match — the MCP Registry validates them against the published npm package. After the npm publish succeeds, refresh the registry listing with:

bash
mcp-publisher login githubmcp-publisher publish

Publishing requires the NPM_TOKEN repository secret (a granular npm access token with write access to atag-mcp). If the token expires or is rotated, add the new one under the same secret name, then run the manual Check npm token workflow (Actions tab) to verify it authenticates before tagging a release.

Keeping data current

The ATAG 2.0 spec is captured in data/atag.json. The GitHub Actions workflow (.github/workflows/update-atag.yml) runs weekly and opens an issue if the W3C spec content changes.

To update manually:

  1. Review changes at https://www.w3.org/TR/ATAG20/
  2. Edit data/atag.json with the changes
  3. Run npm run validate-data to check structure
  4. Run npm run check-updates -- --save to update the stored hash

Data

  • Version: ATAG 2.0
  • Specification: https://www.w3.org/TR/ATAG20/
  • Parts: 2 (Part A + Part B)
  • Principles: 8
  • Guidelines: 24
  • Success Criteria: 63
  • Glossary Terms: 18

License

MIT

Source: README.md at commit 1cfdaac

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v1.0.2LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts