IT Procurement and VPAT Documents

IT Procurement and VPAT Documents: Shifting Risk to the Vendor

No matter how hard your internal development team works to make the company website accessible (100% compliant with WCAG 2.2 Level AA), that effort will be entirely wasted if you integrate a flawed third-party software.

If your main Career Portal uses a third-party HR widget plugin that cannot be accessed with a keyboard, the blind applicant who fails to apply for a job will sue your company, not the vendor.

To prevent this kind of "ecosystem poisoning", Jonathan Lazar in his book Ensuring Digital Accessibility through Process and Policy emphasizes the importance of a "Shift-Right" strategy in Procurement. This article will discuss what a VPAT is and how to turn it into your contractual weapon.

1. What is a VPAT?

A VPAT (Voluntary Product Accessibility Template) is a standardized document format created by the Information Technology Industry Council (ITI) to evaluate how easily an ICT (Information and Communication Technology) product can be used by people with disabilities.

A VPAT document that has been filled out by a vendor is referred to as an ACR (Accessibility Conformance Report). In it, the vendor must answer line-by-line for every WCAG 2.1 or 2.2 criterion and declare their product's level of conformance (e.g., Supports, Partially Supports, or Does Not Support).

Related Insight

Building an Accessible Design System

2. The Danger of Fake or Inaccurate VPATs

In the world of B2B (Business to Business) software, Sales divisions often consider the VPAT to be merely an administrative document that must be submitted to win a project tender.

Many software vendors will fill in "Supports" across all 78 WCAG criteria without ever actually testing them. They rely on the fact that very few Procurement Officers understand how to read the document.

How to Critically Read a VPAT:

Look at the Remarks Column: If a vendor fills in "Partially Supports" for criterion 1.4.3 (Contrast Minimum), they must explain in the remarks column: which components fail, and what their remediation roadmap is.
Who Conducted the Audit? A VPAT filled out internally by the vendor's own development team is highly biased. The most reliable VPATs are those tested and certified by an independent, third-party accessibility auditor.

3. Make Accessibility an Absolute Deal-Breaker

Procurement and Legal staff must work closely with the technical team (or an Accessibility Champion) before any third-party software is purchased.

RFP (Request for Proposal): In the initial bidding document, include an explicit statement: "All vendors must include a current VPAT (based on WCAG 2.1 AA or 2.2 AA). Products without a VPAT will be automatically disqualified."
Live Trial (Sandbox): Do not blindly trust the VPAT document. Request a sandbox account, then have a blind user from your company (or your internal auditor) attempt to navigate the software using a Screen Reader. If the claims in the VPAT do not match reality, cancel the purchase.

4. Service Level Agreements (SLA) and Contract Language

Accessibility clauses must be baked into legal contracts and SLAs (Service Level Agreements).

Your software contract should have a clause that roughly states: "Vendor warrants that the product complies with WCAG 2.1 Level AA guidelines. If accessibility flaws violating these guidelines are discovered in the future, Vendor must provide a code patch within 30 calendar days at no additional cost. Should Vendor fail, the Contractor reserves the right to terminate the license with a full refund, and Vendor agrees to indemnify the Contractor for any litigation costs related to accessibility laws."

A strong indemnification clause officially shifts the legal liability away from your company and back onto the shoulders of the vendor. This forces the vendor to prioritize accessibility.

5. Conclusion

Building an inclusive digital ecosystem means you cannot introduce exclusionary software into it. Procurement gatekeeping of IT software using VPAT instruments and robust contracts is the only way to ensure that your internal accessibility investments are not dismantled by fragile code from the outside.

References

The philosophy of shifting liability and the procedural framework for evaluating VPAT documents in IT Procurement are extracted from the corporate policy analysis in the book Ensuring Digital Accessibility through Process and Policy by Jonathan Lazar. The integration of legal contract language (SLA) represents a standard risk management practice from that literature.