Why Automated Scanners Miss Most Lawsuit Triggers

why automated scanners miss most ADA website lawsuit triggers

Most ADA website lawsuits start with some form of accessibility testing. Businesses often assume those tests rely entirely on automated scanning tools. They run a scanner, see a short list of errors, and assume the site is reasonably accessible.

That assumption is wrong.

Automated accessibility scanners are useful, but they only detect a portion of the barriers that lead to ADA website lawsuits. The gap between automated detection and real user experience is large. In many cases, the barriers described in lawsuits are the exact issues automated tools fail to identify.

Understanding that gap requires looking at how scanners work, how plaintiffs actually test websites, and why some accessibility problems require human judgment rather than automated detection.

how automated accessibility scanners actually work

Automated accessibility scanners analyze the structure of a web page and compare it against a set of rules. These rules come from the Web Content Accessibility Guidelines, commonly called WCAG.

The scanner reviews the HTML, CSS, and sometimes JavaScript on the page. It checks for specific conditions tied to accessibility standards.

Typical automated checks include:

Missing alt attributes on images.

Color contrast failures between text and background.

Empty links or buttons.

Missing form labels.

Improper heading structure.

Tools like WAVE, Axe, Lighthouse, and Siteimprove can run these checks in seconds.

The output usually appears as a list of errors and warnings.

That speed is useful for developers. A scanner can quickly highlight technical problems across dozens or hundreds of pages.

But the scanner only identifies issues that can be confirmed through code analysis. Many accessibility barriers are not visible in the code alone.

Those barriers require human testing.

what automated tools cannot understand

Accessibility guidelines often depend on context. Automated tools struggle with context.

Consider alt text for images.

A scanner can detect whether an image has an alt attribute. It cannot determine whether the description is meaningful.

For example:

An online store might display a product image of a red running shoe.

The alt text might read: “image.”

Technically, the alt attribute exists. The scanner reports no error.

A blind user using a screen reader receives no useful information about the product.

In a lawsuit, that image may be described as inaccessible.

The scanner sees a valid attribute. The user experiences a barrier.

This type of mismatch appears frequently in accessibility complaints.

automated tools cannot interpret page meaning

Many accessibility issues involve structure rather than isolated elements.

Headings illustrate the problem.

Screen reader users often navigate by headings. Proper heading structure allows them to move through a page quickly.

Automated scanners can detect whether heading tags exist. They cannot always determine whether the headings reflect the page structure.

A page might contain five headings, all marked as H1.

The scanner may flag it as a warning. It cannot determine whether the structure makes sense.

A screen reader user trying to navigate the page might hear a list of headings that provide no clear hierarchy.

The page technically passes some automated checks. The user experience remains confusing.

When plaintiffs describe accessibility barriers in lawsuits, they often describe this type of structural problem.

keyboard navigation failures rarely appear in scans

Keyboard accessibility is one of the most common barriers described in ADA website complaints.

Many users with mobility impairments rely on keyboard navigation rather than a mouse.

They move through a site using the Tab key.

Interactive elements must be reachable and usable through the keyboard.

Automated scanners struggle to detect these failures.

Consider a dropdown navigation menu that opens only when the mouse hovers over it.

The code for the menu exists. The scanner sees it.

But keyboard users cannot open the menu.

The scanner does not always detect that failure.

A manual test reveals it immediately.

A tester presses the Tab key. The menu never opens.

This type of issue appears repeatedly in accessibility lawsuits.

screen reader compatibility cannot be fully automated

Screen readers convert webpage content into speech or braille output.

Programs such as NVDA, JAWS, and VoiceOver interpret the page structure and read it aloud to the user.

Automated scanners cannot fully simulate how screen readers interpret content.

Some accessibility problems appear only during real screen reader use.

For example:

A button might be labeled visually with text but coded incorrectly.

A screen reader may announce it simply as “button.”

The user cannot determine what the button does.

The scanner may not detect the problem because the visual text exists on the page.

Only a manual screen reader test exposes the issue.

Plaintiffs who file ADA website lawsuits frequently use screen readers to document barriers.

Their testing process identifies problems automated tools miss.

dynamic content breaks automated assumptions

Modern websites rely heavily on JavaScript and dynamic content.

Menus expand. Forms update in real time. Product filters change search results without reloading the page.

Automated scanners often analyze only the static version of the page.

Dynamic interactions may never be evaluated.

A common example appears in e-commerce filters.

A clothing store may allow users to filter products by size, color, and price.

The filtering controls might appear visually as buttons.

If those buttons lack proper ARIA attributes, screen readers cannot interpret them.

The scanner may analyze the page before the filter panel opens.

The accessibility problem remains hidden.

Manual testing reveals the issue when the user attempts to apply a filter.

automated tools miss inaccessible PDFs and documents

Many business websites host downloadable documents.

Restaurant menus, patient intake forms, insurance policies, and brochures often appear as PDFs.

Accessibility scanners typically analyze web pages, not attached documents.

An automated scan may show few accessibility issues while the site contains dozens of inaccessible PDFs.

A blind user opening a scanned PDF receives no readable text.

The screen reader may announce only “graphic.”

This problem appears regularly in ADA website lawsuits involving restaurants, government offices, and healthcare providers.

The accessibility barrier exists in the document itself, not the webpage code.

