What is a VPAT?

Published September 14, 2026 · about a 6-minute read

A deal is moving along nicely, and then procurement sends a one-line email: "Please attach your VPAT." If your stomach just dropped because you don't have one — or don't know what one is — you're in good company. A VPAT is one of those documents nobody mentions until it's suddenly blocking a sale.

Here's what it is, which version you need, and how to fill it out without either torpedoing the deal or writing a check your product can't cash.

VPAT vs ACR: the two words people mix up

A VPAT — Voluntary Product Accessibility Template — is a blank standardized form maintained by the Information Technology Industry Council (ITI). It lists accessibility criteria and asks, for each one, how well your product meets it. When you actually fill it in for your product, the completed document has a different name: an Accessibility Conformance Report (ACR).

So "send us your VPAT" really means "send us your completed ACR." People say VPAT for both. The template is free to use and you don't need to be an ITI member.

The four editions — pick by who's buying

The current version is VPAT 2.5, and it ships in four editions. You pick the one that matches the standard your buyer cares about:

If you're not sure, the INT edition covers the most ground. All of them are built on the same WCAG success criteria underneath, so the testing work is shared.

Who actually asks for one

It started as a U.S. federal thing — Section 508 requires agencies to buy accessible technology, so vendors need an ACR to compete. But it has spread well past government. These days you'll get asked for a VPAT by universities and school districts, hospitals and health systems, large enterprises with their own accessibility policies, and increasingly European buyers pointing at EN 301 549. If you sell B2B software or a SaaS product, assume the request is coming eventually.

A VPAT isn't a compliance badge. It's a disclosure. Its whole value is that it tells the buyer the truth about what works and what doesn't.

The four words that make or break it

Every criterion in an ACR gets one of four conformance levels:

• Supports — the product meets this with no significant issues.
• Partially Supports — some functionality works, some doesn't. Explain what in the remarks.
• Does Not Support — the majority of this isn't met yet.
• Not Applicable — the criterion genuinely doesn't apply to your product.

The single biggest mistake I see is writing "Supports" down the entire column to look clean. Don't. A sophisticated buyer's accessibility team will test a few claims, find a "Supports" that isn't, and now every other line is suspect — and so is your honesty. A VPAT full of thoughtful "Partially Supports" entries with specific remarks reads as more credible, not less. And in a world where accessibility lawsuits keep climbing, a knowingly false ACR is exactly the kind of document you don't want with your signature on it.

How to actually produce one

A VPAT is only as good as the testing behind it, and that's the part people skip. You can't honestly fill in "Supports" for "keyboard accessible" if nobody has ever tabbed through the product. The real sequence:

1. Run an audit first. Automated scan for the machine-detectable failures, then manual keyboard and screen-reader testing for the rest. I broke down how to do this in the accessibility audit guide — the audit findings become your evidence for each line.
2. Map findings to the criteria. Use the WCAG AA checklist as the backbone; each success criterion maps to a row in the VPAT.
3. Write honest remarks. For anything short of "Supports," say what's affected and, ideally, that a fix is planned. Buyers reward candor plus a roadmap.
4. Date it and sign it. An ACR states the product version and the date tested. Which leads to the catch…

The catch: an ACR goes stale

A VPAT is a snapshot of one version on one date. Ship a redesign, and last quarter's "Supports" can quietly become "Does Not Support" — while your ACR still says otherwise on a buyer's desk. The teams that stay out of trouble re-test continuously so the report reflects the live product, not the product as it was six months ago. That's where ongoing monitoring earns its keep: the machine-detectable layer runs on every change, so regressions show up before they end up contradicting a signed document.

Start by seeing where your live pages actually stand — our free accessibility checker grades them against WCAG-based checks in seconds, so you know what your ACR would honestly say today before you write it.