AccessLint — web accessibility (a11y) skills

Agent Skills for finding and fixing web accessibility issues, powered by @accesslint/core. They cover the WCAG 2.2 audit workflow end to end: automated scanning, hands-on keyboard and screen-reader checks, WCAG-EM conformance auditing, remediation, and regression diffing.

Works with any agent the skills CLI supports — Claude Code, Cursor, Codex, Copilot, Windsurf, Gemini, Cline, Amp, and more.

Keywords: accessibility · a11y · WCAG 2.2 · Section 508 · screen reader · keyboard navigation · color contrast · ARIA · inclusive design

The skills

Five skills, each with one responsibility. Each finding is graded on two axes — severity (user impact) and evidence basis (● verified · ◐ confirm with a human · ○ human-required).

LOCATE                                 ASSESS                 REMEDIATE           GUARD
accessibility-scan    (automated) ┐
                                  ├─► accessibility-audit ─► accessibility-fix ─► accessibility-diff
accessibility-inspect (manual)    ┘   (WCAG-EM)              (edit→verify)       (regression)

The methodology they follow — WCAG-EM, the two grading axes, the boundary against standing in for real assistive-technology users — is in plugins/accesslint/skills/shared/methodology.md.

Install

Any agent (skills CLI)

npx skills add AccessLint/skills

Installs the five skills. accessibility-scan and accessibility-diff work immediately (they shell out to @accesslint/cli). accessibility-fix needs the MCP server below; accessibility-audit and accessibility-inspect also use it for rule metadata (list_rules / explain_rule) when it's available.

Claude Code (plugin)

claude plugin marketplace add accesslint/skills
claude plugin install accesslint@accesslint

Adds the skills and the bundled MCP server together, and namespaces the skills as accesslint:accessibility-scan and so on.

MCP server on its own

{
  "mcpServers": {
    "accesslint": {
      "command": "npx",
      "args": ["-y", "@accesslint/mcp@latest"]
    }
  }
}

Use

Ask in plain language — "audit this site for accessibility", "is localhost:3000 accessible", "fix the a11y issues in Nav.tsx" — or invoke a skill directly if your agent supports slash commands:

/accessibility-scan http://localhost:3000/dashboard
/accessibility-audit --level AA http://localhost:3000/
/accessibility-diff --branch main

Every skill takes a URL, a named target from accesslint.config.json, or nothing (the default target). Run npx @accesslint/cli init to set targets up once, then drop the URL.

Requirements

Most a11y violations only appear after JS runs, so these skills work against a rendered page. scan, diff, audit, and fix reach the live DOM over CDP, auto-launching Chrome when no debug session is reachable — no setup.

accessibility-inspect drives the page, which needs a browser MCP (chrome-devtools, Playwright, or Puppeteer). Without one it runs the static checks and hands off the rest. In Claude Code:

claude mcp add chrome-devtools npx -- -y chrome-devtools-mcp@latest

For a page behind a login, start a headed debuggable Chrome (npx @accesslint/chrome ensure --headed) and sign in there; accessibility-fix attaches to that session instead of launching its own.

MCP tools

The plugin bundles @accesslint/mcp, which backs accessibility-fix's baseline and verify runs and supplies rule metadata. The tools are also callable directly.

Installed standalone they are mcp__accesslint__<tool>; installed as a Claude Code plugin, mcp__plugin_accesslint_accesslint__<tool>.

The hosted connector

The server this plugin bundles runs on your machine. It drives a Chrome you can watch, reaches localhost, staging and production alike, and keeps nothing — each call audits and returns.

AccessLint's hosted connector is a different server for the work that needs memory: a user journey across several pages, a site re-checked over time, findings that persist, and a report someone else can read. There those are flows, runs and violations. You add it in a chat client — Claude.ai, ChatGPT, or any MCP client — as a custom connector rather than installing it from npm, and it signs you in to an accesslint.com account:

https://mcp.accesslint.com/mcp

It cannot reach localhost. Both servers register under the name accesslint; this is the one with a way into your dev server.

WCAG coverage

Level A and AA — perceivable (alt text, contrast, structure), operable (keyboard, focus), understandable (labels, language), robust (ARIA, accessible names). AAA rules are opt-in via --include-aaa. Run list_rules for the active set in your installed version.

The engine catches what is mechanically detectable. Content clarity, announcement quality, keyboard-flow coherence, and lived experience need a person — these skills name and hand those off rather than guessing at them.

Resources

• WCAG 2.2 Guidelines
• WCAG-EM evaluation methodology
• WAI-ARIA Authoring Practices
• @accesslint/mcp on npm
• AccessLint hosted MCP connector — flows, runs and violations for a deployed site

License

MIT