A VPAT (Voluntary Product Accessibility Template) is a free template from the Information Technology Industry Council that vendors use to document how a product conforms to accessibility standards such as Section 508, EN 301 549, and WCAG. A completed VPAT is called an Accessibility Conformance Report, or ACR.
If you sell software, hardware, or digital content to a federal agency, a university, or a large enterprise, a request for your VPAT will eventually land in your inbox. It usually arrives inside an RFP or a procurement checklist, with a short deadline and no explanation of which edition the buyer wants. Knowing the answer before the request arrives is most of the work.
VPAT editions compared: 508, EU, WCAG, and INT
ITI publishes the VPAT in four editions so a vendor can report against the standard a given contract actually cites. The current release is version 2.5Rev, published in April 2025 and available free from ITI. Membership is not required, and all four editions ship as Microsoft Word files.
| EDITION | STANDARD IT COVERS | WCAG VERSION INCLUDED | WHEN TO USE IT |
|---|---|---|---|
| VPAT 2.5Rev 508 | Revised Section 508 standards | WCAG 2.0 | Selling to US federal agencies |
| VPAT 2.5Rev EU | EN 301 549 | WCAG 2.1 | European public procurement of ICT |
| VPAT 2.5Rev WCAG | W3C WCAG only | WCAG 2.0, 2.1, and 2.2 | Buyers who cite WCAG directly |
| VPAT 2.5Rev INT | Section 508, EN 301 549, and WCAG | WCAG 2.2 | Selling across all three regions |
The WCAG version differs by edition because each underlying standard incorporates a different one. That is why the Section 508 edition still references WCAG 2.0 while the WCAG and INT editions carry WCAG 2.2. If you are selling to the US federal government, guidance is explicit that you must use either the Revised Section 508 edition or the INT edition. When a solicitation does not specify, INT is the safest single answer, because it covers all three standards at once.
A completed VPAT is an Accessibility Conformance Report
The naming trips up first-time responders. The VPAT is the blank template. Once you test the product and record the results, the finished document is an Accessibility Conformance Report. Buyers use both terms loosely, and GSA publishes a step-by-step guide to creating an ACR from a VPAT, along with a free ACR Editor that produces the report in a machine-readable format.
There is no VPAT certification. ITI does not review or approve completed reports, there is no pass or fail score, no certifying body, and no submission process. You publish the ACR on your website or send it when a buyer asks. The one exception worth flagging is that a solicitation can require a third-party audit as a contract term, in which case follow the solicitation rather than the general rule.
How to fill out a VPAT, step by step
- Pick the edition the contract cites. If the solicitation names Section 508, use the 508 or INT edition. Guessing here is the most common cause of a report that comes straight back.
- Scope the product precisely. Name the product and its version number on the title page. A report that covers the platform in general, with no version, ages badly and invites follow-up questions.
- Test before you write. The report is a record of testing, not a statement of intent. Record the methods you used, manual, automated, or both, in the Evaluation Methods field, and name the tools.
- Rate each applicable criterion. Use one of the four conformance phrases exactly as written. Improvised wording is a frequent reviewer complaint, because it breaks the comparison the buyer is trying to make across vendors.
- Explain every gap in the remarks column. Remarks are required wherever you claim partially supports or does not support, and encouraged everywhere else. A candid remark with a roadmap beats a silent gap.
- Clean up and date the file. Delete the template instruction pages before you send it, confirm the finished document is itself accessible, and record the report month and year so buyers can judge whether it is current.
The four VPAT conformance levels
Every applicable criterion gets exactly one of four ratings. The wording matters, because reviewers scan for these phrases rather than reading your prose.
| CONFORMANCE LEVEL | WHAT IT MEANS | REMARKS REQUIRED |
|---|---|---|
| Supports | At least one method meets the criterion without known defects, or meets it with equivalent facilitation | Encouraged, not required |
| Partially supports | Some functionality of the product does not meet the criterion | Required |
| Does not support | The majority of product functionality does not meet the criterion | Required |
| Not applicable | The criterion is not relevant to the product | Encouraged, not required |
Two details save rework. Partially supports replaced the older supports with exceptions wording at the request of US Access Board representatives, so older reports you inherit may still use retired language. And not evaluated is reserved for the Level AAA table, which US federal procurement does not require you to complete at all.
Where the VPAT fits in federal procurement
Conformance to the Revised 508 Standards is mandatory for Executive Branch federal agencies under Section 508 of the Rehabilitation Act. That obligation reaches you through the acquisition process rather than as a rule you comply with directly. Agencies request an ACR during the pre-award phase for each item of information and communications technology they are buying, then evaluate the claims in it during the award phase.
Two things follow. First, an agency is not obliged to take your report at face value. Federal acquisition rules require accessibility testing regardless of the source of the technology, whether commercial, open source, or custom built, and GSA publishes separate guidance for buyers on interpreting vendor claims. Overstating conformance is a short-lived advantage. Second, accessibility gets scored, so a thin or missing ACR can cost you an award even when the rest of the RFP response is strong.
Treat your VPAT answers as institutional knowledge
The teams that turn a VPAT request around in days rather than weeks are not better writers. They stopped treating each request as a fresh writing project. The Consortium for Service Innovation formalized that shift as Knowledge-Centered Success (KCS), a methodology for integrating the use, validation, improvement, and creation of knowledge into the workflow itself rather than rebuilding it each time. Its principles and core concepts describe a demand-driven, self-correcting loop that any knowledge-intensive team can apply.
Applied to accessibility reporting, that means every tested criterion, every remark, and every piece of supporting evidence belongs in a content library with a named owner and a review date, not buried in the last ACR you happened to send. The same answers feed adjacent questionnaires. A HECVAT asks for IT accessibility evidence, and so do a growing number of enterprise security reviews. Answer once, reuse everywhere, and refresh on a calendar rather than on request.
RocketDocs was built for exactly this kind of recurring, evidence-backed response work: approved answers with owners and review dates, routing to the experts who own each control, and an audit trail a reviewer can follow. See how the platform handles security questionnaires, or book a demo to walk a real accessibility request through it end to end.
Looking for the platform behind this? See the RocketDocs platform or book a demo.
