Posted by Huzefa Merchant — ML Engineer | linkedin.com/in/huzefa-merchant
Web accessibility lawsuits in the US crossed 5,000 in 2025 — a 37% increase from the year before.
Most developers hear that number and assume it's an enterprise problem. Big companies, big targets, big legal teams on both sides.
They're wrong. 67% of those lawsuits targeted companies with under $25 million in annual revenue. Small businesses. And increasingly, the agencies that built their websites.
This post is about what's actually happening, why developers and agencies are more exposed than they realise, and what the technically correct response looks like — before a demand letter arrives.
What Changed
The ADA — Americans with Disabilities Act — was written for physical spaces. Ramps, elevators, accessible bathrooms. Courts have since extended it to digital spaces, ruling that websites are "places of public accommodation" under the law.
That ruling opened the door. What changed recently is the economics on the plaintiff's side.
Plaintiffs' attorneys now use automated accessibility scanners that can audit thousands of websites in a single afternoon. They're not hand-picking targets anymore. They scan at scale, identify violations programmatically, and send demand letters in bulk. The cost of filing has dropped dramatically. The volume of cases has increased accordingly.
The most commonly cited violation in those demand letters? Missing or inadequate alt text on images.
Why alt text specifically? Because it takes a scanner approximately two seconds to detect. There's no ambiguity, no interpretation required. An image either has a descriptive alt attribute or it doesn't. Automated detection, automated violation, automated letter.
The Agency Problem Nobody Is Talking About
Here's where it gets uncomfortable for agencies.
When a web agency builds a site for a client, who owns the accessibility compliance after handoff?
In most agency contracts — nobody. It's not specified. Which means when a client receives a demand letter six months after launch pointing at 47 images with missing alt text, the first call they make is to their agency.
That call has one of two outcomes: the agency eats the remediation cost to protect the client relationship, or the client relationship ends badly. Neither is a good outcome for a small or mid-size agency running thin margins on project work.
The agencies most exposed are exactly the ones doing the most client work — WordPress shops, Shopify agencies, digital marketing firms that bundle website delivery. They're shipping sites constantly, accessibility is rarely part of the delivery checklist, and the liability accumulates silently across every client they've ever served.
What WCAG Actually Requires
WCAG — Web Content Accessibility Guidelines — is the technical standard courts reference when determining compliance. It sounds more complicated than it is for most websites.
The violations that appear in demand letters with regularity:
Alt text on images — Every non-decorative image needs a descriptive alt attribute. Not the filename. Not "image001." A genuine description of what the image shows. For a screen reader user, the alt text is the image.
Keyboard navigation — Every interactive element — buttons, links, form fields, dropdowns — must be reachable and operable using only the keyboard. Tab order should follow a logical flow. If you have divs with click handlers instead of semantic button elements, you have a keyboard navigation problem.
Color contrast — Text needs a minimum contrast ratio against its background. WCAG AA requires 4.5:1 for normal text. Tools like the Chrome DevTools accessibility panel flag this automatically.
Focus indicators — When a user navigates by keyboard, there should be a visible focus ring showing which element is currently active. Removing the default outline with outline: none and not replacing it is a violation.
Form labels — Every form input needs a properly associated label element. Placeholder text doesn't count.
Most of these are caught by free tools like WAVE or axe DevTools on a quick scan. The gap between knowing about violations and systematically fixing them across every client site is where agencies get stuck.
The Alt Text Problem at Scale
I want to spend more time on alt text specifically because it's both the highest-risk violation and the most operationally painful one for agencies doing client work at volume.
Consider a mid-size agency delivering 20 Shopify stores per year. Average store has 200 product images. That's 4,000 images per year that need descriptive, contextually accurate alt text written for them.
Current approaches in the industry:
Manual writing — Designers add alt text in Figma specs. Content editors enter it in the CMS. Developers hardcode it in React or HTML components. This works for a 20-image site. It doesn't work for a 200-image store, and it definitely doesn't work at agency scale where multiple sites are being delivered simultaneously.
Accessibility scanners — Tools like axe, WAVE, Lighthouse, and Siteimprove are excellent at detecting missing alt text. They flag every image without a proper alt attribute. What they don't do is generate the alt text. They identify the problem, they don't solve it.
Overlay widgets — Tools like accessiBe or UserWay add a JavaScript layer that makes superficial accessibility adjustments. They've been controversial — some have been named in lawsuits themselves, and they don't actually remediate the underlying HTML. They're a band-aid, not a fix.
The gap: there's no clean, production-ready workflow for bulk-generating accurate, WCAG-compliant alt text across an entire website during the delivery phase.
What The Technically Correct Workflow Looks Like
Whether you're handling one site or twenty, here's what an accessibility-conscious delivery process looks like:
During build:
- Use semantic HTML from the start —
<button>not<div onClick>,<nav>not<div class="nav">. Semantic HTML gives you keyboard navigation and ARIA landmarks for free. - Associate every form label with its input using
forandidattributes or by wrapping inputs in label elements. - Never remove the default focus outline without replacing it with something visible. Before handoff:
- Run WAVE or axe DevTools and work through every flagged violation.
- Audit every image for a descriptive alt attribute. For product images, alt text should describe what's in the image in enough detail that someone who can't see it understands what it shows.
- Check color contrast ratios on text-heavy sections, especially CTAs and navigation. In the client handoff document:
- Include an accessibility section noting what was addressed and what ongoing responsibilities the client has (new images added after launch need alt text too).
- This creates a paper trail that clearly delineates what the agency delivered versus what changed post-handoff.
The Practical Reality
Accessibility done properly isn't a one-afternoon task on a large site. It's a process that needs to be built into delivery from the start, not retrofitted at the end.
The good news: the most commonly litigated violations are also the most systematically addressable. Alt text, keyboard navigation, color contrast, and form labels account for the vast majority of demand letters. Fixing those four categories properly on a new build doesn't require becoming an accessibility expert. It requires making them part of the checklist.
The bad news: for agencies with existing client sites in the wild, the liability is already there. Every site delivered without proper alt text is a potential demand letter.
The right question for agency owners isn't "does this apply to us?"
It's "how many of our client sites are currently exposed, and what's the cost of finding out through a lawsuit versus finding out proactively?"
Resources Worth Bookmarking
- WAVE — wave.webaim.org — free browser-based scanner, visual feedback on violations
- axe DevTools — Chrome/Edge extension, developer-friendly violation reports
- WebAIM Contrast Checker — webaim.org/resources/contrastchecker — quick contrast ratio calculator
- WCAG Quick Reference — w3.org/WAI/WCAG21/quickref — the actual guidelines, filterable by level
I'm an ML Engineer currently researching how web agencies handle accessibility compliance at scale before building tooling for this problem. If you work at an agency and the alt text problem at volume resonates with you, I'd genuinely like to hear how your team handles it. Reach me on LinkedIn: linkedin.com/in/huzefa-merchant