What Is a VPAT, and Do You Actually Need One? A Vendor's Guide to Accessibility Conformance Reports

Short answer: A VPAT, the Voluntary Product Accessibility Template, is a free reporting template published by the Information Technology Industry Council (ITI). It is not a certificate and no certification body stands behind it: the filled-out template is an Accessibility Conformance Report (ACR), a structured self-declaration of how your product performs against Section 508, EN 301 549 or WCAG. You need one mainly when buyers ask for it: US public-sector procurement, EU tenders that reference EN 301 549, and a growing share of enterprise vendor reviews. An honest ACR that says "Partially Supports" with specific remarks is more credible, and wins more deals, than a suspiciously perfect "Supports" column.

This article is general information for software vendors, not legal advice. Procurement rules differ by country, agency and contract, so confirm specific obligations with qualified counsel.

Table of contents

• VPAT vs ACR: the template and the report
• The four editions: 508, EN 301 549, WCAG and INT
• When you actually need one
• Anatomy of an ACR: tables and the conformance vocabulary
• Honest language wins deals
• VPAT vs accessibility statement
• Keeping it current: versioning and re-issuing
• How cerez.io drafts an ACR from scan data
• Frequently Asked Questions
• Sources

VPAT vs ACR: the template and the report

The procurement email usually says: "As part of our vendor review, please send us your VPAT." Strictly speaking, that request names the wrong artifact.

The VPAT is the blank template. ITI, the Information Technology Industry Council, publishes it for free, maintains its revisions, and holds the trademark on the name. The V stands for voluntary: no law anywhere obliges a vendor to fill one out, and no authority audits, stamps or certifies the result.

The ACR, the Accessibility Conformance Report, is what exists once you have completed the template for a specific product and version, and it is the document you actually attach to the reply. In practice everyone says "VPAT" when they mean "an ACR produced on the VPAT template", and fighting that habit is pointless; what matters is reading the request correctly:

• If a buyer asks for "your VPAT", they want your completed ACR for the product they are evaluating, not a link to ITI's template.
• If you have conformance documentation under another name (an internal audit report, a WCAG summary), do not answer "we have no VPAT": say what you have, since it often contains most of what the buyer needs.
• An ACR is a self-declaration: its credibility comes from the quality of its remarks and the rigor of the evaluation behind it, because no external seal exists.

That last point cuts both ways: nothing stops a vendor from producing an inflated ACR, which is why experienced reviewers read them skeptically, and why honest, specific language is a competitive asset.

The four editions: 508, EN 301 549, WCAG and INT

ITI publishes the template in four editions, each mapping to a different standard or combination; picking the right one is mostly a question of who is asking.

How to tell which one a buyer actually means:

• A US federal RFP or a "Section 508 compliance" question means the 508 edition. Section 508 governs ICT that US federal agencies procure, develop, maintain and use.
• Any mention of EN 301 549 points to the EU edition. EN 301 549 is the harmonized European standard for ICT accessibility; for web content it incorporates WCAG (current versions align with WCAG 2.1 Level AA), alongside software, documents and support services. It is the reference you will meet in European public tenders and in European Accessibility Act conversations.
• A generic "do you have accessibility documentation?" from a commercial buyer is usually satisfied by the WCAG edition, which is also the shortest to produce.
• When you sell into both the US and Europe, the INT edition answers every variant of the question with one document, at the cost of length: it reports against three overlapping standards at once.

If you are unsure, ask which standard the review is based on; the question is normal and prevents a 40-page INT report for a reviewer who needed two WCAG tables.

When you actually need one

A VPAT-based ACR is a procurement document: you need one when a purchasing process asks for it, and three situations cover almost every real request.

1. US public-sector procurement. Section 508 of the Rehabilitation Act requires US federal agencies to make the ICT they procure accessible, and agencies commonly ask vendors for an ACR during market research and proposal evaluation. Many US states, school districts and universities apply similar requirements in their purchasing policies. If government or education money is anywhere in your pipeline, an ACR is effectively a prerequisite for being evaluated seriously.

