The 8 Accessibility Failures That Show Up in Every Demand Letter

ClearPath Team · 2026-08-01 · 7 min read

If you've ever read through a batch of ADA demand letters, you notice something fast: they're not creative. The same eight or so problems show up again and again, letter after letter, industry after industry. That's actually useful information. It means you can prioritize your fixes based on what testers and plaintiffs' firms actually find, not on guesswork.

Website accessibility lawsuits aren't slowing down either. Federal website accessibility filings rose 27% in 2025 to 3,117, the highest total since 2022, and website cases now make up 36% of all ADA Title III federal lawsuits. And that's just the lawsuits that get filed. The published count understates the real total because many demand letters settle privately. A lot of businesses never appear in any public tracker because they wrote a check before it got that far.

So what actually gets cited? Two different data sources tell slightly different stories, and both are worth knowing. Automated scans like the annual WebAIM Million, which tests the accessibility of the top one million homepages, tell you what's most common by raw volume. Demand letters, which usually come from a human tester using a screen reader plus an automated scan, tell you what's easiest to prove and demonstrate to a judge. Here's how the two line up.

1. Low color contrast

By sheer volume this is the most common failure on the web. Low contrast text, below the WCAG 2 AA thresholds, was found on 83.9% of home pages, the most commonly-detected accessibility issue, and each home page had 34 distinct instances of low-contrast text on average. It's rarely the headline complaint in a demand letter on its own, but it almost always shows up as supporting evidence.

Does a widget help in the moment? Yes. A contrast toggle that a visitor can switch on instantly makes hard-to-read text usable right then. This is one of the places ClearPath does what it's meant to do, installed with a single line of code, it gives visitors an on-page contrast adjustment among its 25 tools without anyone touching the CSS. What still needs a code fix? The actual color values in your CSS. A widget-driven override is a patch, not a redesign, and design teams should still aim for 4.5:1 contrast in the source styles.

2. Missing or useless alt text

Alt-text on images was missing on 55.5% of home pages, with an average of 11 images per page missing it, and even when alt text exists it's often junk. About 13% of images with alt text had questionable or repetitive descriptions, like "image," a file name, or text redundant with nearby content. This is the single most commonly cited item in demand letters, because it's trivial for a tester to show a judge a screenshot of a screen reader announcing "image1234.jpg" instead of a description.

Does a widget help? Partially. Some tools can generate a rough AI description for images that have no alt attribute at all, which gives a screen reader user something instead of nothing. ClearPath deliberately does not do this. Guessing what an image shows is how overlays earned their reputation, and a wrong description is worse than none, so the widget leaves your alt attributes alone and helps in the ways a browser-side tool honestly can, such as contrast, text size and reading support. What still needs a code fix? Real, context-aware alt text written by a person who understands what the image means on that page. No automated tool reliably knows that a photo is a "before" shot in a product comparison versus decoration.

3. Unlabelled form fields

Missing form labels sit at 51.0%, up from 48.2% the year before, making it one of the fastest growing failures on the list. Checkout forms, contact forms, and account signup fields are common targets because a demand letter can point to a specific, unusable transaction.

Does a widget help? Somewhat. It can improve visual cues like larger focus outlines and highlight the active field. What still needs a code fix? The actual label-to-input association in the HTML. A screen reader needs a proper <label> or aria-label tied to the field, and no overlay can safely invent that relationship for a form it didn't build.

4. Keyboard traps

These are less common in raw counts because they can't be caught by an automated scanner reliably. Keyboard accessibility remains one of the top barriers reported by screen reader users, with 68% encountering keyboard traps or inaccessible interfaces monthly. A true keyboard trap, where a user tabs into a widget and can't tab back out, is one of the most severe failures possible because it stops navigation cold.

Does a widget help? Not with a true trap. What still needs a code fix? Everything. The component's JavaScript has to release focus properly on Escape or Tab. This is a developer-only fix, full stop.

5. Menus and modals that can't be operated by keyboard

Custom dropdown menus, date pickers, and modal popups built with generic <div> elements instead of proper interactive tags are a frequent source of complaints. Keyboard accessibility failures represent approximately 15-20% of WCAG violations on typical websites, and combined with related focus management issues, keyboard problems affect a majority of accessibility-dependent users.

Does a widget help? A bit, mostly around visibility and tab order. What still needs a code fix? The component logic itself, including proper ARIA roles and keyboard event handlers so Enter, Space, and arrow keys behave the way assistive tech expects.

6. Missing focus indicators

Developers frequently strip the default focus outline for design reasons without replacing it. This is explicitly called out as a WCAG requirement: WCAG 2.1 AA requires visible focus indicators (2.4.7) and no keyboard traps (2.1.2).

Does a widget help? Yes, this is one area where a widget genuinely fixes the problem for the visitor. Injecting a clear, high-contrast focus style client-side solves the immediate visibility issue. What still needs a code fix? Ideally the CSS should never have removed the outline in the first place, but the widget-level fix here is a legitimate solution, not just a patch.

7. Video without captions

Less frequent on homepages simply because fewer homepages carry embedded video, but it's a near-automatic citation whenever a site relies on video for product demos, testimonials, or instructions.

Does a widget help? No. What still needs a code fix? Captions and transcripts have to be authored and attached to the video file or player. There's no way for a browser-side tool to generate accurate captions for existing video content after the fact.

8. Inaccessible PDFs

PDFs are often the last thing anyone thinks about, but menus, spec sheets, and application forms saved as untagged PDFs are a common target because screen readers simply can't parse them.

Does a widget help? No. What still needs a code fix? The PDF itself needs proper tagging, reading order, and alt text for images inside it, done in the source document, not on the webpage that links to it.

None of this means you need to fix all eight before lunch. Start with what's cited most often and easiest to prove: alt text, form labels, and contrast. Then work down through keyboard behavior, focus styles, captions, and PDFs. A demand letter rarely lists just one problem, it lists a pattern, and closing the gaps one at a time is how you get out of that pattern for good.