Your organization works hard to build accessible digital experiences. But all of that effort can be undermined the moment you sign a contract with a vendor who hasn't done the same, or maybe is accessible at the beginning of the contract but not after an update.

Inaccessible third-party tools are one of the most common and preventable accessibility risks organizations face. The problem is that vendor accessibility failures are rarely discussed, much less demonstrated, during the sales process. Where they are most likely to surface after contracts are signed, systems are integrated, and your users are hitting barriers. At that point, your leverage is gone because the money is already spent.

Procurement is one of the most powerful tools in your accessibility strategy.  Yet, most organizations aren't using it. The correct contract language sets clear expectations upfront, holds vendors accountable to measurable standards, and gives you viable options if they fall short.

This article walks through what language should be considered and how to start putting it to work before you sign your next contract.

One huge caveat: I am not your lawyer. All of this needs to be run through in-house or outside counsel before implementation.

Accessibility Compliance

The first thing you need in a procurement contract is an overarching statement that everything your vendor delivers will be accessible. Not just the product, everything.

Accessibility Compliance: All digital deliverables produced under this Agreement, including but not limited to websites, web applications, mobile applications, electronic documents, multimedia content, and software interfaces, shall conform to the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA success criteria, as published by the World Wide Web Consortium (W3C), or any successor standard mutually agreed upon in writing by the parties.

The next thing you absolutely need is a guarantee that the vendor will conduct testing and produce an ACR/VPAT.  Being their external QA is expensive, slow, and reactive.  If the product you are buying is cloud-based software, you may want to identify how often the ACR/VPATs need to be updated.

Conformance Verification. Prior to delivery, the Vendor shall conduct accessibility testing using both automated tools and manual evaluation methods, including testing with commonly used assistive technologies such as screen readers, keyboard-only navigation, and voice recognition software. The Vendor shall provide an Accessibility Conformance Report (ACR) for each deliverable, based on the Voluntary Product Accessibility Template (VPAT®), documenting the conformance status of each applicable WCAG success criterion.

Documentation and Support. The Vendor shall provide reasonable and accessible documentation and technical support to assist the Client in understanding and sustaining accessibility conformance following delivery. For SaaS deliverables, ACR/VPATs shall be updated every X months, or when a new major version is released, whichever comes first.

Also, it isn’t enough for your contractor to commit to accessibility; everything in the procurement contract related to accessibility must also bind any subcontractors they use.

Use of Subcontractors. Vendor shall ensure that all subcontractors, consultants, and third parties engaged in performance of this Agreement are bound by the same restrictions.

Bugs happen.  But you shouldn’t be paying your vendor to fix bugs they created. Remediation timeframes can be flexible.  The fact that you aren’t paying for it is not.  Often, organizations specify timeframes that depend on whether the bug was reported by a customer or is Level A, which are expedited, while Level AA bugs can take longer to get fixed.

Remediation. Remediation shall be treated as a defect correction and shall not constitute a change in scope. If a deliverable is found to contain accessibility barriers, whether identified by the Vendor before delivery or by the Client following acceptance, the Contractor shall remediate identified issues within the following timeframe …

Most contracts include catch-all language requiring that the vendor comply with local, state, national, and sometimes international laws.  Identifying accessibility laws in or around these clauses can only strengthen the purchaser’s claim that accessibility was 100% part of the contract from the beginning, in the event of a dispute.

Legal Compliance. Nothing in this clause limits the Vendor’s obligation to comply with applicable accessibility laws and regulations, including but not limited to Section 508 of the Rehabilitation Act of 1973 (as amended), the Americans with Disabilities Act (ADA), and any applicable state, local, or international accessibility requirements.

Software projects never end with one install.  There are always updates, security maintenance, and new features down the road.  The following clause makes it clear that not only must the initial delivery be accessible, but that all deliveries must be accessible as well.  Only companies with mature accessibility programs can truly accomplish this.

Ongoing Obligations. Where this Agreement involves maintenance, updates, or iterative development, the Vendor shall ensure that accessibility conformance is maintained throughout the engagement. New features or content additions shall meet the same conformance standard as the original deliverable.

Indemnification for Accessibility Non-Conformance

Indemnification is a promise in a contract that effectively states, "if your mistake causes me to get sued or lose money, you will cover that cost; we won’t have to pay for it."

For example, if a vendor sells you inaccessible software that is the basis of an ADA lawsuit against your organization, indemnification means the vendor is on the hook for those legal and settlement costs, not you. It's a "you broke it, you bought it" rule codified into the contract.

A solid indemnification clause in this context should address third-party claims arising from the vendor's failure to meet the agreed accessibility standard, the cost of defense (including attorneys' fees and expert witness costs), any settlement amounts or judgments, and regulatory fines or penalties, where applicable.

Common carve-outs to negotiate: Vendors will typically push back and seek to limit indemnification to situations where the accessibility failure was solely their fault. That's reasonable. Standard carve-outs include cases where the client modified the deliverable after acceptance, where the client provided content or design specifications that caused the barrier, or where the client failed to implement a remediation the vendor provided. These carve-outs are extremely fair, and a well-drafted clause should include them.  However, it is excruciatingly important to document in writing when the customer has made a decision that may lead to an outcome that is inaccessible.

