A Client Got Sued Over Accessibility. Who's Liable?

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

You built the site three years ago. The client hasn't called in months. Then an email shows up: "We got a demand letter about accessibility. Your team built this, right?" That question is the whole problem in one sentence, and how you answer it depends entirely on paperwork you probably signed a long time ago and haven't looked at since.

This is the conversation every agency and freelancer eventually has. Let's get specific about who actually owes what, what your contract needs to say before the next project starts, and how to turn "can you fix this" into paid work instead of a favor.

Who the law actually names first

Under Title III of the ADA, the legal obligation attaches to the business offering goods or services to the public, not the company that coded the site. Title III risk typically follows the business offering the goods or services, not the agency building the site, since the claim is about access to what the business provides online, and the owner is the party most likely to be named first. If your client runs a restaurant, a clinic, or an online store, they're the ones being sued, not you.

That's the good news for agencies. Here's the catch: it doesn't mean agencies are safe. The piece that often gets missed is the next question: who can still be exposed even if they are not named first, and that is where vendor risk tends to show up through contract language, representations, and downstream claims after the client is sued. In other words, the plaintiff's attorney isn't coming after you directly. Your own client might, once their legal bill arrives.

There's a narrower but real exception too. When the client is a government entity or receives public funding, false claims laws come into play. The Federal government and many states have false claims laws that make lies or misstatements in government contracts illegal and subject to criminal or civil liability, and often these lawsuits can be brought by private citizens affected by that misstatement. A California case bears this out directly: a blind citizen sued a web developer under the Unruh Civil Rights Act, California's False Claims Act, and Title II of the ADA because the developer falsely promised the state it would make a campground reservation website accessible. If you ever promise a public-sector client that a site "will be ADA compliant," write that sentence very carefully.

What contracts usually say, and what they leave out

Most web design agreements say nothing about accessibility at all. That silence isn't neutral, and it doesn't automatically protect you. If a client wants to share responsibility or avoid it altogether, they'll need to point to your service agreement to show the work was expressly excluded from scope, and without a specific and express undertaking to include ADA compliance services, a client will have a much tougher time shifting liability onto the agency.

So silence tends to favor the agency, but only if you can prove the silence was intentional and not an oversight. Vague scope language, a line in your proposal about "modern, user-friendly design," or a sales call where someone said "don't worry, we build clean sites" can all be read against you later.

What a contract should actually say:

• Name accessibility explicitly. State whether WCAG conformance is in scope, out of scope, or a separate paid add-on. Don't leave it implied.
• Avoid absolute promises. One legal guide is blunt about this: in most cases an agency shouldn't guarantee that its work will cause the client to be in compliance with the ADA, because the agency isn't a law firm and can't advise on how regulations apply or how best to comply.
• Keep the limitation of liability clause intact. An agency should avoid carving out ADA or WCAG compliance exceptions to its limitation of liability clause.
• Put a maintenance clock on it. Accessibility isn't a one-time deliverable. Content edits, new plugins, and redesigns can all reintroduce barriers after launch. Say who's responsible for checking after go-live.

Why "we built it to your budget" doesn't transfer liability

This is the excuse that never holds up: "The client only paid for a 5-page brochure site, they didn't ask for accessibility." Courts and plaintiffs don't care what the invoice said. The business still offered goods or services online, and that's what triggers the obligation, regardless of what tier of package they bought.

Budget constraints are a business decision your client made. They are not a legal shield, and if your contract didn't document that accessibility was explicitly discussed and declined, "we built what they paid for" reads as "we didn't raise it," which is worse for you, not better.

Pricing it instead of assuming it

The fix is simple to describe and annoying to actually do: stop bundling accessibility into "quality" and start pricing it as a line item. In every proposal, include a short accessibility section that states plainly:

• Whether the build targets WCAG 2.2 AA conformance, and at what confidence level (a full audit versus a best-effort build)
• What's included: semantic markup, color contrast checks, keyboard testing, form labeling, alt text for new content
• What's excluded: third-party embeds, PDFs the client uploads later, content added after launch through their CMS
• Who owns ongoing monitoring once the site goes live

Clients rarely object to this once you frame it as scope, not upsell. And if they decline the accessibility line item, you now have a signed record that it was offered and turned down. That single paragraph is worth more than any disclaimer buried in your terms of service. Some agencies list a widget like ClearPath as an optional line item here too, since it's a one line install that gives clients an easy way to offer adjustment tools while the deeper WCAG work is scoped separately.

The awkward call when a past client gets sued

It happens. A client from two years ago calls, forwards a demand letter, and asks what you're going to do about it. Handle it like this:

1. Don't admit fault on the call. Say you'll review the contract and the site, and get back to them. Anything you say in the moment can get quoted back to you later.
2. Pull the original SOW and any emails about scope. This is where the accessibility clause you wrote (or didn't) actually matters.
3. Separate "what we're contractually obligated to do" from "what we're willing to do for the relationship." Those can be different things, and it's fine to say so.
4. Quote the remediation as a new project. This is not a warranty callback. It's new, paid, scoped work with its own timeline.

Legal counsel that works with agencies on exactly this scenario recommends the same thing: have the accessibility conversation up front so everyone is clear about responsibility before the site is built, not after a demand letter or lawsuit arrives. The call is a lot less awkward when you've already had that conversation once, in writing, at the start.

Turning remediation into paid work

The instinct when a past client is in trouble is to fix it for free out of guilt or fear of a bad review. Resist that. A demand letter is leverage for you, not just a threat to them. The client needs work done fast, under pressure, with a deadline attached. That's a paid retainer, not a favor.

Structure it as three tiers if it helps the conversation: an audit against WCAG 2.2 to document current gaps, code-level remediation for the items that need markup or structural changes, and a visitor-facing layer for the adjustments that don't require touching the codebase. Selling remediation as tiered, scoped work also gives you a natural place to introduce a tool like ClearPath as part of the plan, rather than pretending a widget alone solves the letter.

Be honest: no tool removes liability

Every accessibility overlay company on the internet will tell you their tool makes the problem go away. It doesn't, and any agency that repeats that claim to a client is setting up the same call you're trying to avoid. No one can guarantee your website is 100% ADA compliant and accessible in all instances, at all times, and in all possible ways, and nobody can guarantee compliance under current ADA law. That's true of any vendor, including us.

The agencies that come out ahead here aren't the ones with the cleanest code, they're the ones with the cleanest paperwork. Name accessibility in every proposal, keep your limitation of liability intact, and when the call comes, treat remediation as billable work instead of an apology. That's the difference between a bad afternoon and a bad year.