Your VPAT Is a Liability Document, Not a Compliance Document.

There is a document sitting in your procurement files, or published on your website, that your organization treats as evidence of accessibility conformance. It has a structured format. It references WCAG success criteria. It contains phrases like "Supports" and "Partially Supports" next to rows of technical requirements. It looks authoritative.

It may also be the most dangerous document your organization has published.

It may also be the most dangerous document your organization has published.

A Voluntary Product Accessibility Template, once completed, becomes an Accessibility Conformance Report (ACR). The distinction matters. The template is a blank form. The report is a signed declaration of your product's accessibility state. And that declaration, once made public, becomes discoverable, citable, and enforceable in ways that most organizations producing them have not fully considered.

Procurement teams read VPATs as proof of conformance. Plaintiff attorneys read them as admissions. The document serves both audiences whether you intended it to or not.

What a VPAT Actually Is

No certification body means the document is only as credible as the evaluation behind it. The VPAT was created in 2001 to address a practical problem in government procurement: federal agencies needed a consistent way to evaluate the accessibility of technology products before purchasing them. The template standardized that evaluation by mapping each product against specific accessibility criteria and asking vendors to self-report their conformance level: Supports, Partially Supports, Does Not Support, or Not Applicable.

The template is maintained by ITI and has been updated through several versions, most recently VPAT 2.5, which incorporates WCAG 2.1, Section 508, and the European standard EN 301 549. It is the leading global format for accessibility conformance reporting, used in both public and private sector procurement across multiple jurisdictions.

Here is the critical detail that changes how you should think about this document: there is no certification process. ITI does not review or approve completed VPATs. There is no third-party validation requirement. There is no auditing body that verifies the accuracy of what you report.

The vendor fills out the template, publishes the resulting ACR, and the market takes it at face value. That means the accuracy of a VPAT depends entirely on the rigor of the evaluation behind it. And for a significant number of organizations, that evaluation was either automated, incomplete, or both.

How VPATs Become Liability Documents

The shift from compliance tool to liability exposure happens the moment a VPAT is made public or submitted as part of a procurement process. At that point, it becomes a representation. A statement of fact about your product's accessibility state. And representations, when they prove inaccurate, create consequences.

In procurement

Federal agencies are required to purchase accessible ICT products under Section 508 of the Rehabilitation Act. The ACR is the primary vehicle for evaluating whether a product meets that requirement. Without one, the government may not proceed with the purchase. With an inaccurate one, the vendor has misrepresented their product's capabilities in a government contracting context. That is not a gray area.

As procurement teams become more sophisticated in evaluating accessibility claims, the stakes rise.

A VPAT that uses vague language, omits critical criteria, or reports "Supports" for criteria that the product clearly fails is not just incomplete. It is a document that contradicts the product's actual state, submitted to a buyer who relied on it to make a purchasing decision.

In litigation

Plaintiff attorneys in ADA cases routinely request accessibility documentation during discovery. A published VPAT that claims conformance with WCAG criteria while the product demonstrably fails those same criteria is not a defense. It is evidence. It shows that the organization was aware of accessibility as a requirement, claimed to meet it, and did not.

The legal risk of an inaccurate VPAT extends beyond the ADA itself. Filling out a VPAT inaccurately can be interpreted as a form of misrepresentation. When a product is marketed or sold on the basis of accessibility claims that its own documentation contradicts, the exposure includes not just accessibility law but potentially deceptive trade practices.

In the vendor relationship

Organizations that procure technology products often rely on their vendor's VPAT as evidence that the platform is accessible. When it is not, and when the organization gets sued or investigated, the liability does not transfer to the vendor. The entity delivering the service to the public bears the legal responsibility. The vendor's inaccurate VPAT may have created the false confidence, but the organization that relied on it without independent verification owns the outcome.

The Scanner-Generated VPAT Problem

The most common failure pattern in VPAT production is straightforward: an organization runs an automated scan, maps the scanner output to WCAG criteria, and fills in "Supports" for every criterion that did not generate a flagged error. Since automated tools can only test approximately 30% of WCAG criteria with reliability, and since roughly 42% of criteria cannot be evaluated by automation at all, the resulting document systematically overstates conformance.

A VPAT produced from scanner output alone is not a conformance report. It is a document that reports the absence of detected errors as the presence of conformance. Those are not the same thing.

The scanner did not test keyboard operability in your custom modal dialogs. It did not evaluate whether your captions accurately represent audio content. It did not determine whether a screen reader user can complete your multi-step form. It did not assess whether your error messages provide actionable guidance. The VPAT says "Supports." The product does not.

This is not a hypothetical risk. The FTC's 2025 enforcement action against accessiBe established a public precedent: an automated tool that claims to make websites WCAG-compliant, when it demonstrably cannot, constitutes a deceptive practice. The principle applies with equal force to VPATs. If the evaluation behind the document did not actually test the criteria the document claims to report on, the document overstates what is known.

What a Defensible VPAT Requires

The organizations that produce VPATs with genuine legal and procurement value share a common foundation: their documentation reflects an evaluation that actually tested what it claims to report. That means the conformance claims are grounded in manual validation, not just scanner output.

It means the testing methodology included keyboard navigation, screen reader evaluation, and interaction testing against the specific success criteria in question. It means the remarks column contains specific, honest descriptions of known limitations rather than generic language or silence.

It also means the document is treated as a point-in-time representation, not a permanent state. Products change. Features ship. Code is refactored. A VPAT completed against version 3.1 of a product does not describe version 3.4. Organizations that treat accessibility documentation as a one-time deliverable rather than a maintained artifact are producing documents that grow less accurate with every release.

The Section 508 Buy Accessible program recommends that VPATs be dated within 18 months for current procurement consideration. But even that window assumes the product has not changed significantly. In modern software development, 18 months is several major releases. Each one introduces the possibility that a previously conformant component no longer meets the criteria the VPAT claims it does.

The Document Reflects the Evaluation

A VPAT is only as defensible as the evaluation behind it. An evaluation built on scanner output alone produces a document that systematically overstates conformance. An evaluation built on manual expert testing, real assistive technology interaction, and honest reporting produces a document that can withstand scrutiny from procurement teams, legal counsel, and plaintiff attorneys alike.

Most organizations do not think about VPATs this way. They think of them as procurement paperwork. As a checkbox in an RFP response. As something to publish on a website and forget about.

Plaintiff attorneys do not see them that way. Procurement evaluators increasingly do not see them that way. And the organizations that discover the difference at the wrong moment are the ones who treated the document as administrative rather than consequential.

Your VPAT is a statement of what your organization knows, what it tested, and what it is willing to claim in writing. The question is whether that claim can survive the moment someone checks.