VPAT and the accessibility conformance report

A VPAT (Voluntary Product Accessibility Template) is a blank template published by the Information Technology Industry Council. You fill it in for your product, and the completed document is properly called an Accessibility Conformance Report, or ACR. In practice most people say "VPAT" for both the blank template and the finished report, and buyers asking for "your VPAT" mean the completed report.

The important word is voluntary. No agency issues it, no agency approves it, and there is no pass mark. You are self-reporting, in a standard format, so a buyer can compare your product against someone else's. That also means the document is only as credible as the testing behind it.

The current template is VPAT 2.5, published in four editions. Pick the one matching the standard your buyer is procuring against, and check the ITI site for the latest revision before you start, since they update it periodically:

• WCAG edition covers the WCAG success criteria alone. The right choice for most commercial software and web products.
• 508 edition covers the US Revised Section 508 standards. Required when selling to US federal agencies.
• EU edition covers EN 301 549, the European standard, which matters for EU public-sector procurement and the European Accessibility Act.
• INT edition combines all three. Longer to complete, but one document satisfies buyers in every region.

If you are unsure, the INT edition avoids producing three separate reports later. If you only ever sell to US federal buyers, the 508 edition is less work.

Every criterion in the report gets one of four ratings, plus a remarks column explaining the rating. The remarks are the part buyers actually read.

• Supports means the product meets the criterion with no known defects.
• Partially Supports means some functionality does not meet it. This is the honest answer far more often than vendors admit.
• Does Not Support means the majority of functionality fails the criterion.
• Not Applicable means the criterion is irrelevant to your product, for example a video criterion when the product contains no video.

A report that says "Supports" on all fifty-odd criteria with empty remarks is a red flag to any experienced procurement reviewer, because almost no real product is perfect. "Partially Supports" with a clear explanation and a remediation date reads as more trustworthy than a clean sheet nobody believes.

VPATs surface in procurement, usually late and usually urgently. The buyers who ask are US federal agencies, where Section 508 makes accessibility a purchasing requirement, along with state and local government, universities and school districts, hospital systems, and increasingly any large enterprise with its own accessibility programme.

It typically arrives as a line item in an RFP or a security and compliance questionnaire, with a deadline attached. That timing is why so many VPATs are completed badly: the request lands, the deal is waiting, and somebody fills the template in from memory in an afternoon.

No tool can generate your VPAT, and any vendor claiming otherwise is selling you a liability. Every criterion needs a judgement about your specific product, and a large share of the criteria cannot be evaluated by software at all. What automated testing does is narrow the work and remove guesswork from the part that is machine-checkable.

A workable order:

• Scan first. Run automated testing across your real templates and key user journeys, not just the homepage. This reliably settles criteria like colour contrast, image alt text, form labels and accessible names, and gives you concrete defects rather than opinions.
• Then test manually. Keyboard-only navigation, screen reader behaviour, focus order, meaningful sequence, error handling and anything involving judgement about content. This is the larger half and it needs a person.
• Write the remarks properly. For anything less than full support, say what fails, where, and what the plan is. Vagueness here is what gets a report sent back.
• Date it and own it. Record the evaluation methods, the product version tested, and the date. A report about a version from two years ago is worth little.

Automated testing covers roughly a third of the WCAG success criteria. That third is genuinely worth automating, because it is the part where machines are more reliable and more consistent than people. The rest is yours.

The recurring ones are easy to avoid. Marking everything "Supports" without evidence. Leaving the remarks column empty. Using the wrong edition for the buyer's standard. Evaluating only the marketing site when the product being purchased is the application behind the login. Submitting a report with no date or product version. And treating it as a one-off document rather than something you refresh as the product changes.

A VPAT is a snapshot of a moving product. If you ship weekly, a report from last year describes software that no longer exists.