Is My Website ADA Compliant? How to Actually Check

You've heard about ADA web accessibility lawsuits. You know 8,600+ were filed in 2025. You want to know if your site is at risk. So you search for "is my website ADA compliant" and find a dozen free checker tools.

Here's the problem: most of those tools check the wrong things. They scan your HTML for rule violations - missing alt text, color contrast ratios, heading structure. That's useful, but it's not what plaintiff attorneys actually test. And it's not what ends up in lawsuit complaints.

What Automated Scanners Check vs. What Attorneys Check

Automated scanners catch about 30-40% of WCAG issues. The rest require testing actual behavior - can you tab through every interactive element? Does the screen reader announce what's happening when you open a dropdown? Does focus go to the right place after submitting a form?

This is the gap that gets businesses sued. Your site passes an automated scan. You think you're covered. A plaintiff attorney tabs through your checkout flow and can't complete a purchase with the keyboard. That's a complaint.

The Two Things That Actually Matter

If you want to know whether a plaintiff attorney would find issues on your site, you need to check two things:

1. The Accessibility Tree

Every browser builds an accessibility tree from your HTML - a parallel structure that assistive technology reads instead of the visual page. It contains the name, role, and state of every element. When a screen reader says "Submit button" or "Email, text field, required" - it's reading the accessibility tree.

If an element is missing from the tree, it doesn't exist for screen reader users. If it has the wrong name or role, it's misleading. Plaintiff attorneys inspect the accessibility tree directly - it's in the complaint as evidence.

You can see your site's accessibility tree right now: open Chrome DevTools, go to the Elements panel, and look for the "Accessibility" pane. Click through your interactive elements and check if they have meaningful names and correct roles.

2. Keyboard Navigation

Put your mouse away. Press Tab. Can you reach every link, button, form field, and interactive widget? Can you see where you are (is there a visible focus indicator)? Can you operate everything with Enter, Space, and arrow keys?

Keyboard navigation failures are cited in 61% of ADA web accessibility complaints. It's the second most common violation after missing alt text. And it's something automated scanners largely can't test - they can check if elements are technically focusable, but not whether the tab order makes sense or whether custom widgets actually work.

A Quick Self-Check (5 Minutes)

You can do a rough assessment right now. This won't catch everything, but it will tell you if you have obvious problems:

1. Tab through your homepage. Start at the top. Press Tab repeatedly. Can you reach every link, button, and form field? Can you always see where you are? If focus disappears or gets trapped, that's a violation.
2. Check your images. Right-click any image, Inspect, look for the alt attribute. If it's empty or missing on images that convey meaning, that's the #1 cited violation (89% of complaints).
3. Click inside a form field, then check DevTools. In the Accessibility pane, does the field have a meaningful name? "Edit text" is bad. "Email address" is good.
4. Open any dropdown or modal. Does focus move into it? Can you navigate inside it with the keyboard? Can you close it with Escape? If not, that's a violation.
5. Squint at your text. If any text is hard to read against its background, it probably fails contrast requirements.

Why Free Scanners Aren't Enough

Free tools like WAVE, axe, and Lighthouse are useful for catching HTML-level issues. Use them. But understand their limits:

• They scan one page at a time. Your site has dozens or hundreds of pages.
• They can't test keyboard behavior - only whether elements are technically focusable in the HTML.
• They can't tell if an alt text is meaningful - only whether it exists. alt="image" passes the scan but fails in court.
• They don't test dynamic interactions - what happens when you open a menu, submit a form, or trigger an error.
• They give you a snapshot, not ongoing monitoring. Your site changes constantly.

A passing score on a free scanner does not mean you're protected. It means you've addressed 30-40% of what a plaintiff attorney would look at.

What "ADA Compliant" Actually Means

There's no official "ADA compliant" certification for websites. Nobody can stamp your site as "compliant" - the FTC fined accessiBe $1 million for making that claim. What you can do is meet WCAG 2.1 Level AA - the technical standard that courts and the DOJ use as the benchmark.

WCAG 2.1 AA has specific, testable criteria. Meeting them means you've addressed the issues that show up in complaints. It doesn't make you immune to lawsuits (nothing does), but it gives you a strong defense and dramatically reduces your risk.

The Right Way to Check

If you want to know what a plaintiff attorney would actually find on your site, you need testing that mirrors their methodology:

• Accessibility tree inspection - checking that every element has correct names, roles, and states
• Keyboard navigation testing - tabbing through every page, operating every widget, verifying focus management
• Every page, not just the homepage - violations on any page can trigger a complaint
• Ongoing, not one-time - because your website changes and new violations appear with every update

Related Reading