A VPAT is a structured document that describes how well your product meets a set of accessibility standards. The acronym stands for Voluntary Product Accessibility Template, and the document it produces is called an Accessibility Conformance Report (ACR).
If a procurement team has asked you for a VPAT, they want to know whether your product is accessible enough to buy. This post explains what the document actually says, why buyers ask for it, what the current versions look like, and how to produce one without it eating two weeks.
When buyers ask for a VPAT
Three groups will ask you for one regularly:
- US federal agencies and their contractors, because Section 508 of the Rehabilitation Act requires federal procurement to consider accessibility.
- Large enterprises, especially in regulated industries like healthcare, finance, education, and government adjacent sectors.
- Public-sector buyers in Europe, where EN 301 549 sets the equivalent standard for government IT procurement.
If you sell B2B software and your buyer has a procurement department, expect a VPAT request inside the security-and-compliance questionnaire. Larger deals stall at this step more often than at any other.
What a VPAT actually contains
A VPAT walks through a list of accessibility success criteria and tells the reader, for each one, whether your product supports it, partially supports it, does not support it, or whether the criterion does not apply.
The current standard template is VPAT 2.4, published by the Information Technology Industry Council (ITI). It comes in four flavours, depending on which standards your buyer cares about:
| Edition | Covers | | --- | --- | | WCAG | WCAG 2.1, levels A and AA | | 508 | Revised Section 508 standards (US federal) | | EU | EN 301 549 (European public sector) | | INT | All three of the above, in one document |
Most B2B buyers will accept the WCAG edition. US federal contracts require the 508 or INT edition. European public tenders require the EU or INT edition.
Each edition contains the same structural sections:
- Product information. Product name, version, vendor, contact, date.
- Evaluation methods. How you tested. Was it manual, automated, third-party audit, internal expert review.
- Applicable standards. Which versions of WCAG, 508, or EN 301 549 you are reporting against.
- Terms. A short legend explaining the conformance terminology you use.
- Tables of conformance. The bulk of the document. One row per success criterion, with a conformance level and explanatory remarks.
The conformance levels are standardised:
- Supports. The product fully meets this criterion.
- Partially Supports. Some functionality meets this criterion, but not all.
- Does Not Support. The product fails this criterion.
- Not Applicable. The criterion does not apply to this product.
- Not Evaluated. You did not test against this criterion. Use sparingly. Buyers see this as a red flag.
What a single row looks like
Take WCAG criterion 1.1.1, "Non-text Content." A real VPAT row reads something like this:
1.1.1 Non-text Content (Level A): Partially Supports. All product images include descriptive alt text. The image upload component does not currently prompt content authors to provide alt text for user-uploaded images, which is a known limitation tracked in issue #4428 and scheduled for the Q3 2026 release.
The row tells the buyer three things: how you score, why you score that way, and what you are doing about it. That third part matters as much as the score.
Why honest scoring beats inflated scoring
The temptation is to write "Supports" against every criterion and submit a VPAT that says everything is fine. This backfires for two reasons.
First, sophisticated procurement teams cross-check VPATs against automated audits and screen reader testing. Discrepancies surface in due diligence and your contract dies in a meeting you are not invited to.
Second, an honest VPAT that admits "Partially Supports" with a remediation plan reads as competence. An inflated VPAT that claims full support and gets caught reads as either negligence or fraud, depending on the auditor's mood.
The buyer does not need a perfect product. They need a product that knows where its gaps are and has a credible plan to close them.
The four steps to producing a VPAT
Step 1: Run an audit
You cannot fill in a VPAT honestly without knowing your conformance level. Three options, in increasing order of cost and credibility:
- Automated scan. Tools like axe DevTools, Pa11y, and the AriaWAI built-in scanner cover roughly 30 to 40 percent of WCAG criteria. They catch low-hanging fruit fast.
- Internal manual review. A developer or designer with accessibility training works through the criteria with a screen reader and keyboard. This covers most of the rest.
- Third-party audit. Firms like Deque, Level Access, and the Bureau of Internet Accessibility deliver formal reports. Buyers in regulated sectors increasingly expect this.
For a first VPAT, automated plus internal manual is usually enough. Schedule a third-party audit before any seven-figure deal.
Step 2: Download the template
The ITI publishes the templates as Word documents. Pick the edition that matches your buyer:
- VPAT 2.4 WCAG (most common)
- VPAT 2.4 508 (US federal)
- VPAT 2.4 EU (European public sector)
- VPAT 2.4 INT (all three)
If you have an AriaWAI Pro plan, the dashboard generates a draft directly from your scan results, with the right edition, the right rows, and starter remarks based on what the scanner found.
Step 3: Fill in the rows
For each success criterion, write three things:
- The conformance level: Supports, Partially Supports, Does Not Support, Not Applicable, or Not Evaluated.
- A specific remark explaining why you scored that way. Mention the actual feature or component.
- If you score below "Supports", reference the tracked issue and the planned remediation date.
Resist the urge to write "Supports" everywhere. Resist the urge to write Not Evaluated against half the criteria. If you genuinely cannot evaluate a criterion, explain why in the remark column.
Step 4: Sign, date, and version
A VPAT is a point-in-time document. It must include the exact product version it describes, the date the evaluation completed, and the contact email of whoever is willing to defend its accuracy. Buyers will email that contact. Make sure it goes to a real person.
How long does this take
For a typical SaaS product, the first VPAT takes one to three weeks if you are doing it yourself, mostly because you are also fixing things you discover during the audit. Subsequent VPATs are quicker because you have a baseline and a remediation log.
A third-party audit firm will deliver a draft VPAT in two to four weeks for a fee in the four-figure to low five-figure range, depending on product complexity.
The AriaWAI Pro plan generates a draft VPAT from a built-in scan in about ten minutes. You still need to review, expand the remarks, and sign it. The scan does not replace human judgment, but it covers about 40 percent of the work.
Common mistakes
Three to avoid.
Submitting a VPAT for the wrong standards. A buyer who asked for Section 508 conformance will reject a WCAG-only VPAT. Read the procurement document carefully and pick the right edition. Use the INT edition if you are unsure.
Letting the VPAT go stale. A VPAT from twelve months ago against a product that has shipped four major releases is suspect. Refresh annually at minimum, after every major release in regulated sectors.
Treating it as marketing. A VPAT is a procurement document. Buyers and auditors read it adversarially. Marketing copy in the remark column reads as evasion.
Where AriaWAI fits
The AriaWAI Pro plan generates a starter VPAT from your scan results. You can use it directly for smaller deals, or as a draft for a third-party audit firm to refine. It will not pass a federal procurement review without human work, but it skips the first ten hours of the writing.
For a longer explanation of what an automated scan can and cannot tell you, read Do Accessibility Overlay Widgets Make Your Site WCAG Compliant?. For the install side of things, read How to Add an Accessibility Widget to Wix, WordPress, Webflow, and Shopify.