Is my website ADA compliant? How to actually check

Short answer: no government agency certifies websites as "ADA compliant," so nobody can sell you a badge that settles the question. The practical test is whether your site meets WCAG, the standard the Department of Justice points to in its web guidance. You can get a first honest read on that in about 30 minutes with free tools, and I'll show you exactly how.

To prove the point, I ran a scan while writing this post. I pointed axe-core, the open source accessibility engine, at a demo page the W3C keeps intentionally broken for training purposes. It came back in a few seconds with seven distinct violation types, including 33 images with no alt text and a form control with no name. The full, unedited output is further down.

That's the shape of a real first check. Not a certificate, not a score out of 100. A list of specific failures on specific elements, which you can then fix. (Quick note before we go further: I'm a founder who builds accessibility tooling, not a lawyer, and none of this is legal advice.)

What "ADA compliant" actually means for a website

The Americans with Disabilities Act is a civil rights law from 1990. It says nothing about HTML, because HTML barely existed. There's no clause you can read that says "your checkout page must do X," and there's no formal certification program. Anyone offering to "certify" your site as ADA compliant is selling you their own opinion with a ribbon on it.

What exists instead:

• DOJ guidance. The Department of Justice has said for years that the ADA applies to websites of businesses open to the public, and its guidance on web accessibility points to the Web Content Accessibility Guidelines (WCAG) as the reference for what accessible means.
• A binding rule for governments. In April 2024, the DOJ published a rule under Title II requiring state and local governments to make web content and mobile apps meet WCAG 2.1 Level AA. The compliance deadlines were pushed back a year by an interim final rule in April 2026: April 26, 2027 for larger entities, April 26, 2028 for smaller ones and special districts.
• Case law. For private businesses there's no equivalent regulation yet, but plaintiffs' complaints and settlement agreements almost always use WCAG as the yardstick.

So when someone asks "is my website ADA compliant," the answerable version of that question is: "does my website conform to WCAG 2.1 AA, and can I show my work?" That's what you should check.

Three free tools for a first check

You don't need to buy anything for a first pass. Three tools, all free:

WAVE by WebAIM. Paste a URL or use the browser extension, and it overlays icons directly on your page: red for errors, yellow for things a human should review. It's the most visual of the three, which makes it great for showing a non-developer what's wrong.

axe DevTools by Deque. A browser extension that runs the axe-core engine inside Chrome or Firefox DevTools. This is the same engine most paid scanners run under the hood, so the results translate directly to what an auditor or a scanning platform will find.

Lighthouse, built into Chrome. Open DevTools, pick the Lighthouse tab, run the Accessibility category. It also uses axe-core rules and gives you a 0 to 100 score. Useful as a trend line, dangerous as a finish line. A 100 does not mean your site is accessible; it means the automated checks passed.

Run all three on your homepage and your highest-stakes page (checkout, signup, contact form). They overlap heavily, but each surfaces the findings differently.

What a real scan looks like

Here's the scan I mentioned at the top. I ran axe-core through Playwright against the W3C's "Before" demo page, a fake site the WAI team built to be deliberately inaccessible:

node --input-type=module -e "
import { chromium } from 'playwright';
import AxeBuilder from '@axe-core/playwright';
const browser = await chromium.launch();
const context = await browser.newContext();
const page = await context.newPage();
await page.goto('https://www.w3.org/WAI/demos/bad/before/home.html');
const results = await new AxeBuilder({ page }).analyze();
console.log(JSON.stringify(results.violations.map(v =>
  ({ id: v.id, impact: v.impact, nodes: v.nodes.length, help: v.help })), null, 2));
await browser.close();"

The actual output, unedited:

[
  {
    "id": "color-contrast",
    "impact": "serious",
    "nodes": 2,
    "help": "Elements must meet minimum color contrast ratio thresholds"
  },
  {
    "id": "html-has-lang",
    "impact": "serious",
    "nodes": 1,
    "help": "<html> element must have a lang attribute"
  },
  {
    "id": "image-alt",
    "impact": "critical",
    "nodes": 33,
    "help": "Images must have alternative text"
  },
  {
    "id": "landmark-one-main",
    "impact": "moderate",
    "nodes": 1,
    "help": "Document should have one main landmark"
  },
  {
    "id": "link-name",
    "impact": "serious",
    "nodes": 7,
    "help": "Links must have discernible text"
  },
  {
    "id": "region",
    "impact": "moderate",
    "nodes": 22,
    "help": "All page content should be contained by landmarks"
  },
  {
    "id": "select-name",
    "impact": "critical",
    "nodes": 1,
    "help": "Select element must have an accessible name"
  }
]

