ADA Compliance: The Website Lawsuit You Don't See Coming

A law firm in Florida sends a demand letter to a small business owner. The letter says their website isn't accessible to people with disabilities, violating the Americans with Disabilities Act. They can settle for $15,000 to $25,000 or face a federal lawsuit. The business owner had no idea there was a problem.

This is not a hypothetical. Web ADA compliance lawsuits have been filed by the thousands — against small businesses, restaurants, medical practices, retailers, and service companies. The numbers increase every year. Federal courts have broadly ruled that websites are "places of public accommodation" under the ADA, which means they must be accessible to people with visual, auditory, motor, and cognitive disabilities.

Most small business owners have never heard of web accessibility standards. Most website designers don't build for them by default. That gap is where the lawsuits live.

This Is Not a Large-Business Problem

If you've heard of ADA web compliance at all, you might have assumed it's something that applies to enterprise companies with legal teams and compliance departments. The opposite is true. Small businesses are frequently targeted precisely because they're less likely to have legal representation, less likely to fight, and more likely to settle quickly.

Serial litigants and their legal teams have automated the process of scanning websites for accessibility failures and sending demand letters. It costs them almost nothing to identify ten thousand non-compliant sites and send letters to all of them. A 5% settlement rate at $15,000 a letter is an extremely profitable operation.

I'm not saying this to alarm you unnecessarily. I'm saying it because the risk is real, it's growing, and it's entirely preventable if you address it before a letter shows up.

What Accessibility Actually Requires

The technical standard for web accessibility is WCAG — Web Content Accessibility Guidelines — published by the W3C. Courts and the Department of Justice have increasingly pointed to WCAG 2.1 Level AA compliance as the benchmark for ADA compliance on websites. It's a detailed technical specification, but the core requirements aren't mysterious — they're practical, and most of them are things any competent developer should be doing anyway.

Every image on your site needs alt text — a text description that screen readers can read aloud to visually impaired users. Not "image.jpg." Not blank. Not "photo." An actual description of what the image shows. A photo of your team doesn't need a novel — "Three dentists in white coats outside the office" is completely fine. A photo of your specials board needs the actual text from the board written out, because a screen reader user has no way to see what the board says otherwise.

Videos need captions — real captions, not auto-generated ones that mangle every third word. Forms need properly labeled fields — not just placeholder text that disappears when someone clicks, but actual accessible labels that persist and that screen readers can announce clearly. Color contrast between text and background must meet minimum ratios (4.5:1 for normal text). Buttons and links must be reachable and fully operable by keyboard alone, without a mouse, because many people with motor disabilities navigate entirely by keyboard.

The Content Hierarchy Problem

Screen readers navigate web pages using a content hierarchy built from heading tags — H1, H2, H3, and so on. A properly structured page has one H1 (the main topic), followed by H2s for major sections, followed by H3s for subsections within those sections. This structure is how a screen reader user understands the page without seeing it.

Most websites get this completely wrong. They use heading tags for visual styling — making text bigger or bolder — rather than for actual document structure. A page might have three H1s, no H2s, and H4s used for decorative subheadings. To a sighted user, the page looks fine. To a screen reader, it's a disorganized mess with no navigable structure.

Fixing heading hierarchy is a content and markup problem, not a design problem. It doesn't change how your page looks to sighted users at all. It takes a few hours to audit and fix correctly, and it makes a significant difference for both accessibility and SEO.

Why Good User Experience and Accessibility Are the Same Thing

Here's what people miss when they think of accessibility as a legal compliance burden: almost everything that makes a site accessible also makes it a better user experience for everyone. Proper color contrast helps people reading on phones in bright sunlight. Keyboard navigation helps power users who prefer not to use a mouse. Captions on videos help people watching in noisy environments or quiet offices.

The white space and clear visual structure that make pages easier to scan for sighted users also support users with cognitive disabilities who are overwhelmed by dense, cluttered layouts. Descriptive link text — "Download the pricing guide" instead of "Click here" — helps screen reader users and also helps everyone understand what they're about to do.

Accessibility done right isn't a layer of accommodations bolted onto a finished design. It's a design philosophy that produces better work for everyone. The businesses that approach it that way end up with both a more usable site and a legally defensible one.

What an Accessibility Overlay Won't Do For You

You've probably seen the little accessibility icon that appears in the corner of some websites — a stick figure with a circle. That's an accessibility overlay tool, sold by companies like AccessiBe and UserWay, that claims to make your site compliant automatically using AI and JavaScript for a monthly fee.

The accessibility community — the actual blind and low-vision users these tools are supposed to help — is overwhelmingly opposed to them. Major accessibility advocates have published open letters against them. The core problem is that a JavaScript layer can't fix structural HTML problems. It can't give meaningful alt text to images it doesn't understand. It can't fix a form that's fundamentally broken for assistive technology.

More importantly for your legal exposure: courts have not consistently accepted overlay compliance claims as a defense. Lawsuits have been filed and won against sites that had active overlay subscriptions. The overlay is not a solution. It's a false sense of security.

The Forms and Checkout Problem

Contact forms and checkout flows are where accessibility failures are most consequential — and most common. A form where the labels only appear as placeholder text inside the input fields looks clean and modern. It's also a nightmare for screen reader users and a common WCAG failure. When the placeholder disappears as someone starts typing, a user who's lost track of which field they're in has no way to know without navigating backwards.

Error messages are another frequent failure point. When someone submits a form incorrectly, the error message needs to be programmatically associated with the field that caused it — not just displayed visually somewhere nearby. A screen reader user needs to be told exactly what went wrong and on which field, not just shown a red border they can't see.

These aren't obscure edge cases. They're the core of how people interact with your website to become customers. Fixing them makes the form better for everyone — sighted users who tab through fields, mobile users who fill out forms with their thumbs, and assistive technology users alike.

How to Actually Get This Right

A proper accessibility audit runs your site against WCAG 2.1 AA criteria — both automated testing tools and human review, because automated tools catch about 30-40% of issues and the rest require human judgment. Tools like Axe, WAVE, and Google Lighthouse catch the obvious structural failures — missing alt text, poor contrast ratios, missing form labels. A human reviewer catches the things that require understanding context, intent, and the actual experience of navigating with a screen reader.

The fixes are mostly not expensive or complicated. Alt text is a content task — it takes time but not skill. Heading hierarchy is a markup task that usually takes a few hours to audit and correct across an entire site. Color contrast is a design task that often only requires adjusting a few values. Keyboard navigation is a development task that requires someone who knows what they're doing, but it's scoped work, not a rewrite.

We build ADA compliance into every site we build at Firebrand, and we offer accessibility audits for existing sites. If you've never had your site reviewed for accessibility, the time to do it is now — before a demand letter arrives and makes the conversation significantly more expensive than the fix would have been.