Test a Website for ADA Compliance & WCAG Accessibility

Run a quick, effective scan of your business website for ADA accessibility compliance.

/

Testing a website for ADA compliance and WCAG accessibility has moved from a nice-to-have to a legal requirement with real deadlines attached.

The legal landscape changed meaningfully: the Department of Justice finalized a rule under ADA Title II in April 2024 requiring state and local government websites to meet WCAG 2.1 AA, with compliance deadlines landing in 2026 and 2027 depending on population size, and the European Accessibility Act began applying to businesses serving EU customers in June 2025. Private-sector ADA lawsuits over inaccessible websites continue in the thousands per year, and WCAG 2.2 has been the current standard since late 2023. Knowing where your site stands is the first step, and the good news is that the first pass costs nothing.

Start with Lighthouse

Google’s Lighthouse tool is built into Chrome and gives you a scored accessibility report per page:

  1. Open Chrome and browse to the page you want to test
  2. Right click anywhere and choose Inspect
  3. In the DevTools panel, select the Lighthouse tab (this replaced the old “Audits” tab)
  4. Check Accessibility, pick Desktop or Mobile, and click Analyze page load
  5. In under a minute you get a scored report with each failing element identified

One critical caveat that applies to every automated scanner: Lighthouse’s accessibility checks are powered by axe-core, and automated tools catch roughly a third to half of WCAG failures. A perfect score means the machine found nothing, not that the site is accessible. Keyboard navigation, focus order, screen reader sense-making, and meaningful alt text still need a human pass.

Website Accessibility Report Example

The Testing Stack I Actually Use

  1. axe DevTools: the free browser extension from Deque runs the same engine as Lighthouse but with better issue grouping, guided manual tests, and element highlighting. This is my primary scanner.
  2. WAVE: WebAIM’s evaluation tool overlays findings directly on the page, which makes it the best tool for showing a non-developer what’s wrong and where.
  3. Accessibility Insights: Microsoft’s free tool adds the piece most scanners skip, a guided manual assessment covering the full WCAG criteria, including tab-stop visualization for keyboard testing.
  4. Pa11y: command-line scanning for testing every URL in a sitemap instead of one page at a time, and the natural fit for CI pipelines.
  5. The A11y Project Checklist: a plain-language interactive WCAG checklist, ideal for the human-judgment items automation cannot cover.
  6. W3C WCAG 2.2: the current specification straight from the source, with How to Meet WCAG as the more usable quick reference.
  7. UK Government accessibility posters: printable dos and don’ts per user type, still the best cheat sheets for designers.

Screen reader testing deserves its own line: free options cover every platform now, with NVDA on Windows, VoiceOver built into macOS and iOS, and TalkBack on Android. Fifteen minutes navigating your own checkout or contact form with a screen reader teaches more than any report.

Keeping Accessibility Tight with Claude Code or Codex CLI

The newest change in how I handle accessibility work: AI coding agents like Claude Code and the OpenAI Codex CLI have turned remediation from a periodic audit scramble into something that stays continuously tight, because the agent can run the scanners and fix the findings in the same loop.

The workflow that works for me:

  1. Scan from the terminal. The agent runs Pa11y or the axe-core CLI across the sitemap and reads the JSON results itself, so nothing is manually copied between a report and an editor.
  2. Fix in the codebase, not with an overlay. Pointed at the theme, the agent works through findings where they live: heading order, missing form labels, contrast tokens in the SCSS, focus states, ARIA attributes that should mostly be replaced with semantic HTML.
  3. Verify the fix, not just the diff. The agent re-runs the scanner after each change and confirms the finding is gone before moving to the next, which is the discipline human remediation passes tend to skip.
  4. Guard the future. A line in the project’s CLAUDE.md or AGENTS.md file like “every new template must pass axe-core with zero violations and be fully keyboard navigable” means every feature the agent builds afterward carries the requirement, and a Pa11y step in CI catches regressions from anyone else.

A one-liner from either tool makes the point:

claude -p "Run pa11y against http://localhost:8000/contact/, then fix every WCAG 2.2 AA violation it reports in the theme templates and re-run it to confirm zero issues."

The same caveat as the scanners applies: agents inherit automation’s blind spots, so the human pass with a screen reader and a keyboard stays on the checklist. What changes is that the mechanical majority of the work no longer waits for an annual audit.

Scanning tells you where you stand; it is not a legal defense. If you have received a demand letter, operate under Title II’s deadlines, or sell into the EU under the EAA, remediation belongs in the codebase with documentation of what was fixed and when, and your attorney drives the compliance posture. That codebase-level remediation, audits triaged into prioritized fixes and implemented in the theme rather than masked by an overlay widget, is exactly the work I do as an accessibility consultant, and overlay widgets deserve a warning: they are named in a growing share of accessibility lawsuits rather than preventing them.