VPATs & Accessibility Conformance Reports

VPAT vs ACR: The Template and the Report

The VPAT (Voluntary Product Accessibility Template) is a free template published by ITI, the Information Technology Industry Council. On its own it is a blank form: a structured list of accessibility criteria with empty columns waiting for answers.

An ACR (Accessibility Conformance Report) is what the VPAT becomes once a vendor fills it in for a specific product: a completed report stating, criterion by criterion, whether the product supports each requirement, with remarks explaining each determination. The template is the blank form; the ACR is the report.

In practice the vocabulary is sloppy. Buyers say “send me your VPAT” when they mean the completed ACR, and most vendors answer in kind. That is fine as shorthand, as long as you understand what is actually being requested: not an empty template anyone can download, but a filled-in, dated, product-specific report backed by real testing.

Each criterion in an ACR gets one of a fixed set of conformance answers: Supports, Partially Supports, Does Not Support, Not Applicable, and Not Evaluated, the last of which is allowed only at WCAG Level AAA. Every answer needs a remark explaining how the determination was made. Empty remark columns are the single clearest mark of a low-quality ACR.

The Four Editions and How to Pick One

The current VPAT 2.x family comes in four editions, each mapping a different accessibility standard. Choosing the right one is not a technical decision so much as a market decision: the edition you need is determined by who is asking.

US federal buyers want the 508 edition, because Section 508 is the standard their procurement rules reference. European buyers increasingly want the EU edition mapping EN 301 549. Commercial buyers with no statutory hook often accept a WCAG edition. If you sell into more than one of these markets, the INT edition lets you maintain a single report instead of three parallel ones.

How to Read an ACR Before You Buy

An ACR is only useful to a buyer who reads it critically. Vendors write these documents to win deals, and the format makes optimism easy. A practical checklist:

• Check the edition and the date. Does the edition match the standard you care about? A WCAG-only report does not answer a Section 508 question. And an undated report, or one several years old, describes a product that may no longer exist.
• Check the product version it covers. A credible ACR names a specific release. If the report covers version 3 and you are buying version 5, ask for a current one.
• Scan for Partially Supports clusters on core criteria. Partial support on keyboard access, form labels, or contrast is not a footnote; those are the criteria that decide whether disabled users can operate the product at all. Clusters there deserve direct questions before contract signature.
• Be suspicious of 100% Supports with thin remarks. Real products have real defects. A report where every row says Supports and the remark columns are empty or boilerplate is more likely describing wishful thinking than testing.
• Ask for the testing methodology. Who tested, with what tools and assistive technologies, on which pages or screens? A vendor who can answer crisply probably did the work. A vendor who cannot, probably did not.

If accessibility documentation is becoming part of your purchasing process more broadly, our accessible procurement guide covers how to build these checks into RFPs and vendor reviews.

How to Produce an ACR That Survives Scrutiny

The order of operations matters more than anything else: testing comes first, and the document comes second. An ACR without testing behind it is fiction.

1. Test the product first. Combine automated scanning, manual testing against each criterion, and assistive technology testing with screen readers and keyboard-only operation. Automated tools alone cannot evaluate most criteria, so a scanner-only report is incomplete by construction. Our how-to-audit guide walks through the methodology, and the WCAG 2.2 checklist covers the criteria themselves.
2. Pick the right edition. Match the edition to your buyers: 508 for US federal, EU for European procurement, WCAG for commercial deals, INT when you need all three in one document.
3. Fill in per-criterion conformance with specific remarks. For each criterion, record Supports, Partially Supports, Does Not Support, or Not Applicable (Not Evaluated is allowed only at WCAG Level AAA), and write remarks that name components and known defects. “Date picker is not operable by keyboard; fix scheduled” is a useful remark. An empty cell is not.
4. Date and version the report against a specific release. State the product version tested, the date, and the testing approach. This is what lets a buyer connect the report to the thing they are actually buying.
5. Update it when the product changes materially. Redesigns, new modules, and major remediation efforts all invalidate old answers. A stale ACR erodes exactly the trust it was written to build.

One more credibility lever: who did the testing. Third-party-produced ACRs carry more weight with buyers than self-reported ones, because the incentives are cleaner. Our accessibility audit service produces exactly the automated, manual, and assistive technology testing an ACR needs behind it.

VPATs in Europe: EN 301 549 and the EAA

The VPAT conversation is often framed as a purely American, Section 508 story. That framing is out of date. The VPAT EU edition maps EN 301 549, the European accessibility standard, and European public procurement references that standard directly.

The European Accessibility Act raises the stakes further. As EAA obligations flow through supply chains, accessibility documentation is moving beyond government tenders into private-sector purchasing: companies that must meet accessibility requirements themselves start demanding evidence from their software vendors. The VPAT EU edition, as a structured EN 301 549 conformance report, is a natural format for answering those requests.

For vendors, the practical takeaway is simple: if European customers are on your roadmap, an ACR that speaks only Section 508 will not be enough. Either produce a VPAT EU edition alongside your US report, or use the INT edition and cover both markets, plus WCAG, in one document.

Limits: What an ACR Is Not

A VPAT or ACR is disclosure, not certification. There is no official accessibility certification body for WCAG, so no report, badge, or seal can formally certify conformance. An ACR does not make a product compliant with any law; it documents where the product stands, including where it falls short.

That limit is also the document's strength. An honest ACR that says “Partially Supports” in ten places, with specific remarks and a remediation plan, is worth more to a serious buyer than a perfect-looking report nobody believes. The goal is an accurate map of the product, not a marketing artifact.

It is also worth distinguishing the ACR from its public-facing sibling. An ACR is procurement-facing: a detailed, criterion-level report handed to buyers on request. An accessibility statement is public-facing: a page on your website telling users what to expect and how to get help. Most organizations selling software eventually need both; our accessibility statement guide covers the other half.

Frequently Asked Questions