Your RFP says the vendor "must be ADA compliant." You feel protected. You are not.
That sentence has almost no enforceable technical meaning. It sounds like a requirement. It functions like a wish.
The Sentence That Feels Like a Requirement (and Isn't)
Picture a procurement lead at a mid-sized university finalizing an RFP for a new student portal. Legal asks for an accessibility clause. She adds one line: "Vendor's product must be ADA compliant." Everyone nods. The RFP goes out.
Eighteen months later, disability services flags that the portal is unusable with a screen reader. Legal pulls the contract to see what recourse exists. There isn't much. The clause never defined what "compliant" meant, against what standard, tested how, or by whom. The vendor can honestly say they believed they were compliant — because nothing in the contract said otherwise.
This is not a rare mistake. It's the default mistake, because "ADA compliant" sounds precise. It isn't.
Why "ADA Compliant" Isn't a Technical Standard
Here's the part most procurement teams don't realize: the ADA itself does not name a specific technical standard for websites or software. It's a civil rights law that prohibits discrimination — it doesn't contain a checklist of pixel-level requirements.
That means "must comply with the ADA" is, technically, a statement about outcome, not about method. It gives you no way to test the product before you buy it, no way to evaluate a vendor's response objectively, and no way to prove breach of contract later if the product turns out to be inaccessible. Both sides are guessing, and guessing is exactly the condition where disputes are born.
Contrast that with language that names an actual standard: "the product shall conform to WCAG 2.1 (or 2.2) Level AA." Now you have something testable. An auditor can check specific success criteria. A vendor can demonstrate conformance. A contract dispute has an objective reference point instead of two parties arguing about what "accessible" was supposed to mean.
The Stat: WebAIM's annual WebAIM Million evaluation of the top 1,000,000 home pages has repeatedly found that the vast majority — in recent years around 95-96% — have detectable WCAG 2 failures, with low-contrast text and missing alt text among the most common. If nearly every site fails without a named standard to test against, imagine how little "ADA compliant" alone accomplishes in a vendor contract. (WebAIM: The WebAIM Million)
The Four Clauses That Actually Do Something
Strong procurement language isn't longer — it's more specific. Four elements do most of the work.
1. Name the Standard, Version, and Level
Don't write "accessible." Write "conforms to WCAG 2.1 Level AA" (or 2.2, if that's your organization's requirement). This single change turns a subjective promise into an objectively testable one. It also gives your internal or third-party auditors something concrete to check the product against before final acceptance.
2. Require a Dated, Version-Matched VPAT/ACR
Ask for a current VPAT (Voluntary Product Accessibility Template), formatted as an ACR (Accessibility Conformance Report), as part of the RFP response — not after the contract is signed. This gives you a criterion-by-criterion starting point for evaluation while you can still compare vendors against each other.
Critically, the VPAT must be dated and tied to the specific product version being purchased. A VPAT from two release cycles ago describes a different product. Without this tie, a buyer can be shown a clean VPAT for version 4.2 and then receive version 6.0 — and have no contractual leg to stand on when the accessibility posture doesn't match.
3. Require Ongoing Conformance, Not Just Point-in-Time Conformance
A product that's accessible on delivery day can become inaccessible with the next feature release. Software updates constantly; accessibility clauses that only cover the moment of signing quietly expire the day the vendor ships an update.
Strong contracts include an ongoing-obligation clause: the vendor commits to maintaining WCAG AA conformance across future updates, and agrees to a defined process for reporting and remediating newly discovered accessibility issues. This is the clause most RFPs skip entirely — and it's the one that matters most over the life of a multi-year contract.
4. Set a Defined Remediation Timeline
What happens when your team (or a user, or an auditor) finds an accessibility defect after the contract is signed? Without a timeline, resolution is entirely up to the vendor's discretion and priorities — which in practice often means "eventually, maybe."
A remediation-timeline clause specifies a defined window — a stated number of business days — for the vendor to acknowledge a reported issue and a separate window to address it. This gives you real leverage. It converts "we'll look into it" into a contractual obligation with a clock attached.
Before vs. After: What Weak Language Costs You
Vague clauses vs. enforceable clauses — same intent, very different outcomes:
| Element | Weak / Vague Clause | Strong / Enforceable Clause |
|---|---|---|
| Standard referenced | "Must be ADA compliant" | "Shall conform to WCAG 2.1/2.2 Level AA" |
| Evidence required | None, or a self-attestation | Dated VPAT/ACR tied to exact product version |
| Testability | Subjective, disputed after the fact | Objective — testable against named criteria |
| Future updates | Not addressed | Ongoing WCAG AA conformance commitment |
| Defect handling | Left to vendor discretion | Defined remediation timeline (business days) |
| Dispute leverage | Weak — no breach standard exists | Strong — breach is measurable against the clause |
What This Looks Like in Practice
You don't need a 20-page legal exhibit to get this right. A few sentences, done precisely, cover most of the risk:
- "Vendor's product, as delivered and throughout the term of this agreement, shall conform to WCAG 2.1 Level AA."
- "Vendor shall provide a current, dated VPAT/ACR specific to the version of the product being purchased, as part of its RFP response."
- "Vendor shall notify Buyer of any known accessibility non-conformances discovered after delivery and shall acknowledge reported defects within [X] business days and provide a remediation plan within [Y] business days."
- "Vendor commits to maintaining WCAG 2.1 Level AA conformance across all future updates and releases during the term of this agreement."
Each of these is short. Each is specific. Each one is testable — which is the entire point.
The Cost of Getting This Wrong Is Rarely Small
Procurement teams sometimes treat accessibility language as boilerplate — something legal inserts and no one revisits. That's a mistake, especially given the broader landscape. Roughly 1 in 4 U.S. adults live with some type of disability (CDC), and globally, over 1 billion people — about 16% of the population — live with some form of disability (World Health Organization). Any vendor product your organization deploys will, sooner or later, be used by someone in that population.
There's also a real, growing legal environment around this. UsableNet's annual ADA Digital Accessibility Lawsuit Report has tracked several thousand federal web accessibility lawsuits filed per year in recent years, with plaintiffs' firms increasingly sending pre-suit demand letters before filing suit — and retail/ecommerce is consistently reported among the most-sued industries. If the inaccessible product came from a vendor, you'll want your contract to say clearly whose obligation it was to prevent that.
Put These Clauses to Work
Vague "ADA compliant" language protects no one and resolves nothing when a real dispute arises. Naming a specific WCAG version and level, requiring a dated and version-matched VPAT, and locking in ongoing-conformance and remediation-timeline commitments turns your RFP from a hopeful gesture into an actual contractual safeguard.
If your procurement team is drafting or revising an RFP, or reviewing a vendor contract that's already in front of you, don't guess at the wording. Get help drafting or reviewing your organization's accessibility procurement language — reach out through our resources page and get the clauses reviewed before they're signed, not after.