What three of those actually mean, in plain English:

• image-alt (critical, 33 elements). Thirty-three images have no alt text. A screen reader user hits each one and hears either nothing or a useless filename like "img_0234.jpg". If any of those images carry meaning (a product photo, a chart, a button), that meaning is simply gone for them.
• link-name (serious, 7 elements). Seven links have no discernible text, usually an icon or image link with no label. Screen reader users often navigate by pulling up a list of every link on the page. These seven show up as "link, link, link." Where do they go? No way to know without clicking.
• html-has-lang (serious). The page never declares its language. Screen readers use that attribute to pick pronunciation rules, so English text can get read with the wrong voice entirely. The fix is one attribute on one tag.

Notice how concrete this is. Every finding names a rule, an impact level, and the exact elements. This is why I'd rather you run a real scan than stare at a compliance checklist.

What automated scans catch, and what they miss

Automated tools are genuinely good at a specific slice of WCAG: missing alt attributes, contrast ratios, unlabeled form fields, missing document structure. But they can't judge everything, and the coverage numbers are worth knowing before you celebrate a clean scan.

When the UK's Government Digital Service tested 13 automated tools against 142 known barriers, the best tool caught about 40% of them and the worst caught 13%. Deque's own analysis of real audit data puts axe's coverage higher, at about 57% of issues by volume, because the failures machines can detect happen to be the most common ones. A fair summary: automation finds roughly a third to a half of your real problems.

What it structurally cannot judge:

• Keyboard traps and focus order. A scanner can't tell that tabbing into your date picker means never tabbing out, or that focus jumps from the header to the footer and back.
• Whether alt text is any good. alt="image" passes the automated check. It's still useless.
• Whether the experience makes sense. Does the error message actually tell you which field failed? Does the modal announce itself? Only a human, ideally one using a screen reader, can answer that.

So the honest workflow is: automate the detectable half continuously, and put human eyes (yours, then eventually a professional auditor's) on the rest.

Check your site in 30 minutes

Here's the first pass I'd run on any site, no budget required:

1. Minutes 0 to 5: WAVE your two most important pages. Homepage plus your money page. Count the red errors. Screenshot the results so you have a baseline.
2. Minutes 5 to 10: run axe DevTools on the same pages. Note the critical and serious findings. These two impact levels are where real users get blocked.
3. Minutes 10 to 15: unplug your mouse. Tab through your key flow, keyboard only. Can you see where focus is at all times? Can you reach and operate every menu, button, and form? Can you get out of every widget you get into? This one test catches problems no scanner ever will.
4. Minutes 15 to 20: zoom to 200%. WCAG expects your content to survive it. Look for text that clips, overlaps, or disappears.
5. Minutes 20 to 25: check your forms. Click each field's label; does the cursor land in the field? Submit an empty form; does the error clearly say what's wrong and where?
6. Minutes 25 to 30: write it down. A dated list of findings is the start of a paper trail, and a documented remediation effort is worth a lot more than a clean-looking homepage if a demand letter ever shows up.

Will this make you compliant? No, and be suspicious of anyone who says their tool will. What it does is tell you honestly where you stand, which is the thing "am I compliant?" is really asking.

FAQ

Is there an official ADA certification for websites?

No. Neither the DOJ nor any other agency issues one. The DOJ's web guidance points to WCAG as the reference standard, and the Title II rule makes WCAG 2.1 AA legally binding for state and local governments. Anything sold as a "certificate" is a vendor's opinion, not a legal status.

Which WCAG version should I test against?

WCAG 2.1 Level AA is the pragmatic target. It's what the DOJ's Title II rule adopts and what most lawsuits and procurement checklists reference. WCAG 2.2 adds a handful of useful criteria on top, and meeting it doesn't hurt, but 2.1 AA is the baseline that matters in the US today.

My Lighthouse accessibility score is 100. Am I done?

No. Lighthouse runs automated checks only, and automated checks catch roughly a third to a half of real issues. A 100 means you've cleared the machine-detectable layer. Keyboard flow, focus management, and alt text quality still need a human. That said, a 100 is a genuinely good start; most sites aren't close.

How often should I re-check?

Every deploy, realistically. Accessibility regressions ship the same way bugs do: a new component, a redesigned form, a marketing page built in a hurry. A site that scanned clean in January can fail in March. That's the argument for making scanning continuous instead of a once-a-year event, which I've written more about on our accessibility page.

If you want the 30-minute check without the setup, we built a free WCAG scan that runs the same axe-core engine you saw above against any URL and gives you the findings, element by element. Run it, keep the report, and you'll know exactly where you stand.