A VPAT (Voluntary Product Accessibility Template) is the procurement-standard document for declaring accessibility conformance of a software product. Government buyers, large enterprises, and increasingly mid-market customers require one. Here is how to write one that holds up.
What a VPAT is (and is not)
A VPAT is a structured self-disclosure of how your product conforms to specific accessibility standards. It is NOT a certification — there is no certifying body. It is a vendor-issued statement, completed using the ITI/INCITS template (current version: VPAT 2.5 Rev 508, published by the Information Technology Industry Council).
An ACR (Accessibility Conformance Report) is the completed VPAT for a specific product version. The terms are often used interchangeably.
The four standards a VPAT 2.5 covers
- Section 508 — US federal procurement (mandatory for federal contracts)
- WCAG 2.0 + 2.1 + 2.2 — Web Content Accessibility Guidelines, Level A, AA, AAA
- EN 301 549 — EU equivalent (EAA, public sector)
- Section 504 — Rehabilitation Act program accessibility
For each applicable criterion across these standards, you declare a conformance level.
The five conformance levels
| Level | Meaning |
|---|---|
| Supports | The product fully meets the criterion. |
| Partially Supports | The product has some support but with known limitations. Remarks must describe them. |
| Does Not Support | The product does not meet the criterion. |
| Not Applicable | The criterion does not apply (e.g. video criteria on a product with no video). |
| Not Evaluated | Not assessed (acceptable only for AAA criteria; not acceptable for A or AA). |
The five steps to write a VPAT
1. Download the current template
From itic.org/policy/accessibility/vpat. Use VPAT 2.5 Rev 508 (the latest stable version as of 2026). Word format is the standard.
2. Run a thorough accessibility audit
This is the substantive work. Pair automated scanning (AccessProof, axe-core, Lighthouse) with manual review (keyboard navigation, screen reader testing) for every criterion. Automated catches ~30-40%; manual catches the rest.
Document evidence per criterion: WCAG 1.4.3 contrast — link to the AccessProof PDF showing contrast pass. WCAG 2.1.1 keyboard — link to a video or test report.
3. Fill in product details
Product name, version, vendor info, date of evaluation, evaluator info (in-house team, external consultant, or both). Be specific about the product version — VPATs need updates per major release.
4. Complete each applicable table
Three tables to fill: WCAG 2.x, Section 508 chapter 5, Section 508 chapter 6. For each criterion: conformance level + remarks (explanations, especially for "Partially Supports" or "Does Not Support").
Be honest. Procurement teams and disability advocates routinely cross-check VPAT claims against the actual product. False claims of "Supports" damage credibility and legal posture more than honest "Partially Supports" with a remediation timeline.
5. Add remediation plan for known issues
"Partially Supports" criteria deserve a remarks line with the planned fix and target date. This is what procurement teams want to see — not just current state, but trajectory.
Common mistakes
- Claiming "Supports" without testing. Procurement teams cross-check.
- Outdated VPAT. Updates are needed per major release, at minimum annually.
- "Not Evaluated" for AA criteria. Acceptable for AAA only. AA must be assessed.
- Missing remarks for "Partially Supports". Always explain.
- VPAT for the wrong scope. Each product gets its own VPAT — not the whole company.
How AccessProof fits into the VPAT workflow
AccessProof produces the underlying WCAG audit evidence — timestamped PDF, per-element selectors, criterion-mapped findings — that goes into the WCAG section of a VPAT. Many SaaS teams use AccessProof for the automated portion and pair with a freelance accessibility specialist for manual review on critical flows.
Run a free WCAG audit on your product to see what AccessProof captures. For scheduled scans and PDF archives for ongoing VPAT maintenance, see Starter and Pro plans.