Accessibility Agents: Eleven Specialists That Keep WCAG 2.2 AA in an AI Tool's Context
Accessibility review agents for Claude Code, GitHub Copilot, and Claude Desktop. Eleven specialists that enforce WCAG 2.2 AA compliance so AI coding tools stop generating inaccessible code.
At a glance
- What is it?
- Community-Access/accessibility-agents is an MIT-licensed collection of agents, skills and prompts that push accessibility rules into Claude Code, GitHub Copilot, Gemini CLI, Codex CLI and an MCP server. The premise is that LLMs drop accessibility context; the trade-off is that you now depend on several fast-moving platform APIs staying compatible.
- Who is it for?
- Adopt it if your team already writes code inside Claude Code, Copilot, Gemini CLI or Codex CLI and you want WCAG 2.2 AA rules present in every conversation rather than pasted in by hand. Skip it if you need deterministic, blocking enforcement: the project's own README says AI and automated tools are not perfect and cannot replace testing with VoiceOver, NVDA, JAWS and keyboard-only navigation.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 35 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure mode these agents were built to catch
The README states the problem plainly: AI coding tools generate inaccessible code by default. It lists the specific ways this shows up. ARIA gets misused. Focus management gets skipped. Color contrast fails silently. Modals trap screen reader users. Keyboard navigation is left out. The maintainers say they wrote CLAUDE.md instructions and skills, and the accessibility context still got deprioritized or dropped entirely. That last point is the real claim. It is not that models cannot describe WCAG, it is that the rules fall out of the working context once a session gets long or a task gets narrow. The target user is a developer who already has an AI coding tool open and wants the accessibility constraints to survive the session. This is not an auditing product for a compliance officer who never opens an editor, and it is not a replacement for a manual audit with assistive technology. The README says so directly in its opening blockquote.
Eleven specialists, eight teams, five runtimes
The headline number in the README is seventy-nine agents across eight teams and five platforms. The repository description narrows the pitch to eleven specialists that enforce WCAG 2.2 AA. Both numbers appear in the supplied material and they measure different things: the eleven are the accessibility reviewers, the seventy-nine span everything including a twenty-agent GitHub Workflow team that handles triage, PR review, project boards, CI/CD, security alerts, releases, notifications and wiki pages. That breadth is worth pausing on. A team that only wants WCAG checks is installing a lot of repository automation alongside them. The teams are split as Web Accessibility (WCAG AA enforcement plus i18n/RTL, AAA coverage, data visualization, email, media, web components and performance), Document Accessibility (DOCX, XLSX, PPTX, PDF, EPUB, Markdown), GitHub Workflow, Developer Tools (Python, wxPython, desktop accessibility, NVDA addon development), Education and Standards (screen reader simulation, WCAG 3.0 preview, AAA auditing) and Cross-cutting (CI/CD pipelines, compliance mapping, accessibility statements, regression detection, orchestrators).
How dispatch actually works across the five platforms
The integration model differs per platform, and that is the most concrete architectural detail in the README. On Claude Code, agents are invoked directly for accessibility evaluation. On GitHub Copilot in VS Code and the CLI, you get agents plus workspace instructions, so guidance is present in every conversation rather than only when an agent is called. Gemini CLI uses a skills-based extension with always-on WCAG AA context delivered through GEMINI.md. Codex CLI is described as a native plugin with small router skills, custom subagents, lazy specialist references and extension-aware dispatch. The MCP server is HTTP-based and exposes 24 accessibility scanning tools to any MCP-compatible client, naming Claude Desktop, VS Code and CI/CD pipelines. The v6.0.0 release notes, titled Accessibility Agents 6.0: Codex, Extensions, and Enforced Specialist Dispatch, suggest the Codex path and the routing behaviour were the focus of that release. The lazy specialist reference pattern in Codex is the interesting one: rather than loading every specialist into context, a router skill pulls the relevant one in on demand. That is a direct answer to the context-drift problem, and it is the design choice I would want documented in more depth than the README provides.
Getting it running: commands and config keys from the material
The README's update section gives the commands you would actually type. To update the skill itself, gh extension upgrade gh-skill. To pull the latest repository changes when working from source, cd accessibility-agents followed by git pull origin main. Node.js tooling is updated with npm update -g @axe-core/cli and npm update -g pa11y. Claude Code CLI updates through claude code update. Platform requirements are stated as Node.js v18.0.0 or higher, macOS 10.15 Catalina or later, or Windows 10/11 with PowerShell 5.1 or later. Claude Code needs a Pro, Max or Team subscription. Gemini CLI needs a Google AI Studio API key. The always-on context file for Gemini is GEMINI.md, and Copilot relies on workspace instructions. The README does not give a single install command for the agents themselves in the supplied excerpt, so treat the update commands as the confirmed surface and check the repository for the initial setup step before you plan a rollout.
The version-currency requirement is a real operating cost
The README marks tool currency as CRITICAL and asks that all tools stay on their latest versions. It gives five reasons: platform API changes, new accessibility features in the host tools, bug fixes for tool invocation and orchestration, security patches, and WCAG evolution. Read that as a maintenance statement rather than a marketing one. You are not installing a self-contained linter. You are installing a layer that sits on top of VS Code, GitHub Copilot and Copilot Chat extensions, Claude Code CLI, Gemini CLI, Codex CLI, Node.js and axe-core or pa11y. Any of those shifting can change agent behaviour. The v5.3.0 and v5.4.0 releases, both dated 2026-05-06 and titled CI Reliability and Release Safety and Playwright Runtime Checks and CI Guard Rails, point at the same thing from the project side: the maintainers are spending release cycles on reliability rather than new specialists. That is a healthy signal, and it is also a warning that the integration surface is where the work lives.
Where this is the wrong tool
The README's own disclaimer is the strongest limitation and it deserves to be taken literally: AI and automated tools are not perfect, they miss things, make mistakes, and cannot replace testing with real screen readers and assistive technology. It names VoiceOver, NVDA, JAWS and keyboard-only navigation as the verification step. So the boundary is clear. If your requirement is a signed accessibility conformance report, an agent team is not the evidence. If your build pipeline needs to fail a pull request on a contrast regression, an agent that reasons in natural language is a weaker guarantee than a deterministic axe-core run, even though the project does ship CI/CD pipeline agents and regression detection under its Cross-cutting team. And if your stack is not one of the five supported platforms, the MCP server is the only entry point, and it exposes scanning tools rather than the specialist reviewers. That is a smaller product than the headline.
What to compare against: axe-core and pa11y directly
The honest alternative is to skip the agent layer and run the underlying tools yourself. The README already points at them: @axe-core/cli and pa11y are installed with npm and updated with npm update -g. The difference in approach is not quality, it is timing and determinism. axe-core and pa11y evaluate rendered output and return rule violations you can gate a build on. They do not read your source as you write it, they do not explain why a modal traps focus, and they do not suggest a fix in the same breath. Accessibility Agents sits earlier, inside the conversation, and works on intent as well as output. The trade-off is the reverse: an agent can be wrong, can be ignored, and can drift when context is trimmed, while a rule engine returns the same answer every run. Most teams that care about both will want the rule engine in CI and the agents in the editor, which is roughly what the project's own CI/CD and regression-detection agents imply.
Licence, contributions and what to check before adopting
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive position and it matters here because you are copying agent definitions and instruction files into your own repositories. Keep the LICENSE file with anything you vendor. The README also states the project wants more contributors and points to CONTRIBUTING.md, with support handled in a separate Community-Access/support repository for discussions and issues, and curriculum in Community-Access/git-going-with-github. This is a community project with named leads, Taylor Arndt and Jeff Bishop, rather than a vendor product, so the support path is a GitHub discussion, not a contract. Before adopting, confirm which specialists your specific platform dispatches, since the enforced dispatch behaviour is a v6.0.0 feature and the README does not enumerate the routing rules. Then run one real component through a specialist and check the output against NVDA or VoiceOver yourself.
Editorial conclusion
Adopt it if your team already writes code inside Claude Code, Copilot, Gemini CLI or Codex CLI and you want WCAG 2.2 AA rules present in every conversation rather than pasted in by hand. Skip it if you need deterministic, blocking enforcement: the project's own README says AI and automated tools are not perfect and cannot replace testing with VoiceOver, NVDA, JAWS and keyboard-only navigation. Before rolling it out, verify which of the eleven specialists your platform actually dispatches, check that the MCP server exposes the scanning tools your CI pipeline needs, and confirm your Node.js version is at least 18.0.0.
Community notes