VPAT Explained: What It Is and When You Need One

VPAT stands for Voluntary Product Accessibility Template. It's a standardized form, published and maintained by the Information Technology Industry Council (ITI) (opens in new tab), that a vendor fills out to describe how accessible their product is. You go through each accessibility requirement — a WCAG success criterion, a Section 508 provision — and state whether your product meets it, with a note explaining how.

The key word is the one people skip: voluntary. A VPAT is a self-report. Nobody hands it to you and nobody signs off on it. You write it about your own product, and it's exactly as accurate as you choose to make it. That's worth internalizing before you either request one from a supplier or produce one for a customer, because it changes how much weight the document actually deserves.

Buyers ask for VPATs because accessibility has become a purchasing requirement. Federal agencies are bound by Section 508, and universities, hospitals, banks, and large enterprises have adopted the same expectation in their procurement rules. The VPAT is how they compare vendors on paper before anyone signs. If you sell software, SaaS, or hardware into any of those markets, this document is a gate on your pipeline.

The current template is VPAT 2.x, and it ships in four editions depending on which standards your buyer cares about. Choosing the wrong one is the most common way a first VPAT gets bounced back:

• WCAG edition— reports conformance against the Web Content Accessibility Guidelines only. Best for a purely web-based product with no U.S. federal or EU angle.
• 508 edition— covers WCAG plus the U.S. Section 508 requirements. This is the one you need to sell to federal agencies and most U.S. public institutions.
• EU edition— maps to EN 301 549, the European standard referenced by the European Accessibility Act. Ask for this when your buyer is in the EU.
• INT (international) edition— combines all three. It's the most work to complete and the most flexible to hand out, which is why larger vendors default to it.

All four are built on the same underlying WCAG success criteria, so the bulk of the testing work carries across editions. If you're not sure which your customer wants, ask — it's a one-line email that saves a rewrite.

Not every website needs one. A VPAT is a procurement artifact, so you need it when someone is buying your product and their rules require it. In practice that means:

• You sell software, SaaS, hardware, or digital content to a U.S. federal agency— Section 508 effectively requires it.
• You sell to state or local government, public universities, or K–12 districts, which usually inherit 508-style rules.
• You're going through enterprise procurement or a security/vendor review at a large company, where accessibility is now a standard line item.
• You're a vendor to a regulated industry — healthcare, finance, education — where the buyer is managing their own compliance exposure.

If you run a small-business marketing site or a local e-commerce store, you almost certainly don't need a VPAT — but you do still need an accessible site. Your risk lives in ADA lawsuits and demand letters, not procurement forms, and the fix is the same underlying work either way: meet WCAG.

Here's the part vendors most want to shortcut, and the part you can't. A credible VPAT requires you to evaluate every applicable success criterion against your real product — and you cannot get there with an automated scan alone. Automated tooling reliably catches only roughly 30–40% of WCAG criteria: missing alt text, color-contrast failures, missing form labels, empty links, and other machine-detectable issues. The rest — keyboard operability, focus order, whether your alt text is actually meaningful, screen-reader behavior, logical reading order — needs a human. That's not a knock on automation; it's the honest division of labor between automated and manual testing.

So the practical workflow looks like this:

1. Establish an automated baseline. Scan your key page types and flows with a real engine — CompliaScan is built on axe-core (opens in new tab), the same open-source engine much of the industry trusts — to find and clear the machine-detectable third fast. Start with our free WCAG checker.
2. Do the manual testing. Walk your product with a keyboard only, then with a screen reader, and check every applicable criterion by hand. Work the WCAG checklist criterion by criterion so nothing gets skipped.
3. Record evidence per criterion. For each line, note how you tested and what you found. This is what turns a VPAT from a marketing sheet into a defensible record.
4. Write the ACR, then keep it current. Fill in the template edition your buyer wants, date it, and re-issue it after meaningful releases. A VPAT dated three years and forty deploys ago describes a product that no longer exists.

If this sounds like the same work as a proper accessibility audit, that's because it largely is. The VPAT is the report; the audit is the work that earns it.