A11yEco: Open-Source WCAG 2.2 Accessibility Tools (Chrome Extension + CLI)
Accessibility shouldn't require a consultant, a budget line, or a last-minute audit. But for most teams, checking a site against WCAG 2.2 means either expensive paid tooling or a pile of disconnected browser extensions that don't talk to each other.
A11yEco started from a different premise: compliance testing should be a natural part of the development workflow — for every team, at every stage, on every budget. It's a suite of professional accessibility tools — Chrome extension, CLI, and a Figma plugin (coming soon) — all powered by the same open-source core, and all completely free.
The full toolkit: one engine, four interfaces
Every A11yEco tool runs the same shared engine: @a11yeco/core, built on axe-core — the open-source accessibility testing engine developed by Deque Systems and used by major companies and governments worldwide. Scores, fingerprints, and WCAG references are consistent across every tool in the ecosystem.
- Chrome Extension — full-page axe-core scans, vision simulation, contrast checker, ARIA tree, focus order, history and dashboard — all in a side panel. Available now.
- CLI Tool — scan any URL from your terminal, crawl entire sites via link discovery or sitemap, and output JSON, Markdown, or SARIF for CI/CD pipelines. Available now.
- Figma Plugin — check colour contrast, heading hierarchy, and alt text directly in design files before a line of code is written. Coming soon.
Three principles guide the whole project:
- Standards-first — every rule maps to a WCAG 2.2 success criterion. No vague heuristics, just the spec faithfully implemented.
- Privacy by design — all data stays in your browser. No telemetry, no servers, no accounts. Your scans belong to you.
- Open & composable — built on a shared library you can extend, fork, and build on.
The Chrome extension: an accessibility co-pilot
The extension (Manifest V3) gives you everything needed to build, audit, and monitor WCAG 2.2 compliance right inside Chrome — no backend, no account, and nothing leaving your browser. A scan surfaces issues ranked by severity, like missing alt text on 1 node, low contrast on 1 node, or empty button label.
Features in one panel:
- Component Scan — right-click any element to audit just that component, ideal for React, Vue, and Angular.
- Full-Page axe-core Scan — instant WCAG 2.2 A/AA/AAA audit powered by axe-core.
- Accessibility Score — a 0–100 score that tracks accessibility health over time.
- Contrast Checker & Bulk Scanner — eyedropper, manual input, and full-page contrast analysis.
- Vision Simulation — preview how your site looks with 7 types of colour vision deficiency.
- Focus Order & Keyboard Audit — visualize the complete focus sequence with numbered overlays.
- ARIA Tree Inspector — explore the live accessibility tree: roles, names, states, and properties.
- Heading Structure — validate heading hierarchy and catch skipped levels at a glance.
- Landmark Navigation — inspect ARIA landmarks and flag missing or duplicate regions.
- Reading Order Overlay — visualize DOM reading order vs visual layout to catch reflow issues.
- Text Spacing Override — apply WCAG 1.4.12 text spacing values with one toggle.
- Reduced Motion Toggle — force
prefers-reduced-motionto test animation fallbacks. - Alt Text Overlay — render
altattributes and ARIA labels directly on every image. - Scan History & Trend Analytics — track score and issue counts per URL over time.
- Dashboard & Priority Queue — cross-site POUR health, user-group impact, and a ranked fix list.
- Issue Status Tracking — mark issues as acknowledged, in-progress, or false positive.
- Scheduled Background Scans — set hourly, daily, or weekly scans via the Chrome Alarms API.
Your data never leaves your browser
A11yEco has no backend. Scan history, issue metadata, and settings are stored in Chrome's IndexedDB — local to your browser. There is no analytics, no telemetry, and no account required.
The CLI: accessibility scanning in your terminal
The CLI (a11yeco) brings the same engine to your terminal and your CI pipeline:
# Install globally, or run without installing
npm install -g @a11yeco/cli
npx @a11yeco/cli https://yoursite.com
Installation is genuinely zero-friction — the CLI uses a headless Chromium browser to render pages, and if it detects the browser is missing, it downloads it automatically on first run.
What you can do with it:
- Scan a single URL and get a Markdown report printed to your terminal.
- Scan multiple URLs at once, with a combined summary table.
- Scan a single component with
--selector ".checkout-form"— perfect for component libraries and focused regression gates. - Crawl an entire site via link discovery (breadth-first,
--max-pagesdefault 50,--concurrencyup to 32 pages in parallel) or via asitemap.xmlwith--crawl sitemap. - Output four formats — Markdown, JSON (for dashboards and post-processing), SARIF 2.1.0 (for GitHub Code Scanning and Azure DevOps), and a self-contained, shareable HTML report.
Which WCAG levels you check is up to you: --level A, the default A,AA, or A,AA,AAA.
Fail CI builds on accessibility violations
The --fail-on flag exits with code 1 when violations meet a severity threshold:
a11yeco https://yoursite.com --fail-on serious
Pair that with SARIF output, and you can upload results directly to GitHub Code Scanning so accessibility violations show up like any other code quality finding.
Gate on what changed, not the backlog
A plain --fail-on gate punishes your whole backlog — if your site already has 40 known violations, the build fails on all of them every time. Baseline gating flips the question: did anything get worse?
Wired together, the workflow looks like this:
# Seed the baseline from a state you're happy with
a11yeco https://yoursite.com --crawl links --save-baseline .a11yeco/baseline.json
# Gate CI: fail on any new violation
a11yeco https://yoursite.com --crawl links --baseline .a11yeco/baseline.json --fail-on-new
# Nightly monitor: gate, then refresh the baseline only when nothing regressed
a11yeco https://yoursite.com --crawl links \
--baseline .a11yeco/baseline.json --fail-on-new --save-baseline .a11yeco/baseline.json
A baseline file records the current state as the "known accepted" set of violations. Subsequent runs exit with code 1 on anything new — a new violation on a known page, a severity increase, or a newly discovered page with violations. The nightly monitor re-baselines automatically, but only when every gate passes — so a regressing state can never be blessed into the baseline.
There's a complete GitHub Actions example in the docs that gates every pull request, plus a nightly monitoring workflow that commits the refreshed baseline only on a clean run.
WCAG 2.2 rules, mapped and explained
The WCAG 2.2 rules reference documents all 105 accessibility rules from axe-core, each mapped to its WCAG 2.2 success criteria and level — from color-contrast (Level AA) and image-alt (Level A) through to target-size, heading-order, and label-content-name-mismatch. Every issue you see in a scan links back to exactly what it means and how to fix it.
Is A11yEco really free?
Yes. The Chrome extension and the CLI are both completely free and open source. There are no paid plans, no subscriptions, and no account requirements. Full stop.
Frequently asked questions
What is axe-core?
axe-core is an open-source accessibility testing engine developed by Deque Systems. It's an industry-standard tool for automated WCAG compliance testing, used by major companies and governments worldwide. A11yEco runs axe-core in every scan.
Does A11yEco send my data to a server?
No. The Chrome extension runs entirely in your browser. All scan results are stored locally in IndexedDB — no analytics, no telemetry, no accounts, and no servers. Your data never leaves your device.
What WCAG level does A11yEco check?
A11yEco supports WCAG 2.2 Levels A, AA, and AAA. By default it checks A and AA, which covers the legal compliance requirements of most regions. You can configure the level in each tool's settings.
Can I use A11yEco in CI/CD?
Yes. The CLI supports SARIF output for GitHub Code Scanning, Azure DevOps, and other CI platforms. Use --fail-on to fail builds when violations meet a severity threshold, and --crawl to scan entire sites via link discovery or sitemap.
What's supported: WCAG 2.2 vs the 105 rules?
The rule reference documents all 105 axe-core accessibility rules, each mapped to a WCAG 2.2 success criterion at level A, AA, or AAA. It's the same engine that powers A11yEco's scans.
Start scanning today
The Chrome extension installs in seconds, requires no account, and runs everything locally in your browser. Or open your terminal and scan a URL right now with npx @a11yeco/cli.
Add the extension to Chrome — free → Install A11yEco
Or bring accessibility into your CI → Try the CLI