What a VPAT-Based Accessibility Conformance Report (ACR) Proves About Compliance

What a VPAT Is

The Voluntary Product Accessibility Template (VPAT) is a standardised reporting template developed by the Information Technology Industry Council (ITI). It translates accessibility standards into a structured set of criteria that a product or service can be tested against, row by row.

The current version, VPAT 2.5, comes in four editions, each matched to a different standard: WCAG, US Section 508, EU (built on EN 301 549), and INT — a combined edition covering all three. For an organisation operating in the EU, the EU edition is the relevant one, since it maps directly onto EN 301 549's technical clauses.

What an ACR Really Is

An ACR is what you get once a VPAT has been filled in with real testing results. The template itself is blank — a structure waiting for evidence. The completed, evidence-backed version is the Accessibility Conformance Report.

The VPAT isn't the only way to produce an ACR, though — it's just the format nearly everyone uses. Nothing in EU or US law requires the specific VPAT structure; an organisation could document conformance in its own format. In practice, almost nobody does, because the VPAT gives buyers and evaluators a consistent, comparable structure across vendors — reinventing that format product by product would make ACRs harder to read, not more credible.

That distinction matters more than it sounds: a VPAT is a format, not a claim. An ACR is the claim, made against that format, and it's only as credible as the testing behind it.

How Conformance Levels Work

An ACR doesn't work on a pass/fail basis. Each criterion gets one of these conformance levels:

• Supports — the product meets the criterion, with no known defects
• Partially Supports — some functionality meets it, some doesn't
• Does Not Support — the criterion isn't met
• Not Applicable — the criterion doesn't apply to this product
• Not Evaluated — reserved specifically for WCAG Level AAA criteria, since AAA conformance isn't required for reporting.

Every "Partially Supports" or "Does Not Support" result needs a remark explaining exactly what falls short. That's the real value of a well-built ACR: it gives a buyer or auditor a precise, criterion-by-criterion picture, not a single "accessible / not accessible" label.

What an ACR Doesn't Prove

An ACR is not a certification. Nobody audits or signs off on it externally by default — it's a self-reported document, and its accuracy depends entirely on who tested the product and how rigorously.

This is where the credibility gap actually lives. An ACR completed by the vendor itself, based on a quick internal review, carries far less weight than one built on an independent, standards-based evaluation — manual testing against EN 301 549's actual clauses, not just an automated scan mapped loosely onto the template.

If you're evaluating a vendor's ACR, the testing methodology section is worth reading as closely as the conformance results themselves. A report with vague or absent methodology is a red flag regardless of how many rows say "Supports."

Where This Fits Alongside EU Legal Requirements

Here's a distinction worth being precise about: an ACR is not the same document as the accessibility statement required by EU law.

Under the Web Accessibility Directive (WAD) (Directive 2016/2102), public sector bodies are legally required to publish an accessibility statement, in a specific format set out by the European Commission — covering conformance status, any known inaccessible content, and a feedback mechanism for users. The European Accessibility Act (EAA) (Directive 2019/882) doesn't reference the VPAT or ACR format at all.

An ACR isn't a substitute for that legally mandated statement, and it isn't itself required by either directive. What it does well is something the accessibility statement doesn't: give a detailed, criterion-level account of a specific product's conformance — genuinely useful in procurement, vendor evaluation, and as supporting evidence when demonstrating how you meet the standard behind your statement.

Why This Matters in Practice

If you're procuring digital products or services, asking for an ACR — and reading its methodology section critically — is one of the most direct ways to evaluate a vendor's actual accessibility work, rather than taking a marketing claim at face value.

If you're the one being asked for an ACR, the same logic applies in reverse: a report built on real EN 301 549 testing, with clear remarks on every partial or unmet criterion, is what actually holds up under scrutiny — not a self-graded checklist filled in quickly to close a deal.

What to Do Now

• Requesting an ACR from a vendor? Read the testing methodology section first — a report with no clear account of how testing was done is a weaker signal than the conformance results alone suggest.
• Producing your own ACR? Base it on real testing against EN 301 549, not just WCAG — the EU edition of the VPAT exists specifically because WCAG alone doesn't cover everything the standard requires.
• Don't confuse it with your accessibility statement. If you're a public sector body under the WAD, you still need the legally mandated statement — an ACR complements that, it doesn't replace it.
• Treat "Supports" with the same scrutiny as "Partially Supports". A report with no partial or unmet criteria at all is either a genuinely strong product, or a report that wasn't tested critically enough — the remarks column is where you'll be able to tell which.

For binding legal requirements, always check the current text of the WAD, the EAA, and the version of EN 301 549 currently cited in the Official Journal of the EU.