How to Read a VPAT Before You Sign the Contract

What the Document Actually Is

The Voluntary Product Accessibility Template is a reporting format maintained by the Information Technology Industry Council. Strictly, the VPAT is the blank template; a completed one is an Accessibility Conformance Report, an ACR. In everyday procurement conversation both get called a VPAT, which is harmless as long as everyone knows the document is a vendor self-assessment.

That is the first thing to internalize. It is not a certification, there is no issuing authority, and nobody has to approve it. It can be produced by an independent audit firm after rigorous testing or by a product manager in an afternoon, and both results look similar at a glance. Learning to tell them apart is the skill, and it builds directly on knowing what the underlying standards require.

Check the Edition First

The template comes in several editions, and using the wrong one makes the report unusable regardless of how carefully it was filled in.

• WCAG edition: the W3C success criteria alone.
• Section 508 edition: the Revised Section 508 standards, which include criteria beyond WCAG covering things like hardware, documentation and support.
• EN 301 549 edition: the European standard.
• INT edition: all of the above combined, common from large vendors selling internationally.

If your requirement is Section 508 and you were handed a WCAG-only report, you have not received an answer about the support and documentation criteria. Check the WCAG version too: a report against WCAG 2.0 does not tell you about the criteria added in 2.1 and 2.2, several of which concern mobile use and are exactly where modern products fail. Check the date as well, and compare it against the product's release history. A report two major versions old describes software you are not buying.

The Conformance Column Is the Least Useful Column

Each criterion gets a conformance level: Supports, Partially Supports, Does Not Support, or Not Applicable. Buyers scan this column, count the "Supports" entries and form an impression. That is close to worthless, because the terms are only meaningful alongside the remarks.

The remarks and explanations column is where the report either becomes credible or falls apart. Good remarks are specific about scope and about failure: which parts of the product, which user flows, what exactly does not work and what a user encounters when it does not. Weak remarks restate the criterion in different words.

Compare these two entries for the same criterion:

• "Supports. The product provides text alternatives for non-text content." This says nothing. It is the criterion, rephrased.
• "Partially Supports. Images uploaded by end users require alternative text at upload. Three legacy icons in the reporting module lack text alternatives; scheduled for the next release." This is a real answer, and it tells you the author tested the product.

The second entry is a better signal than a page of unqualified "Supports", because it demonstrates that someone looked.

Find Out What Was Tested

A conformance report describes something specific, and the front matter should say what. Read it for the boundaries:

• Which product and version. "Version 7.x" is not a version.
• Which parts. Administrative interfaces are frequently excluded. If your staff use the admin console daily, an end-user-only report covers the wrong half of your problem.
• What method. Automated tooling alone, manual testing, or assistive technology testing, and if the last, which screen readers and browsers.
• Who performed it. Internal staff or a named third party.

If the methodology section is missing or vague, that is your finding. A report that will not say how it was produced is an assertion, not evidence.

A Clean Report Is a Red Flag

This is counter-intuitive and it is the most useful heuristic in this article. A report showing full support for every criterion, with no partial support anywhere, almost never reflects a real audit.

Substantial software has edge cases. Complex data tables, custom widgets, PDF outputs, third-party embeds, charts. A genuine assessment surfaces something. A report with no exceptions usually means the criteria were read and agreed with rather than tested against the product.

Prefer the vendor who documents twelve partial-support entries with specific remarks and a remediation roadmap over the one claiming universal conformance. The first tells you what you are buying and what to write into the contract. The second tells you nothing and leaves the discovery until after go-live, when your leverage is gone.

Turn the Report Into Contract Language

The report is most valuable as an input to the agreement rather than as a filing. The exceptions it lists are the raw material for clauses:

• Name the specific defects and a remediation date, rather than a general accessibility warranty.
• Require an updated report at each major version, so the position does not silently decay.
• Reserve the right to verify independently, and consider doing so for anything public-facing.
• Tie a meaningful portion of acceptance to accessibility criteria being demonstrably met.

Vendors respond to what is in the contract. A vendor who knows the report will be read carefully produces a better report next time, which improves the market for everyone. If you want an independent read on a report you have been handed, or a verification of a product before acceptance, that is what our audit practice does, and you can send us the document.