What Is a VPAT? Accessibility Conformance Reports Explained

If you sell technology, documents, training, or digital content to a government buyer, sooner or later a procurement officer will ask for “your VPAT.” Many vendors treat this as a formality and fill it in optimistically. That is a mistake, because a completed VPAT is a representation about your product that the buyer is entitled to rely on.

VPAT vs ACR — the distinction that matters

• A VPAT (Voluntary Product Accessibility Template) is the blank form, published by the Information Technology Industry Council (ITI).
• An ACR (Accessibility Conformance Report) is what you have once you have filled it in.

Almost everyone says “VPAT” for both, and that is fine in conversation. But if a solicitation asks for an ACR, it is asking for the completed, evaluated document — not the empty template with your logo on it.

“Voluntary” refers to the template being voluntary, not the accessibility. If it is in your contract, nothing about it is voluntary.

The four editions — pick the right one

The template comes in editions, and using the wrong one is a common and avoidable finding:

• WCAG Edition — WCAG success criteria only.
• Section 508 Edition — WCAG criteria plus the Revised Section 508 standards, including hardware, software, support documentation, and functional performance criteria.
• EN 301 549 Edition — the European standard, for EU public-sector procurement.
• INT (International) Edition — all of the above in one document.

If you are selling to a US federal agency, the WCAG Edition alone is usually insufficient. Section 508 covers territory WCAG never addresses — support documentation, closed functionality, hardware. A WCAG-only report leaves those rows unanswered, and a competent reviewer will notice.

How conformance levels are stated

Each success criterion gets one of these:

Term	What it means
Supports	Fully meets the criterion, without exception
Partially Supports	Meets it in some places, fails in others
Does Not Support	Does not meet it
Not Applicable	The criterion does not apply to this product
Not Evaluated	Only permitted for Level AAA criteria

Each rating carries remarks and explanations, and this is where an ACR earns or loses credibility. “Supports” with no explanation is weak. “Partially Supports — data tables in the reporting module lack header associations; scheduled for the Q1 release” is a document a buyer can actually work with.

The honesty problem

There is a strong temptation to write “Supports” everywhere. Resist it, for three reasons.

1. Buyers test. Agencies increasingly validate claims against the shipped product. A contradicted ACR is a credibility problem that outlives the specific procurement.
2. A candid ACR often wins. Contracting officers know no product is perfect. An honest report with a dated remediation roadmap frequently beats a suspiciously flawless one, because it is evidence you understand your own product.
3. You are creating a record. If accessibility becomes contested later, your ACR is the document showing what you told the buyer and when.

The most damaging entry is a confident “Supports” on something demonstrably broken in thirty seconds of keyboard testing. It invites the reviewer to distrust every other row.

What goes into producing one honestly

An ACR is the output of an evaluation, not a writing exercise. Doing it properly means:

1. Define the scope precisely — product name, version, date, and which components were assessed. An ACR covering “the platform” without version boundaries is close to meaningless.
2. Test with real assistive technology, not only automated scanners. Automated tools reliably catch a minority of WCAG issues; the rest need keyboard testing and a screen reader. See how to run a website accessibility audit.
3. Evaluate every applicable criterion, including the ones you expect to fail.
4. Write remarks that a non-engineer can act on — what fails, where, and what the user impact is.
5. Date it and own it. Include the evaluation methodology and who performed it.
6. Re-issue it when the product changes. An ACR two major versions stale is worse than none, because it is confidently wrong.

For buyers: how to read one critically

If you are on the procurement side, a few questions separate a real ACR from decoration:

• Is it dated, and does the version match what you are buying?
• Is it the right edition for your obligations?
• Are the remarks specific, or boilerplate repeated verbatim down the page?
• Does it claim “Supports” universally? Near-perfect reports deserve more scrutiny, not less.
• Was it evaluated by someone independent of the sales team?
• Does it cover the documentation and support channels, not only the interface?

An ACR does not transfer your obligation to the vendor. If you are a Title II entity, you remain responsible for the accessibility of what you deploy, whoever built it. See Section 508 vs ADA vs WCAG for who is actually on the hook.

Where documents fit

One consistently overlooked scope question: if your product generates or distributes documents — reports, statements, exports, courseware — those documents are in scope too. A conformant interface that emits untagged PDFs has an accessibility problem that an interface-only evaluation will miss entirely.

See our guide to PDF remediation and making Office files accessible.

Getting help

Taika provides Section 508 remediation, accessibility assessments, PDF & document accessibility, and accessible video.

If you need an evaluation behind a conformance report — or a second opinion on one a vendor handed you — request an assessment.