What to Put in a Client Contract About Accessibility

An accessibility clause in a client contract should name the target standard, the pages and parts in scope, who owns new content, and what happens after launch. When those four points are missing, a client can hear a promise the agency never meant to make, and an agency can inherit work it never priced. A short, plain clause prevents that argument.

This is general information, not legal advice. If you have received a demand letter or been sued, talk to a qualified attorney. Have an attorney review the real contract before either side signs it.

Key takeaways

• Name one target standard with its version and level, such as WCAG 2.2 AA, and say how work will be measured against it.
• List what is in scope by page type, template, form, and part of the site, and list what is out of scope just as plainly.
• Give the client a clear duty for content they add, and give the agency a clear duty for code the agency builds.
• State how testing will be done, what counts as accepted work, and how long fixes after handoff are included.
• Keep maintenance in the contract, because a site that is accessible at launch can drift as soon as new pages, images, and plugins are added.

Name the target standard in the accessibility clause

Start with the standard, not with a broad promise. WCAG 2.2 is the Web Content Accessibility Guidelines published by the W3C. It sets testable success criteria at levels A, AA, and AAA. A contract that says only "accessible" or "best practice" gives no one a test to run. A contract that names WCAG 2.2 AA gives both sides a shared reference point.

Do not promise that a site meets a law. The Department of Justice published Guidance on Web Accessibility and the ADA on March 18, 2022. That guidance says businesses open to the public and state and local governments have flexibility in how they meet ADA requirements, while still having to ensure online goods, services, programs, and activities are accessible. That distinction matters in a contract. The agency can commit to work measured against WCAG 2.2 AA. Whether that work satisfies a law for a given client is a legal question for the client and the client's attorney.

Write the standard line in plain words. For example: "Accessibility work under this agreement will be measured against WCAG 2.2 AA." Then add the test line next to it, so the standard is not left as a label with no proof behind it. State whether the test will use an automated scan, a manual keyboard check, a screen reader check, or a mix of those methods. The Justice Department guidance itself warns that a clean automated report does not necessarily mean everything is accessible, and it lists barriers such as poor color contrast, missing alt text, missing video captions, inaccessible online forms, and lack of keyboard access. A scan is a starting point, and a quick manual keyboard and screen reader check is part of good practice.

Define the scope in plain lists

Scope is where most accessibility arguments start. A client may assume the whole site is covered. An agency may assume only the new templates are covered.

List in scope work by concrete parts: headers, footers, sidebars, web forms, pages built or assembled by the agency, and front end elements controlled only by the agency theme or code. Then list the page types: home, service pages, contact page, checkout or booking flow, and any landing pages the agency builds. If a part is covered only for certain templates, say so.

List out of scope work with the same care. Common out of scope items include content imported from an old site, posts and products the client adds later, and elements controlled by third party plugins or embeds that the agency did not build. A booking widget, a payment form, and a chat tool can each block a task even when the surrounding page is sound. If those tools are in scope, name them and say who will test them. If they are out of scope, name them and say who owns the gap.

Add a line for extra work. When a client wants old posts, old product pages, or third party content reviewed and fixed, that work can sit in a separate remediation plan after launch, or it can be added to the build for an added fee. The contract should say which route applies, and how the added work will be priced.

A line that says "all pages" without a page list is not scope. It is a guess.

Put content duties and maintenance in writing

A site is not finished at launch. New images need alt text. New forms need labels and clear error messages. New videos need captions. If the contract stops at launch, the first content update can undo the work both sides paid for.

Give the client a content duty in plain terms. The client supplies alt text for images they upload, or approves alt text the agency drafts. The client does not paste text as an image, does not add a plugin without telling the agency, and does not publish a PDF as the only way to read key information without an accessible alternative.

Give the agency a maintenance duty to match. State how often the site will be scanned, who reviews the scan, and how fixes are reported. State how a reported barrier from a visitor will be handled and who logs it. A feedback route on the site helps here, because a way to report accessibility problems lets an owner fix issues that a scan missed.

Set acceptance and fix terms. Say what counts as accepted: the named pages pass the agreed test, the report is delivered, and known issues are listed with a fix plan. Say how long after handoff the agency will fix confirmed accessibility defects in its own work at no added charge, and say what happens after that period ends.

Also settle who owns the record. A dated record of scans, fixes, and retests is useful for a client who later needs to show what was done and when. Say who keeps that record, in what form, and for how long.

How Axeazy helps with this exact issue

A contract clause is only as good as the work behind it. Axeazy scans a site for WCAG 2.2 AA problems using axe-core, then fixes the underlying code instead of laying a script over the page. For sites with a GitHub repository, fixes arrive as a real pull request with a visible code diff that the owner or developer reviews and merges.

The honest scope matters for contract writing too. Axeazy lists 14 fix categories, and the honest scope page sets out what is covered and what still needs a human check. An agency can use that list when it writes its own scope lines, instead of promising work on parts of a site that a scan cannot reach, such as PDF files or content behind logins. The agency page describes white label reports, bulk scanning, and per client risk scoring for up to 10 client sites, which fits a maintenance clause that promises regular scans and client facing reports. The methodology page explains how Axeazy scores and documents scan work.

Want a quick read on your own site before you draft the clause? Run Axeazy's free 60 second scan . It needs no signup. For the demand letter side of the story, read the demand letter guide on our blog.

Last checked: October 26, 2026.

FAQ

Should a contract promise that a site meets the ADA?

No. A contract should name the technical standard the work will be measured against, such as WCAG 2.2 AA, and leave the legal question to the client and the client's attorney. A promise about a law is hard to prove and easy to dispute. A named standard, a named test, and a named scope give both sides something they can check.

What should be in scope for a new site build?

In scope work should list the templates, page types, forms, and parts the agency actually builds, such as headers, footers, and sidebars. It should also name any booking, payment, or chat tools that visitors need to finish a task, and say who tests them. Out of scope work should be listed too, including imported old content and third party elements the agency did not build.

Who owns accessibility after launch?

Both sides own a part of it. The client owns content they add, including alt text, captions, and form wording, unless the contract gives that task to the agency. The agency owns the code it built and the maintenance it agreed to, including scans, reports, and fixes inside the agreed period.

Does an automated scan count as testing in a contract?

A scan counts as one part of testing, not as the whole test. The Justice Department guidance warns that a clean automated report does not necessarily mean everything is accessible. A sound contract pairs a scan with a manual keyboard check and a screen reader check on key pages.

Sources

• Web Content Accessibility Guidelines (WCAG) 2.2, checked October 26, 2026
• Guidance on Web Accessibility and the ADA, checked October 26, 2026
• Incorporating Accessibility in Web Development Contracts, checked October 26, 2026
• Web Contract Accessibility Clauses Explained, checked October 26, 2026