Scanners rarely identify it.

accessibility lawsuits focus on user experience

Automated scanners measure technical compliance.

ADA lawsuits focus on whether a user could complete a task.

That difference explains why scanners miss many lawsuit triggers.

A lawsuit complaint often describes actions taken by the plaintiff.

Examples include:

Attempting to schedule an appointment.

Attempting to order food.

Attempting to view a restaurant menu.

Attempting to purchase a product.

The complaint then describes the barrier encountered during the attempt.

The barrier may involve multiple accessibility failures interacting together.

Automated tools examine isolated code issues. They do not evaluate task completion.

This gap is why a website can pass an automated scan and still trigger a lawsuit.

a real-world example from a retail website

In 2022 a blind user attempted to purchase clothing from an online retailer.

The product pages appeared functional at first.

Images had alt attributes. Buttons contained text labels.

Automated scanners reported relatively few errors.

But the checkout process created a problem.

The payment form used custom input fields created with JavaScript.

The visual labels appeared above the fields.

The code did not associate those labels with the inputs.

When the screen reader reached the form, it announced:

“edit text.”

No field description.

The user could not determine which field required a name, address, or credit card number.

The automated scanner did not flag the issue because the labels existed visually.

The barrier appeared only during screen reader testing.

The problem later appeared in an ADA accessibility complaint.

automated scanners generate false positives too

Automated tools not only miss problems. They sometimes flag issues that are not real accessibility barriers.

Accessibility professionals often call these false positives.

For example:

Decorative images should contain empty alt attributes so screen readers ignore them.

Some scanners flag these images as missing descriptions.

Developers unfamiliar with accessibility rules may attempt to “fix” the issue by adding unnecessary alt text.

The result creates noise for screen reader users.

The scanner reports improvement. The user experience becomes worse.

False positives can waste developer time and create confusion about what actually needs to be fixed.

Manual review is required to interpret scanner results correctly.

the percentage problem

Accessibility researchers frequently estimate that automated scanners detect between 25 percent and 40 percent of WCAG accessibility failures.

The exact number varies by study and testing method.

But the pattern remains consistent.

Automated tools detect only a fraction of accessibility problems.

The remaining issues require human evaluation.

Accessibility lawsuits often describe those undetected barriers.

how plaintiffs actually test websites

Plaintiffs involved in ADA website litigation often follow a predictable testing process.

First, they run an automated accessibility scan.

The scan identifies obvious issues such as missing alt attributes or color contrast failures.

Next, the tester manually navigates the site.

Screen readers play a central role in this testing.

The tester may attempt to perform tasks such as ordering a product or submitting a form.

During this process the tester records accessibility barriers encountered.

These barriers become the basis for the complaint.

The documentation may include:

Screen reader output.

Screenshots.

Descriptions of failed interactions.

The complaint describes the user experience rather than the automated report.

This approach explains why automated scan results rarely match the barriers described in lawsuits.

why overlays do not solve the scanner gap

Some businesses install accessibility overlays after discovering accessibility problems.

Overlays add a widget that allows users to adjust text size, contrast, or spacing.

These tools operate after the page loads.

They do not repair the underlying HTML structure.

If a form field lacks a proper label, the overlay does not add one.

If keyboard navigation fails, the overlay rarely fixes the problem.

Because of this limitation, overlays do not close the gap between automated scans and real accessibility testing.

The barriers remain visible during manual testing.

Several ADA lawsuits have mentioned overlays that were present on the website but did not resolve accessibility barriers.

why developers rely too heavily on scanners

Automated scanners are attractive because they are fast.

A full site scan can take less than a minute.

The results appear in a simple report.

Developers can run the tool during development and fix obvious issues quickly.

The convenience leads to overreliance.

Some teams assume that passing an automated scan means the site is accessible.

Accessibility professionals generally treat scanners as the first step rather than the final step.

Manual testing is required to confirm real accessibility.

Without manual testing, the majority of accessibility issues remain undiscovered.

accessibility requires multiple testing methods

A reliable accessibility evaluation usually combines several approaches.

Automated scanning identifies basic technical issues.

Manual keyboard testing confirms navigation functionality.

Screen reader testing evaluates how assistive technologies interpret the page.

Color contrast tools verify visual readability.

Document reviews identify inaccessible PDFs or attachments.

Each method reveals different categories of accessibility problems.

No single tool covers everything.

Automated scanners are useful but incomplete.

the economic reality behind accessibility lawsuits

Accessibility litigation often focuses on websites with widespread barriers.

Plaintiffs do not need to document every accessibility failure.

They need to demonstrate that the barriers prevented access to the goods or services offered.

Manual testing quickly reveals those barriers.

Automated scans may support the complaint but rarely define it.

This difference explains why companies sometimes feel surprised by lawsuits.

Their scanner report showed only a handful of issues.

The manual test revealed the real problems.

the gap between technical compliance and real accessibility

Accessibility guidelines exist to improve usability for people with disabilities.

Automated tools measure whether certain technical conditions are met.

Real accessibility depends on how users interact with the site.

The gap between those two perspectives explains why automated scanners miss many lawsuit triggers.

Scanners evaluate code patterns.

Users experience navigation, interaction, and meaning.

Accessibility problems often appear in the interaction layer.

That layer cannot be evaluated by automated analysis alone.