Accessibility contract language for software agreements

A solicitation can ask for accessibility. Only the contract can hold a vendor to it, which is why accessibility contract language deserves as much attention as the evaluation. Once the award is made, the conformance report you evaluated is just a document in the file unless the agreement says what it means, what happens when the product falls short, and what happens at the next release.

This post sets out the accessibility contract language worth discussing with your counsel for software and SaaS agreements. It is a list of considerations, not a template to sign. Your attorney will know your state's contracting rules, your standard terms and how much negotiating room you have.

Why the contract matters under ADA Title II

The DOJ's Title II web rule requires a public entity to ensure that web content and mobile apps it provides or makes available "directly or through contractual, licensing, or other arrangements" are accessible, and that they conform to WCAG 2.1 Level AA from the applicable compliance date (28 CFR 35.200). The obligation sits with the agency. A vendor's product failing is the agency's compliance problem.

The contract does not move that obligation. What it can do is give you the means to meet it: a defined standard, a remedy, a timeline and a record. The post on third-party vendors covers the responsibility question in more depth.

The accessibility contract language to consider

1. A conformance commitment to a named standard

The core clause states what the vendor commits to. Precision matters more than force.

• Name the standard and version. "WCAG 2.1 Level AA", not "applicable accessibility standards" or "ADA compliance". Vague language leaves every later dispute about what was promised.
• Name what it covers. The product as delivered, including updates, the public-facing and staff-facing interfaces, mobile apps, and documents the system generates.
• Decide whether to require more. Some agencies require WCAG 2.2 Level AA, or "WCAG 2.1 Level AA or a later version adopted by the agency". Counsel should weigh whether an open-ended future standard is enforceable in your jurisdiction.

2. The ACR as a contract exhibit

Attach the vendor's Accessibility Conformance Report, the specific version and date you evaluated, as an exhibit. This turns the report from marketing into a representation about the product you bought.

Consider requiring that the vendor:

• represents the ACR is accurate for the version delivered;
• provides an updated ACR for each major release, or at least annually; and
• notifies you if it becomes aware the ACR is materially inaccurate.

Federal practice is a useful reference here. Section508.gov's sample acceptance language asks for an ACR "for each ICT item that is developed, updated, configured for the agency, and when product substitutions are offered." State and local agencies are not bound by that language, but its structure transfers well.

3. Known gaps and a remediation schedule

Most products will have some gaps at award. Rather than pretending otherwise, write them down.

• List the known nonconformances, by WCAG criterion, in an exhibit.
• Attach a dated remediation schedule for each, tied to a release.
• Define what happens if a date is missed: escalation, a service credit, a right to withhold acceptance of the release, or a termination right for persistent failure.

A remediation plan agreed before signature is worth far more than a promise to "continue improving accessibility".

4. Notice and response timelines for new defects

Defects will be reported after go-live, by staff or by the public. The contract should say how they are handled:

• a named accessibility contact on the vendor side;
• a severity scale (for example, a barrier that blocks a person from completing a core task is treated like a severity-one defect);
• response and resolution targets by severity; and
• interim measures while a fix is pending, such as an alternative way to complete the task.

5. No regression

New releases are where conformance quietly erodes. A no-regression clause says that updates, patches and new features must not reduce conformance below the level represented in the current ACR. Pair it with a right to test new releases and to report regressions under the same timelines as other defects.

This is particularly important for SaaS, where releases arrive whether or not you accept them.

6. Testing and acceptance rights

Reserve the right to test, or to have someone test on your behalf, before acceptance and at any point during the term. Section508.gov's sample language includes the agency's right "to perform independent testing" and requires the vendor, at no cost to the agency, to "repair or replace the non-compliant products or services within the period specified by the contracting officer."

7. Documents and content the system produces

If the product generates notices, agendas, permits, receipts, invoices or reports that you publish or send to the public, say that those outputs must also conform. These are often left out of both the ACR and the contract, and the Title II rule covers documents as well as web pages.

8. Indemnity and liability

This is the clause to leave most firmly with counsel. Some agencies seek indemnity for claims arising from the vendor product's inaccessibility. Vendors typically resist, and general limitation-of-liability caps may limit the value of whatever you obtain. Points to raise with your attorney:

• whether accessibility claims fall inside or outside the liability cap;
• whether the indemnity is tied to the vendor's failure to meet the stated standard, or broader;
• what your jurisdiction allows a public entity to accept or give.

An indemnity does not make a product accessible, and it does not change who the public sees as responsible. Treat it as a backstop, not the plan.

Sample wording, as a starting point

The following is illustrative only. It needs review by your counsel against your standard terms and state law before use.

Contractor represents that the Software, including all updates, mobile applications and documents generated by the Software for delivery to the public, conforms to WCAG 2.1 Level AA, except as listed in Exhibit [X] (Known Nonconformances). Contractor shall remediate each Known Nonconformance by the date stated in Exhibit [X]. The Accessibility Conformance Report attached as Exhibit [Y] is accurate for the version delivered. Contractor shall provide an updated Accessibility Conformance Report for each major release and no less than annually. No update shall reduce conformance below that represented in the then-current Accessibility Conformance Report. Agency may test the Software for conformance at any time, and Contractor shall correct any nonconformance identified, at no cost to Agency, within the period specified in [Section Z].

Build the record as you go

Contract terms are only as good as the evidence behind them. Keep the ACR you evaluated, your review notes, the gaps you raised and the vendor's written answers. When a dispute arises two years later, that record shows what was represented, what was known and what was promised. See the procurement guide for where this fits in the cycle.

---

Sources: 28 CFR 35.200 (the DOJ's 2024 Title II web rule, as amended in April 2026); Section508.gov, "Define Accessibility Criteria in Contracts" and "Buy Accessible ICT". This is general guidance, not legal advice; take contract terms to your counsel.

GOVvpat reviews the ACR before it becomes a contract exhibit and keeps the dated record of what was raised and answered. Request a quote.