2. EU tenders and enterprise buyers referencing EN 301 549. European public-sector tenders reference EN 301 549 as the accessibility benchmark, and since the European Accessibility Act became applicable in June 2025, in-scope private buyers have started pushing conformance questions down their supply chains: a SaaS product embedded in a bank's onboarding flow or an e-commerce checkout is part of the buyer's own conformance story. Our EAA compliance checklist covers this dynamic from the buyer's side.

3. Enterprise vendor reviews. Accessibility questions are migrating into the vendor questionnaires that already cover security and privacy, and large companies with internal accessibility commitments increasingly ask for an ACR before signing. The document is rarely a hard gate, but "we have a current ACR, here it is" moves the review along in a way that "we take accessibility seriously" does not.

When a statement is enough instead. If no procurement process is asking, you generally do not need an ACR: a consumer-facing product with no public-sector or enterprise sales channel is better served by a public accessibility statement, and the EAA's information duties are statement-shaped disclosures anyway. The difference deserves its own section below.

Anatomy of an ACR: tables and the conformance vocabulary

Every ACR built on the VPAT has the same skeleton, and reviewers navigate by it.

The header block identifies the report: product name and version, report date, the edition and template revision used, a description of the evaluation methods (automated scanning, manual expert testing, screen reader testing, and the tools used), and contact information. A missing or vague "evaluation methods" entry is the first thing a skeptical reviewer notices.

The criteria tables are the body: one table per applicable standard section, and for WCAG one table per conformance level with one row per success criterion. Each row carries a conformance level from the template's fixed vocabulary and a remarks column explaining it.

The vocabulary is defined by the template, and using it precisely is half the craft:

That last restriction surprises many first-time authors: a finished ACR cannot mark a Level A or AA criterion "Not Evaluated". The template quietly enforces rigor: a real ACR requires an evaluation pass over every A and AA criterion, not just those your tooling covers.

A well-formed row looks like this (illustrative example, not from a real product):

1.4.3 Contrast (Minimum), Level AA. Conformance: Partially Supports. Remarks: Body text and primary controls meet 4.5:1. Placeholder text in the search field (3.2:1) and the secondary button on the billing page (4.1:1) fall short. Fix scheduled for release 4.2 (Q4 2026).

Specific locations, measured ratios, a dated plan: that is the register the whole document should be written in.

Honest language wins deals

It is tempting to treat an ACR as marketing collateral and fill the conformance column with "Supports" all the way down. That is a mistake: reviewers who read ACRs professionally have seen hundreds of them, and a flawless column is a red flag, not a green one.

What reviewers actually do with your ACR:

• Spot-check it against the product. An accessibility officer opens your demo or trial, runs a keyboard-only pass and a screen reader over the core flows, and compares the findings with your claims. One discovered contradiction taints every other row.
• Read the remarks before the ratings. Empty remark cells next to "Supports" suggest nobody evaluated anything; specific remarks, even ones documenting defects, signal a real evaluation.
• Look at dates and versions. An ACR for a version three major releases old, or with no date at all, tells them your accessibility process is not live.

A credible "Partially Supports" with precise remarks survives the spot-check, demonstrates that you actually know your product's accessibility posture, and gives the buyer's accessibility team something they can plan around: known limitations with dates are manageable, surprises discovered after signature are escalations.

Overclaiming also carries real risk: an ACR frequently becomes part of the contract file, a materially false conformance claim can resurface in disputes, and for vendors selling into the US, inflated accessibility claims presented as fact are the kind of representation deceptive-practice rules exist for. The safe rule: write only what your evaluation evidence supports, and date it.

VPAT vs accessibility statement: different documents, different audiences

Vendors often conflate the two, so it is worth stating the split plainly.

An ACR is a procurement document. It is per product and per version, structured as criteria tables, written for a professional reviewer, and usually delivered privately in a sales or tender process.

An accessibility statement is a public document. It is per website or service, written in plain language for end users, and it states your conformance status, known limitations, accessible alternatives and a way to report barriers. EU public-sector bodies publish one in a mandated model form, and EAA-scope services owe statement-shaped information to consumers.

You may well need both: the statement on your website, the ACR in your data room. They must agree, since a reviewer who finds your public statement saying "partially conformant" and your ACR implying near-perfection will trust neither. We cover the statement side in our guide to writing an accessibility statement, and you can produce one with our accessibility statement generator.