Mutual vs. one-way: Vendors sometimes ask for mutual indemnification. Whether that's appropriate depends on the relationship. If the client is providing assets, content, or guidance that could independently create accessibility problems for the vendor, some degree of mutuality may be warranted.

A practical note about indemnification

Indemnification is only as good as the vendor's ability to pay. You should also consider requiring the vendor to carry errors and omissions (E&O) insurance with sufficient limits and naming the client as an additional insured. That gives the client a direct path to the vendor's insurer rather than depending solely on the vendor's financial capacity.

Sample indemnification language

Indemnification by Vendor. The Vendor shall defend, indemnify, and hold harmless the Client an d its officers, directors, employees, and agents from and against any and all third-party claims, demands, actions, losses, damages, penalties, fines, settlements, and expenses (including reasonable attorney's fees and litigation costs) arising out of or relating to the failure of any deliverable to conform to the accessibility standards required under this Agreement.

Indemnification Conditions. The Vendor’s indemnification obligations are subject to the following conditions.

1) The Client shall provide the Vendor with prompt written notice of any claim for which indemnification is sought.

2) The Client shall grant the Vendor reasonable control over the defense and settlement of the claim, provided that the Vendor shall not settle any claim in a manner that imposes obligations on the Client or includes an admission of fault by the Client without the Client's prior written consent.

3) The Client shall provide reasonable cooperation and assistance in the defense of the claim at the Vendor’s expense.

Limitations and Carve-Outs. The Vendor’s indemnification obligations shall not apply to the extent that a claim arises from modification of the deliverable by the Client after acceptance without the Vendor’s written approval, content or design specifications provided by the Client that caused or materially contributed to the accessibility barrier, the Client's failure to implement a remediation solution provided by the Vendor within a reasonable timeframe, or the Vendor’s use of the deliverable in a manner inconsistent with the Contractor's written guidance.

Insurance. The Vendor shall maintain, throughout the term of this Agreement and for a period of three years following final delivery, errors and omissions (E&O) insurance with limits of no less than [INSERT AMOUNT] per occurrence and [INSERT AMOUNT] in the aggregate. Upon request, the Vendor shall provide the Client with certificates of insurance evidencing such coverage and shall name the Client as an additional insured on the relevant policy.

Remediation as Mitigation. Where a third-party claim is pending or threatened, the Client shall provide the Vendor a reasonable opportunity to remediate the identified accessibility barriers prior to any settlement, to the extent that remediation would mitigate or resolve the claim. This provision shall not require the Client to delay any legally required response or compromise any defense.

I can’t afford a lawyer - what are other resources I can use?

I hear this a lot. However, can you really not afford a lawyer? The cost of litigation can be astronomical.

But if you insist on doing this yourself, Section508.gov is probably the most authoritative starting point. This program publishes sample procurement language specifically for federal agencies, covering ACR/VPAT requirements, testing validation, and conformance reporting. It is designed to be adaptable and free. You can find it at section508.gov/buy/define-accessibility-criteria

The City of Boulder, Colorado, has published its actual vendor contract language publicly, which is both rare and useful. Their contract requires vendors to provide a VPAT, conduct audits, and explicitly indemnify the City against accessibility claims, with the indemnification obligation scoped to the accessibility standards in effect at the time of delivery. That scoping detail is a smart carve-out that vendors should consider trying to negotiate for. You can find it at https://bouldercolorado.gov/contract-language-vendors

Final Thoughts: Do not mess around with this!!

Digital accessibility is no longer a niche concern or a nice-to-have. It is a legal obligation, a civil rights issue, and increasingly, a litigation target. When your organization contracts with a vendor to build or maintain digital products, you are not just buying a deliverable. You are absorbing the responsibility for whether that deliverable works for people with disabilities. If it does not, your organization is the one that gets sued, regardless of who wrote the code or designed the product.

Procurement contracts are your primary line of defense. Vague language like "the vendor will make reasonable efforts toward accessibility" is what they call in the legal space “illusory.”  It can’t be objectively measured, which makes it functionally worthless. Relying on the catch-all "The vendor shall ensure that all deliverables comply with all applicable federal, state, and local laws and regulations" is not a good idea either.  What protects you is specific, enforceable language: a defined standard (WCAG 2.1 AA at a minimum), a documented testing requirement, a conformance report delivered with the product, clear remediation timelines, and indemnification that places liability on the party that created the problem if litigation occurs.

The good news is that this does not require reinventing the wheel. Real contract language exists, has been tested in procurement contexts, and is publicly available from sources like Section508.gov and the City of Boulder.

Procurement teams: Please don’t ignore this issue and assume your vendor has things handled. They may. They may not. Without a contract that holds them to a specific standard, you will not find out until someone files a complaint.

A few things are worth keeping in mind as you move forward. Accessibility requirements belong in the contract before the work starts, not as an afterthought during final review. Indemnification is only meaningful if the vendor can actually pay, which is why insurance requirements and additional insured status matter. And the clause you put in today needs to account for the fact that standards evolve: tying your language to the current version of WCAG while building in a mechanism to update as standards change will protect you over the life of longer vendor relationships.

None of this is complicated. It is, however, detailed, and a matter of deciding that accessibility is something your organization takes seriously enough to put in writing and enforce. The organizations that do this well are not necessarily the largest or best-resourced. They are the ones who decided vague commitments were not good enough and wrote their contracts accordingly. That decision is available to any organization right now, and there is no valid reason to wait.