How to Read a VPAT Without Being Misled by It

2026-10-15

Procurement teams ask for a VPAT hoping it settles the accessibility question, and vendors hand over documents in which nearly every criterion supports. The form looks like a certificate. It is not one. It is a structured self report, completed by the vendor, with no governing body checking the answers before it lands in your inbox.

Read with that in mind, a VPAT is still valuable. It tells you how seriously a vendor takes accessibility, where they admit weakness, and what to test yourself. Read as a rubber stamp, it is worse than useless, because it retires questions that were never actually answered.

Supports is a claim, and the remarks are the evidence

The conformance column compresses each criterion into a word, and the word shoppers of these documents learn to read first is supports. The column that matters is remarks and explanations. Specific remarks name product areas, known exceptions, and workarounds. Empty remarks, or boilerplate repeated down the page, tell you the evaluation behind the claim may be just as thin.

Partially supports deserves the closest reading of all. It is where honest vendors park real information: which screens fail, which user groups are affected, what is planned. A document with a few candid partially supports entries and detailed remarks is usually more trustworthy than a wall of supports with nothing behind it.

Check the basics: version, standard, date, and method

Four facts frame everything else in the document. Which WCAG version and level it reports against, since a 2.0 report is a decade behind current expectations. When the evaluation happened, since a VPAT describes a product version that may no longer ship. Who evaluated, the vendor or an independent firm. And by what method, manual testing with assistive technology or an automated scan alone.

Automated only evaluations cap what the document can honestly claim, because scanners detect a minority of WCAG failures and none of the usability barriers that matter most to keyboard and screen reader users. A VPAT whose method section names screen readers, keyboard testing, and manual review is describing a different class of effort than one resting on a tool report.

Your journeys, not their criteria list, decide the risk

A vendor product can support most criteria and still block your users completely if the failures sit on your critical path. Map the partially supports and does not support entries onto the journeys your customers actually take with the product: sign in, search, purchase, get help. One failure on the payment screen outweighs twenty supports on pages nobody visits.

Then test those journeys yourself, briefly, with a keyboard and a screen reader, before the contract makes it awkward. Vendors expect serious buyers to spot check, and the conversation that follows a concrete finding, this dialog traps keyboard focus on your current build, produces better commitments than any exchange of documents.

Turn the VPAT into contract language

The document earns its keep when its claims become obligations: the conformance described is warranted for the version you are buying, remediation timelines attach to the admitted gaps, and material regressions in accessibility count as defects under the agreement. Without that translation, a VPAT is marketing material filed in a procurement folder.

Set the review cadence while you are at it. Products change monthly, and a VPAT from two releases ago describes software your users no longer run. Annual refresh, plus a fresh report on major version changes, keeps the document a living input to vendor management instead of an artifact of the sales process nobody reads again.

Frequently asked questions

What is a VPAT in plain terms?

It is a template vendors complete to describe how their product conforms to accessibility standards such as WCAG, published as an Accessibility Conformance Report. It is a structured self report by the vendor, not an independent certification, and its value depends on the detail and honesty of its remarks and evaluation methods.

What does partially supports mean?

It means the vendor says some aspect of the product does not fully meet that criterion. These entries are often the most informative part of the document: the remarks should say what fails, who is affected, and what is planned. Map them onto your critical user journeys to judge the real risk.

Can we rely on a VPAT instead of testing?

No. A VPAT tells you what to test, not what to skip. Check its standard version, date, evaluator, and methods, read the remarks behind supports claims, then spot test your critical journeys with keyboard and screen reader before procurement. Vendor claims and observed behavior regularly differ.

What should procurement do with a weak VPAT?

Treat gaps as contract material: remediation timelines for admitted failures, conformance warranted for the version purchased, and a refresh cadence for the report. A vendor unwilling to attach commitments to its own document is telling you how much weight the document deserves.