A Voluntary Product Accessibility Template (VPAT) is a standardised document
published by the Information Technology Industry Council (ITI) used by vendors
to report how their products conform to accessibility standards. A completed
VPAT becomes an Accessibility Conformance Report (ACR) — the document buyers
evaluate when assessing whether a product meets their accessibility
procurement requirements.
[1]
US federal agencies are required by Section 508 of the Rehabilitation Act
to purchase accessible technology. Before procuring a product, they evaluate
the vendor's VPAT to determine whether it meets their needs. This makes
completing an accurate VPAT a commercial necessity for any vendor selling
software or technology to the US federal government or large enterprises
with similar procurement policies.
Enterprise buyers — particularly in financial services, healthcare, and
education — increasingly request VPATs as part of vendor due diligence
regardless of government involvement.
[2]
| Edition | Use when |
|---|---|
| VPAT 2.x WCAG | Buyer references WCAG only |
| VPAT 2.x Section 508 | Selling to US federal government |
| VPAT 2.x EU | Selling to EU public sector |
| VPAT 2.x INT | International sales — covers all three |
When in doubt, the INT edition is the safest choice as it covers all three
standards and is accepted by the broadest range of buyers.
Step 1 — Conduct a genuine audit
A VPAT based on guesswork or optimistic self-assessment will not survive
scrutiny from an experienced procurement team. Commission or conduct an
audit combining:
Step 2 — Complete the product information section
Include the product name, version number, evaluation date, and contact
details for accessibility queries. Keep this current — an ACR dated three
years ago covering a product that has changed substantially is not credible.
Step 3 — Select the correct conformance level for each criterion
For each WCAG success criterion and Section 508 requirement, select one of:
Step 4 — Write honest remarks
Every row where the answer is not "Supports" or "Not Applicable" must include
a remark explaining the specific issue and, ideally, a remediation timeline.
Vague remarks such as "some issues exist" are unhelpful. Specific remarks
such as "form error messages on the payment screen are not programmatically
associated with their inputs — remediation planned for Q3 2025" are credible.
[1]
Step 5 — Describe the evaluation methodology
Include a section describing how the product was tested. Buyers weight
VPATs tested by independent third parties more heavily than self-assessments.
At minimum, describe the tools used, the scope of testing, and any
limitations of the evaluation.
Marking everything as Supports without evidence. This is the most common
and most damaging error. Experienced accessibility procurement specialists
will identify it immediately and it damages credibility for all future
commercial relationships.
Using an outdated template. ITI publishes updated versions of the VPAT
as standards evolve. Always download the current version from the ITI website.
Covering only the web interface. If the product includes a mobile app,
desktop software, or documentation, these must be evaluated against the
relevant chapters of EN 301 549 or Section 508 separately.
Not updating after product changes. A VPAT is a snapshot. Significant
product releases should trigger a review and update of the ACR.
Last edited Apr 7, 2026, 7:24 PM · P**** J****