Accessibility is now a standard part of online business. That is progress. It also brings a harder question: what happens when the work gets challenged? When a demand letter or lawsuit shows up, who is responsible for web accessibility in a legal sense—the agency managing the site, or the organization that owns it?
In most U.S. disputes, the website owner is usually the first party named. The Americans with Disabilities Act (ADA) generally places the duty on the covered entity providing the goods, services, or programs, even when access happens through a website or app.
But that does not mean agencies and contractors are not exposed. Vendors often enter these disputes through contract language, representations, and third-party claims after the client is sued. In some public-sector contexts, particularly in California, plaintiffs have shown a willingness to pull contractors closer to the center of the dispute.
This article breaks down who gets held accountable, why vendors still face risk, and how courts tend to evaluate who is responsible for web accessibility once a claim is active.
Who Is Responsible for Web Accessibility Under the ADA?
When people ask, “Who is legally responsible?” they are often asking more than one question. One is procedural: who gets named first. The other is substantive: who the law places the duty on.
In most disputes, the first answer is the website owner—the organization offering the public-facing service. The second answer typically points to the same place. The ADA generally ties the obligation to the covered entity providing the goods, services, or programs, including when access happens through a website or app. DOJ guidance is aimed at public-facing businesses and at state and local governments, reinforcing that expectation.
For private-sector teams, this is the practical baseline. Title III risk typically follows the business offering the goods or services, not the agency building the site. The claim is about access to what the business provides online, so the owner is the party most likely to be named first.
Public-sector requirements can be more prescriptive, but the structure stays similar. The obligation attaches to the entity delivering the program or service.
The piece that often gets missed is the next question: who can still be exposed even if they are not named first. That is where vendor risk tends to show up—through contract language, representations, and downstream claims after the client is sued.
That’s why the key question becomes not only who is named first, but how the record determines who is responsible for web accessibility once a claim is active.
How Vendors Get Pulled In
Even when the website owner is the primary legal target, vendors can still get pulled in. Most of the time, it happens through three documentation-driven channels.
Contract Allocation
The agreement can shape the dispute before it starts. Accessibility scope, testing language, warranties, exclusions, and post-launch responsibility influence whether the vendor is treated as having assumed obligations—or whether the client remains clearly responsible for web accessibility after launch.
Third-Party Claims
After an owner is sued, it may try to shift costs to a platform, developer, or agency through indemnity, contribution, breach of contract, or misrepresentation theories. At that point, the question is not “Is this a Title III claim?” It is “What did the vendor promise, and can the client point to it?” That record can influence how a court views who is responsible for web accessibility obligations in practice.
Evidence and Expectations
Proposals, SOWs, marketing pages, emails, and tickets become the record of what was represented, scoped, and delivered. In a dispute, that record can carry as much weight as the implementation itself—and it can shape arguments about who is responsible for web accessibility when expectations and outcomes don’t match.
When an Access Claim Becomes a Contract Dispute
A recent example shows how quickly an accessibility dispute can shift into contract territory. In Herrera v. Grove Bay Hospitality Group, LLC, after an accessibility claim, a restaurant tried to bring its website platform into the case through a third-party complaint. The court dismissed it, relying heavily on the platform’s terms, including disclaimers of ADA compliance obligations and warranties that the services would satisfy legal requirements.
Two takeaways for agencies and platforms:
- Adding a vendor is not automatic. A viable legal theory still has to survive the contract language.
- Courts focus on what the vendor actually assumed. If sales or scope language implies “we guarantee compliance,” you may be taking on obligations your delivery model cannot reliably support.
That is why “ADA compliant” is a risky marketing phrase unless it is tied to a defined benchmark, a defined scope, and defensible evidence. Otherwise, it can muddy who is responsible for web accessibility when a claim tests the work.
Responsibility Depends on the Legal Pathway
A useful way to answer the responsibility question is to separate the underlying access claim from vendor exposure.
The underlying ADA-style access claim typically targets the entity providing the service, the owner or operator. Vendor exposure usually flows from contracts and promises—and in some contexts, from specialized theories tied to government contracting and representations.
That distinction matters because it changes what “responsible” means in practice. Vendors do not control whether the ADA applies to a client. You are deciding what you will commit to in writing, what you will represent, and what you can prove you delivered—especially if you later need to show how responsibility was assigned and who is responsible for web accessibility in each phase of the work.
Define Responsibility in Contracts
The most effective way to avoid conflict is to define responsibility early and document it in the agreement. Disputes rarely come from bad intent. They come from unclear scope and assumptions that never made it into writing.
From a risk standpoint, agencies and vendors tend to get squeezed in two predictable ways. Both usually come back to how accessibility is described in the agreement and how the agreement answers who is responsible for web accessibility over time.
Two Contract Traps
A Promise Without a Standard
If you say “ADA compliant” without defining the benchmark, you invite a fight over what you meant. If you promise accessibility outcomes, tie them to a named standard and a defined target.
A Standard Without Coverage
Even when WCAG is named, disputes flare up when the scope is unclear. The question becomes what WCAG applies to in this engagement. For example, does it include PDFs, third-party tools, user-generated content, post-launch edits, or new templates and features?
In disputes, this often turns on whether the vendor assumed a duty, and whether the agreement supports the boundaries the vendor intended. That record often becomes the practical answer to who is responsible for web accessibility when the site evolves beyond the original scope.
Websites change. Multiple parties touch the system. Your agreement should reflect that reality instead of treating accessibility as a one-time deliverable.
What to Clarify in Contracts and SOWs
Strong agreements spell out the standard, the testing approach, the boundaries, and the handoff so both sides can execute the work and defend what was done if questions come up later—especially when someone asks who is responsible for web accessibility after launch.
Standard
Identify what accessibility standard is being followed, for example, WCAG 2.1 AA, and clarify whether it applies to all templates, components, and flows, or only to defined pages.
Testing and Evidence
State what methods are included—automated, manual, and assistive tech review—and what proof is delivered, such as issue logs, remediation notes, sign-off steps, and before-and-after documentation.
Boundaries
Spell out what is out of scope, such as third-party tools, PDFs, legacy pages, and user-generated content. If content remediation is included, define which content types or volumes are covered, so it is not left to interpretation later.
Post-Launch Ownership
Clarify who owns accessibility after launch, what that means in practice, and how post-launch edits, new features, and template changes are handled. This is often where teams lose alignment on who is responsible for web accessibility.
Ongoing Support
Describe what ongoing support looks like, such as regression monitoring, periodic audits, or training, and how issues are triaged over time, including workflow, escalation, and response expectations.
When contracts define the standard, the coverage, and the proof, they give both sides a shared operating model that still works months later, after the site has changed and the original project team has rotated.
Sales Language Can Expand Risk
Contracts are only part of the picture. When owners try to bring vendors into a dispute, the evidence they reach for is often straightforward: proposals, emails, marketing pages, and platform claims.
If your materials suggest “we guarantee compliance,” “our platform ensures accessibility,” or “you won’t need to worry about WCAG,” you may be creating avoidable exposure. Those statements are easy to quote, easy to misunderstand, and hard to defend without clear deliverables and documentation.
If your materials imply you are responsible for web accessibility end-to-end, that language can be used to argue you assumed duties beyond the SOW.
The goal is not to hide behind vague language. It is to use wording that matches what you will actually do, what is in scope, and what you can show when someone asks.
The Bottom Line: Responsible for Web Accessibility
So, who’s responsible for web accessibility—you or your client?
In practice, accessibility holds up when responsibility is documented, transparent, and treated as ongoing. That clarity protects people who rely on accessible digital experiences, strengthens partnerships, and keeps accessibility from becoming a source of conflict instead of progress.
If you treat accessibility as a one-time deliverable, responsibility will always be contested. If you treat it as an ongoing practice, responsibility becomes manageable—and shared with purpose.
At 216digital, we can help you build a practical strategy to integrate WCAG 2.1 into your development roadmap—on your terms. If you want a clear plan for aligning ADA expectations, scope, and documentation with real-world delivery, schedule an ADA Strategy Briefing.