How Lawsuit Firms Actually Test Your Website for ADA Violations

Most businesses think ADA web accessibility lawsuits start with a scanner. They don't. Plaintiff attorneys and the firms they work with have a specific testing methodology - and it has almost nothing in common with the automated tools you've probably tried.

After analyzing 20 real ADA lawsuits and the court complaints filed with them, we can show you exactly what these firms check, how they document it, and what ends up in the complaint your attorney receives.

Step 1: They Open the Accessibility Tree

Every web browser builds a parallel version of your page called the accessibility tree. It's what screen readers and assistive technology actually read - not the visual layout you see, but a structured list of every element's name, role, and state.

When a screen reader says "Submit, button" or "Email address, text field, required" - it's reading the accessibility tree. Plaintiff attorneys open Chrome DevTools, navigate to the Accessibility pane, and start clicking through your elements.

What they're looking for:

• Elements with no name. A button that shows up as "button" in the tree instead of "Add to Cart" or "Close menu" means screen reader users have no idea what it does.
• Elements with the wrong role. A <div> styled to look like a button but missing role="button" doesn't appear as interactive in the tree at all.
• Images with missing or meaningless alt text. alt="image" or alt="IMG_4392.jpg" shows up in complaints constantly. This is cited in 89% of ADA web accessibility cases.
• Form fields with no labels. A text input that shows up as "edit text" instead of "Email address" - the user has to guess what to type.

The accessibility tree inspection is documented with screenshots and pasted directly into the complaint. It's evidence.

Step 2: They Put the Mouse Away

This is where most automated scanners completely fall apart. Plaintiff attorneys test your entire site using only the keyboard.

They press Tab. Over and over. Through every page. They're checking:

• Can every interactive element be reached? If there's a button you can click with a mouse but can't reach with Tab, that's a violation. This happens constantly with custom dropdowns, image carousels, and JavaScript-powered widgets.
• Is there a visible focus indicator? When you Tab to a button, can you see where you are? Many sites remove the default focus outline for aesthetic reasons. That makes keyboard navigation impossible.
• Does the tab order make sense? If focus jumps from the header to the footer, skipping the main content, the page is unusable with a keyboard.
• Can you operate everything? Dropdowns should open with Enter or Space. Menus should close with Escape. Carousels should have pause controls. If you can't do it with keys, it's in the complaint.

Keyboard navigation failures appear in 61% of ADA web accessibility complaints. It's the second most common violation category, right behind missing alt text.

Step 3: They Test Real Interactions

Beyond basic Tab navigation, plaintiff attorneys test how your site behaves during actual user tasks. This is the part that no automated scanner can replicate:

Step 4: They Check Every Page Type

A common mistake businesses make: they test the homepage and think they're covered. Plaintiff attorneys test every distinct template on your site:

• Homepage
• Product/service pages
• Category/collection pages
• Cart and checkout
• Contact and form pages
• Search results
• Blog or content pages

Each template can have different accessibility issues. A product page might have an inaccessible image carousel. A category page might have broken filter controls. The checkout might have form fields without labels. They test them all.

What Ends Up in the Complaint

After testing, the firm compiles a list of specific violations with:

• The exact element and page where each violation occurs
• Screenshots of the accessibility tree showing the problem
• The WCAG 2.1 success criterion that was violated
• A description of the barrier it creates for disabled users

A typical complaint lists 5-15 specific violations. The firms that specialize in this - and there are a handful that file hundreds of cases per year - have this process down to a science. They can test a site and file a complaint in a matter of hours.

Why Automated Scanners Miss All of This

Automated scanners like WAVE, axe, and Lighthouse check your HTML source code for rule violations. They catch things like missing alt attributes, color contrast failures, and heading hierarchy issues. That's useful - but it's only about 30-40% of what plaintiff attorneys actually test.

Here's what automated scanners cannot do:

• Tab through your site and check if keyboard navigation works
• Open a dropdown and verify it responds to arrow keys and Escape
• Add an item to a cart and check if focus moves to the cart drawer
• Submit a form and verify errors are announced to screen readers
• Check if a popup traps focus or can be dismissed with the keyboard
• Judge whether an alt text is actually meaningful (not just present)

This is the gap. Businesses run a scanner, see a passing score, and believe they're protected. Meanwhile, every interaction on their site - the cart, the filters, the popups, the forms - is broken for keyboard and screen reader users. That's what shows up in the complaint.

How We Test (and Why It's the Same)

We built Covered Bridge specifically to test sites the way plaintiff attorneys do. Not because we're trying to be adversarial - but because if we can find what they'd find before they do, you're protected.

Our process:

1. Crawl your entire site and identify every distinct page template - homepage, product pages, category pages, cart, contact, etc.
2. Inspect the accessibility tree on every template - check names, roles, and states for every interactive element.
3. Tab through every page - verify keyboard reach, focus visibility, tab order, and keyboard operability for every interactive element.
4. Test real interactions - add to cart, open menus, submit forms, trigger popups, apply filters. Check focus management, screen reader announcements, and keyboard dismissal for each one.
5. Document everything - each finding includes the element, the page, the WCAG criterion, what's wrong, and how to fix it.

We've validated this process against 20 real ADA lawsuits. We compared what our testing found to what the plaintiff attorney cited in the actual court complaint. Across those 20 sites, we caught 80% of the items that appeared in the lawsuit complaints - and our process keeps improving.

The Bottom Line

If you're relying on an automated scanner to tell you whether your site is at risk, you're seeing less than half the picture. The issues that end up in complaints - keyboard navigation failures, broken focus management, inaccessible interactive widgets - are exactly the things automated tools can't test.

The only way to know what a lawsuit firm would find on your site is to test it the way they do.

Related Reading