VPAT template — the practical guide

What is a VPAT

VPAT is a document format published by the Information Technology Industry Council (ITI). It maps every accessibility success criterion of the relevant standards to your product, and you mark each one as Supports, Partially Supports, Does Not Support, Not Applicable, or Not Evaluated, with prose explaining the basis.

The completed VPAT is the Accessibility Conformance Report (ACR). In procurement language, “send us your VPAT” usually means “send us your ACR” — the terminology is sloppy but the document is the same.

Which version do you use

Current version is VPAT 2.5 (2024). It comes in five flavours depending on which standards your buyer references:

• VPAT 2.5 WCAG — for buyers asking only about WCAG conformance. Covers WCAG 2.0 + 2.1 + 2.2 success criteria.
• VPAT 2.5 508— for US federal buyers under the Revised Section 508 (2018+). Covers WCAG 2.0 AA plus the “Other 508” criteria.
• VPAT 2.5 EU — for EU buyers under EN 301 549 (2021). Covers WCAG 2.1 AA plus EU-specific clauses (ICT, real-time text, hardware).
• VPAT 2.5 INT — international, includes all of the above. Most commonly requested for global SaaS.
• VPAT 2.5 R— Revised Section 508 only, for federal buyers who don't need EU coverage.

If you don't know which: produce the INT version. It covers all three standards, most procurement teams accept it, and you don't maintain three documents.

Sections explained

A VPAT 2.5 INT has these sections:

1. Product information — name, version, contact, evaluation date, evaluation methodology. Be specific: “axle web app, v2.3, evaluated 12-Mar-2026 by external IAAP-CPACC certified auditor + axe-core 4.11 CI scans” beats “web app, internal review”.
2. Applicable standards — tick the standards your buyer cares about. Usually WCAG 2.1 AA + Revised 508 + EN 301 549. For federal-only, stick to 508.
3. Terms (definitions)— copy from ITI's template. Don't modify.
4. WCAG criteria table — every success criterion with conformance level (Supports / Partially / Does Not / N/A) and a remarks column. This is where you spend 90% of the effort.
5. Revised Section 508 criteria — only if covering 508. Most overlap with WCAG; the unique ones are the platform / hardware criteria.
6. EN 301 549 criteria — only if covering EU. WCAG 2.1 AA is embedded; the EU-specific criteria are about two-way voice communication, real-time text, ICT generally.
7. Functional Performance Criteria — outcome-based, one row per disability category (without vision, with limited vision, without hearing, etc.).

Evidence — what to attach

Procurement teams increasingly reject VPATs that just say “Supports” with no backing. Strong VPATs attach:

• Automated scan reports dated within the last 90 days (axe-core JSON output covering the product surfaces in scope). This is what most criteria like 1.4.3 (Contrast), 1.1.1 (Non-text Content), 4.1.2 (Name, Role, Value) get backed by.
• Human audit reportfrom a certified auditor (IAAP CPACC / WAS, DHS Section 508 trained, or equivalent) within the last 12 months. Required for the ~43% of WCAG criteria automated tools can't evaluate.
• Continuous CI evidence— a link to your CI pipeline showing accessibility scans run on every PR. This is the strongest defence against “but how do you know it's still compliant after the audit”. axle CI history is what we use.
• Published accessibility statementwith named contact and escalation process. The statement's URL goes in the VPAT's “Contact” row.
• Roadmap for “Partially Supports” items — when something doesn't fully conform, name the workaround and the remediation date. “Partial” with a credible date beats “Supports” that fails verification.

Common mistakes

• Marking everything “Supports” with no evidence. Procurement teams (especially federal) verify with their own automated scan. A scan that contradicts your VPAT kills the deal and your credibility.
• Marking everything “Does Not Apply”. Some criteria genuinely don't apply (3.3.6 if there's no error correction in your product), but more than 30% of “N/A” in a VPAT looks like avoidance.
• Outdated VPAT. If your last VPAT is over 12 months old, refresh it before sending. Procurement reads the date.
• No remarks column content. Empty remarks columns read as “we didn't look”. Even “Verified by axe-core 4.11 + manual VoiceOver test” is better than blank.
• Not signed. The completed VPAT should be signed by an officer of the company. Unsigned PDFs get rejected by US federal procurement automatically.

After the VPAT

Procurement is a checkpoint, not a destination. Many SaaS vendors produce a VPAT, win the contract, then quietly let the product regress over the next 12 months. By renewal time the regressions are baked in and the next VPAT looks materially worse.

The continuous-CI model prevents that. Every PR is scanned, every regression is caught at merge time, the next VPAT is a delta of improvements rather than a list of new failures. That's also what the EAA market-surveillance authorities, the FTC, and ADA plaintiff firms increasingly look for as evidence of ongoing diligence.

See also: accessibility audit guide (cost ranges, scope, choosing an auditor) and ADA demand-letter playbook (what to do in the first 48 hours if you receive one).