Keeping it current: versioning and re-issuing

An ACR describes a product at a point in time, and products move; with no official refresh interval, currency is your own discipline:

• Tie the ACR to a product version. The header names the version evaluated; when the product's UI changes materially, that ACR no longer describes what buyers receive.
• Re-issue after major releases. A redesign, a new core module or a front-end framework migration each justify a fresh evaluation; minor releases usually do not, unless they touch flows your remarks reference.
• Review on a calendar anyway. Annual review is common practice even without major releases, because content drift and dependency updates erode conformance quietly; regular automated scanning between formal evaluations tells you when drift is happening.
• Keep the old versions. Buyers who signed against ACR v2 may ask for it years later; an archive of dated reports is part of your compliance file.

A dated, versioned ACR that is eleven months old and honest beats an undated one that claims perfection, every time.

How cerez.io drafts an ACR from scan data

The slowest part of writing a first ACR is mechanical: walking every WCAG 2.2 Level A and AA criterion and establishing what you currently know about it. This part cerez.io automates, with deliberately conservative language.

The accessibility scanner checks your site against WCAG 2.2 and records violations per success criterion. From the latest completed scan, the VPAT draft builder generates a criteria table using three rules:

• Criteria the automated checks genuinely cover, with no open findings, are marked "Supports (automated)", explicitly labeled as automated verification only.
• Covered criteria with open findings are marked "Partially Supports", with the finding count carried into the row.
• Criteria the scanner cannot meaningfully test (roughly 60 percent of Level A and AA, in line with what automated testing can honestly verify) are marked "Not Evaluated" with a manual-review note.

Those "Not Evaluated" rows are the point, not a gap in the tool: they are your worklist. A finished ACR cannot leave A and AA criteria unevaluated, so the draft shows exactly which criteria still need human judgment, keyboard testing and screen reader passes. The output is a draft to review and complete, not a certification, and no automated tool can honestly offer more. What it saves you is the mechanical half: the criteria inventory, the current findings, and dated scan evidence for the evaluation-methods section. You can see how scanning and reporting fit together on our features page.

Frequently Asked Questions

Is a VPAT legally required?

Short answer: No. The template is voluntary by definition, and no law requires any vendor to publish an ACR. The practical obligation comes from procurement: US federal buyers, EU tenders referencing EN 301 549 and enterprise vendor reviews routinely require one as a condition of being considered.

Who can fill out a VPAT, do I need an external auditor?

Short answer: Anyone with genuine accessibility evaluation competence can complete it, including your own team; there is no licensing scheme and no certification body. The real requirement is testing skill, not credentials. Many vendors commission a third-party audit for credibility or capacity, but the resulting ACR is still a self-declaration signed by you.

Which edition should a SaaS company choose?

Short answer: Follow your buyers. US public-sector and education pipeline: the 508 edition. European tenders and EAA-driven requests: the EU edition (EN 301 549). Purely commercial buyers asking about WCAG: the WCAG edition, the leanest. Selling across the US and Europe: the INT edition, one document at the cost of length.

How often should an ACR be updated?

Short answer: There is no mandated interval. Re-issue after major releases or UI changes that invalidate your remarks, and review on a fixed calendar (annually is common) even without big releases; once the shipping product no longer matches the evaluated version, the report has expired.

Is a VPAT the same as an accessibility statement?

Short answer: No. An ACR built on the VPAT is a per-product procurement document with criteria tables, delivered to professional reviewers; an accessibility statement is a public, plain-language page about a website or service, aimed at end users and regulators. Many vendors need both, and the two must tell the same story.

Sources

• ITI, Voluntary Product Accessibility Template (VPAT)
• Section508.gov, Voluntary Product Accessibility Template
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2
• W3C, Web Content Accessibility Guidelines (WCAG) 2.1
• ETSI, EN 301 549 v3.2.1: Accessibility requirements for ICT products and services (PDF)
• Directive (EU) 2019/882, the European Accessibility Act

The fastest route to a credible ACR starts with knowing where you stand. Start free with an automated WCAG 2.2 scan and a draft conformance table for your site, or compare plans on the pricing page. This article is for information purposes and is not legal advice.