WCAG Audit vs accessiBe: source-level testing vs. overlay widgets
Accessibility overlays add a JavaScript widget on top of your page. They don't fix your code, they don't satisfy legal requirements, and they often make things worse for disabled users. Here's why source-level auditing is the right approach.
AccessiBe can't audit logged-in pages. We can.
AccessiBe is a JavaScript overlay widget injected on public-facing pages. It has no mechanism to log in to your application, navigate your dashboard, or inspect admin routes. That means every accessibility issue inside your authenticated experience — the parts where your users actually spend their time — goes completely undetected.
WCAG Audit is a testing pipeline, not an overlay. The CLI accepts exported auth state (--auth-storage auth.json) and the browser extension runs inside your live session. Both tools audit dashboards, settings pages, checkout flows, and admin panels with the same 12 checkers and AI vision review used on public routes. Violations are reported as code-level findings you can fix — not patched at runtime and forgotten.
Actual remediation vs. theatrical compliance
accessiBe's overlay adds a JavaScript widget that rearranges the DOM at runtime. The underlying HTML, CSS, and ARIA are still broken. If the script fails to load, every "fix" vanishes. Courts, the FTC, and 700+ accessibility professionals have called this approach what it is: theatrical compliance that harms disabled users while giving organizations a false sense of security. WCAG Audit takes the opposite approach — it finds the actual violations in your source code and gives your developers the exact selectors, screenshots, and fix guidance they need to remediate permanently.
The core difference
WCAG Audit (recommended)
Finds the problem. Runs 12 checkers plus AI vision review against your actual page. Generates an Excel report with annotated screenshots and CSS selectors so your developers can fix the source code. Violations are gone permanently.
accessiBe (not recommended)
Hides the problem. Injects a JavaScript overlay that attempts to patch the DOM at runtime. The underlying code is still broken. If the script fails to load, all "fixes" disappear. Courts and accessibility experts have repeatedly rejected this approach.
Feature-by-feature comparison
| Feature | WCAG Audit (recommended) | accessiBe |
|---|---|---|
| Approach | Source-level testing — finds violations in your actual code | JavaScript overlay — patches DOM at runtime without fixing source |
| WCAG 2.2 coverage | 52 of 55 WCAG 2.2 Level A + AA criteria automated across 12 checkers + AI vision | Claims full compliance but independent tests show significant gaps |
| Audit report | Excel workbook with screenshots, CSS selectors, and fix guidance | No exportable audit report |
| Keyboard testing | Automated tab walk, focus order, focus visible, trap detection | Overlay adds keyboard nav widget but doesn't test existing implementation |
| Screen reader | Automated screen-reader label checks + live walkthrough | AI-generated alt text and ARIA — often inaccurate |
| AI vision review | Claude reviews 12 criteria from screenshots (included on paid plans) | AI used to auto-fix (not audit) — no transparency into what changed |
| Legal standing | Audit reports accepted as evidence of good-faith remediation | Overlays explicitly rejected by courts (multiple ADA rulings) |
| Pricing (team of 10) | From $0 (free tier) to $99/mo (Business) | $490/mo per site |
| CI/CD integration | CLI (curl install) + GitHub Action for pipeline gating | No CI/CD integration |
| Data privacy | All audits run locally. Only license validation and page count sent for metering. AI vision forwards screenshots through wcagaudit.io to Anthropic Claude; nothing retained beyond the request. | Third-party JavaScript injected on every page load |
| Audits authenticated pages | Yes — pass --auth-storage auth.json to reach dashboards, admin, and gated routes | No — overlay widget is injected on public pages only. |
| Produces fixable code-level output | Yes — wcag-ai-fix.json + WCAG_FIXES.md with exact selectors for your AI editor | No — auto-patches DOM at runtime; no durable, developer-actionable output |
| Works with AI coding tools | Yes — Cursor rules and wcag-ai-fix.json plug directly into Cursor, Copilot, and Claude Code | No — no integration with AI coding tools |
| Self-hosted (no data leaves your network) | Yes — audits run in your browser or on your CI runner; only violation counts are metered | No — third-party JS loaded from accessiBe CDN on every page view |
| One-shot fix prompt | ✅ WCAG_FIXES.prompt.md — single-pass LLM-applicable fix your AI editor applies in one go | ❌ No fix output of any kind |
| Deterministic codemods (~60% auto-fix) | ✅ 10 built-in codemods auto-fix common WCAG rules without AI | ❌ Runtime overlay only — no source code changes |
| Persistent false-positive memory | ✅ .wcag-audit/false-positives.json — dismiss once, gone from every future scan | ❌ No false-positive registry; re-marks every scan |
| Exact source mapping (file:line) | ✅ @wcag-audit/next-plugin maps violations to exact file + line in your repo | ❌ Points at a CSS selector in the rendered DOM, not your source |
Why courts reject accessibility overlays
Multiple federal courts have ruled that overlay widgets do not satisfy ADA requirements. The FTC fined accessiBe $1M for deceptive marketing in 2024. Organizations relying solely on overlays remain exposed to lawsuits.
Accessibility.com v. Hobby Lobby (2024)
Court found accessiBe overlay insufficient — case proceeded despite overlay being installed
Murphy v. Eyebobs LLC (2023)
Overlay widgets explicitly rejected as a defense against ADA claims
FTC settlement (2024)
accessiBe paid $1M to settle charges of deceptive advertising about compliance claims
What accessibility experts say about overlays
"Overlay widgets are not a substitute for making your website accessible. They create a false sense of security and can introduce new barriers for people with disabilities."
— National Federation of the Blind (public statement)
"No overlay product on the market today can cause a website to become fully compliant with any existing accessibility standard."
— overlayfactsheet.com (signed by 700+ accessibility professionals)
wcag-ai-fix.json: fix the source code, not the DOM
While accessiBe applies a JavaScript overlay that masks issues without fixing them, WCAG Audit generates wcag-ai-fix.json — structured fix prompts you paste into Cursor, Claude Code, or Windsurf to actually fix the source code.
WCAG Audit: wcag-ai-fix.json
Every violation includes the CSS selector, the WCAG criterion, a screenshot, and a structured fix prompt. Open wcag-ai-fix.json in Cursor, Claude Code, or Windsurf and the AI editor fixes the actual HTML/CSS/ARIA in your repository. The fix is permanent — it ships with your next deploy.
accessiBe: runtime overlay
accessiBe patches the DOM after page load with injected JavaScript. No file in your repo changes. No developer sees a diff. If the CDN goes down, the overlay vanishes and every "fix" disappears. There is no exportable, developer-actionable output — just a band-aid that hides the problem.
Switch from overlay to real accessibility testing
Install WCAG Audit and get an Excel report with annotated screenshots showing every violation in your source code — not a band-aid overlay.
curl -fsSL https://wcagaudit.io/install | bash -s -- <license-key>
Need help? Book a demo