What Is a VPAT? An ACR Guide

If you sell software to a government agency, a university, a hospital network, or a large enterprise, sooner or later a procurement officer will ask you for “your VPAT.” For many vendors this is the first time they encounter the document, and the request arrives with little explanation and a tight deadline. This guide demystifies the VPAT and the Accessibility Conformance Report (ACR) it becomes: what the document is, how the two terms relate, which of the four editions you should produce, how conformance is rated, and why an honest, evidence-based report is one of the most valuable accessibility assets your organization can own.

A VPAT is not a certificate, a badge, or a marketing claim. At its best it is a careful, criterion-by-criterion account of how your product measures up against recognized accessibility standards. At its worst it is a rubber-stamped fiction that exposes you to legal and reputational risk the moment a buyer’s accessibility team tests your product. The difference between those two outcomes is the testing behind the document — which is exactly where QualiBooth focuses.

What a VPAT actually is

VPAT stands for Voluntary Product Accessibility Template. It is a standardized document, created and maintained by the Information Technology Industry Council (ITI, through its ITIC arm), that vendors use to describe how an information and communication technology (ICT) product or service conforms to a set of accessibility standards.

The word “voluntary” is a little misleading today. The template originated to help vendors voluntarily disclose accessibility information to US federal buyers, but in practice completing one is now a hard requirement in countless procurement processes. The “template” part is more literal: the VPAT is a blank form with a defined structure — tables of success criteria, a column for conformance level, and a column for explanatory remarks.

Three things are worth fixing in your mind from the outset:

A VPAT describes a specific version of a specific product on specific platforms. A VPAT for “our app” with no version number is meaningless.
A VPAT is self-reported. No external body certifies it. That is precisely why the credibility of a VPAT depends entirely on the rigor of the testing behind it.
The current widely used template family is VPAT 2.5. Always work from the latest version of the ITI template rather than an old copy floating around your shared drive.

VPAT vs ACR: the difference that trips people up

People use “VPAT” and “ACR” interchangeably, but they are not the same thing — and understanding the distinction signals to a knowledgeable buyer that you take the process seriously.

A VPAT is the blank template. It is the empty form ITI publishes.
An ACR — Accessibility Conformance Report — is the completed document. Once you have filled in the template for your actual product, with real conformance ratings and remarks, the result is an ACR.

In other words, the VPAT is the cookie cutter and the ACR is the cookie. When a buyer asks for “your VPAT,” what they actually want is your ACR: the filled-in report. Most teams will keep saying “VPAT” in everyday conversation, and that is fine, but in formal documentation it is correct to label the finished file an Accessibility Conformance Report.

This matters for more than pedantry. A buyer who receives a file literally titled “VPAT 2.5 Template” with blank tables — something that happens more often than you would expect — immediately knows the vendor has not done the work. A properly completed ACR, named and dated for the product version it covers, communicates competence before the buyer reads a single row.

The four editions of the VPAT 2.5 template

One of the most common points of confusion is that the VPAT 2.5 template comes in four editions, each aligned to a different standard or combination of standards. Choosing the wrong edition can stall a deal or fail an audit, so pick deliberately based on where you sell.

1. WCAG edition

This edition evaluates your product against the Web Content Accessibility Guidelines only — typically WCAG 2.2 (or the version your buyer specifies, often at Level A and AA). It is the right choice when a buyer simply wants WCAG conformance information and has no statutory framework layered on top. It is also the leanest edition, which makes it a sensible starting point for products sold primarily into the private sector. If WCAG itself is unfamiliar territory, our WCAG compliance overview and our guide to making a website WCAG compliant explain the underlying standard.

2. Section 508 edition

This edition maps your product to the Section 508 standards used in US federal procurement. Because the Revised Section 508 standards incorporate WCAG 2.0 Level A and AA by reference, this edition includes the WCAG tables plus additional 508-specific requirements covering hardware, software, support documentation, and services. If you sell to any US federal agency — or to state agencies that mirror federal rules — this is usually the edition you need. See our Section 508 compliance guide for the regulatory context.

3. EU edition (EN 301 549)

This edition aligns to EN 301 549, the European harmonized standard for ICT accessibility that underpins public-sector procurement across the EU and increasingly the private-sector obligations introduced by the European Accessibility Act. EN 301 549 incorporates WCAG and adds requirements specific to the European context, including functional performance statements. If you sell into the European public sector — or need to demonstrate readiness for the European Accessibility Act — produce the EU edition.

4. INT (international) edition

The INT edition combines all three frameworks — WCAG, Section 508, and EN 301 549 — into a single document. It is the most comprehensive and the most work to produce, but it is invaluable for vendors selling across multiple markets, because one report satisfies buyers on both sides of the Atlantic. If your customer base spans the US public sector and Europe, the INT edition usually saves you from maintaining three separate documents.

When clients are unsure, we help them choose during scoping. Producing a single INT edition is often more efficient than discovering mid-deal that you have the wrong regional edition. You can read more about how we approach this on our VPAT reports service page.

Conformance levels: the heart of the report

Every applicable success criterion in an ACR receives one of a small set of conformance levels. Getting these ratings right — and resisting the temptation to inflate them — is the single most important part of the work.

Supports — the functionality meets the criterion with no significant accessibility barriers. This does not mean “perfect”; it means a user relying on assistive technology can accomplish the task without obstruction.
Partially Supports — some functionality meets the criterion but there are exceptions or known barriers. This is an honest and very common rating; the remarks column should explain exactly what works and what does not.
Does Not Support — the majority of the functionality does not meet the criterion. Again, the remarks should be specific.
Not Applicable — the criterion does not apply to the product (for example, criteria about audio content for a product that contains no audio).
Not Evaluated — used only in the Section 508 report’s Level AAA tables, since AAA evaluation is not required.

Two principles separate a credible report from a worthless one. First, the remarks column carries the real information. “Partially Supports” with no explanation is almost useless; “Partially Supports — date pickers are operable by keyboard but do not announce the selected date to screen readers; fix scheduled for v4.2” tells the buyer exactly what they need to know. Second, ratings must be earned by testing, not assigned by optimism. A criterion marked “Supports” should have been verified, ideally including testing by users of assistive technology.

Why honest, evidence-based VPATs matter

It is tempting to treat the VPAT as a box-ticking formality and mark everything “Supports” to clear procurement quickly. This is a serious mistake, for several converging reasons.

Procurement teams verify

Mature buyers — federal agencies, large universities, healthcare systems, banks — increasingly have accessibility specialists who do not take an ACR at face value. They spot-check claims by testing your product with screen readers and keyboards. When a “Supports” rating collapses under a five-minute screen reader evaluation, you do not just lose the row; you lose the buyer’s trust in the entire document, and often the deal.

Legal risk compounds

An overstated VPAT is a written representation about your product’s accessibility. In a jurisdiction with accessibility litigation exposure — under the ADA in the US, AODA in Ontario, or the European Accessibility Act in the EU — a document that claims conformance your product does not deliver becomes evidence against you. An honest ACR that candidly reports “Partially Supports” with a remediation timeline is far more defensible than an inflated one that claims perfection.

An honest report is more useful internally

A truthful ACR doubles as a backlog. Every “Partially Supports” and “Does Not Support” is a prioritized to-do item for your engineering team. Teams that treat the VPAT as a living inventory of accessibility debt make steady, measurable progress; teams that fake it accumulate hidden risk.

This is why a VPAT should never be confused with an accessibility overlay or a one-line “accessibility widget.” Overlays do not fix the underlying code, do not produce defensible conformance evidence, and cannot substitute for a real ACR. QualiBooth does not endorse overlays for exactly this reason — they create the appearance of compliance without the substance, which is the opposite of what an honest VPAT represents.

How to produce a VPAT, step by step

A reliable ACR is the product of a disciplined process. Here is the sequence we follow, and the one you should expect from any competent provider.

Define the scope. Identify the exact product, version, and platforms (web, iOS, Android, desktop) the report will cover. Decide which edition — WCAG, Section 508, EU, or INT — based on your target markets.
Run automated testing. Automated scanners are fast and excellent at catching certain categories of issues — missing alternative text, low contrast, unlabeled form controls. Our accessibility scanning software provides this baseline, and you can try it free with a quick scan. But remember that automation reliably detects only a portion of WCAG issues.
Conduct manual testing. The majority of success criteria require human judgment: meaningful focus order, logical reading sequence, sensible error messaging, accessible custom widgets. A thorough manual accessibility audit is non-negotiable for a credible report.
Test with assistive technology users. The most defensible ratings come from audits by people with disabilities who use screen readers, magnification, and switch devices daily. They surface real barriers that sighted testers miss.
Assign ratings and write remarks. Translate findings into Supports / Partially Supports / Does Not Support for each criterion, with specific, useful remarks.
Assemble and review the ACR. Format the completed report cleanly, label it with the product version and date, and have it reviewed for accuracy and consistency before it leaves the building.
Pair it with a remediation roadmap. A good provider hands you not just the report but a prioritized plan to move “Partially Supports” toward “Supports.”

If your team lacks the in-house expertise for steps two through five, that is the norm rather than the exception. This is precisely the work covered by our VPAT reports service and broader accessibility consulting. For a fuller picture of what consulting engagements involve, see our explainer on accessibility consulting.

Maintaining a VPAT over time

A VPAT is a snapshot of a moving target. The day you ship a new release, your ACR begins to drift from reality. Treating the document as a one-time deliverable is one of the most common — and most damaging — mistakes vendors make.

Update on material change. Any release that meaningfully alters the user interface or adds new functionality should trigger a review of the affected criteria.
Refresh at least annually. Even without major changes, standards evolve and buyers expect a recent date on the document. An ACR dated three years ago invites skepticism.
Tie it to ongoing testing. The most reliable way to keep an ACR truthful is to keep testing the product continuously. Recurring accessibility audits catch regressions before they invalidate your claims, so the report you hand to a buyer always matches the product they will test.

QualiBooth combines a scanning platform with expert human evaluation precisely so that the evidence behind your ACR stays current. The scanner watches for regressions between formal audits; the human testing keeps the nuanced, judgment-based ratings honest. You can compare our full range on the accessibility services page and review options on our pricing page.

Frequently asked questions

Is a VPAT legally required?

The template itself is voluntary, but providing one is frequently a mandatory condition of a purchase contract, especially in US federal and state procurement and across the EU public sector. Separately, the underlying accessibility obligations — Section 508, the EAA, the ADA — are very much mandatory, and a VPAT is how you demonstrate your position against them.

Can I complete a VPAT myself?

You can, and nothing prohibits self-completion. The risk is accuracy. A self-assessment written without rigorous testing — or with an incentive to look good — tends to overstate conformance, which creates legal exposure and erodes buyer trust the moment the claims are tested. Many organizations bring in an independent provider for exactly this reason.

How long does a VPAT take to produce?

It depends on the size and complexity of the product and the edition required. A single-platform web application might take a couple of weeks once testing is underway; a large multi-platform suite needing the INT edition takes longer. A scoping conversation gives you a realistic timeline.

What is the difference between WCAG conformance and a VPAT?

WCAG is the standard — the set of success criteria. A VPAT/ACR is the document that records, criterion by criterion, how your product performs against that standard (and, depending on the edition, against Section 508 and EN 301 549 as well). You need to actually meet WCAG to claim conformance; the ACR is how you communicate where you stand.

The bottom line

A VPAT, completed as an Accessibility Conformance Report, is far more than a procurement hurdle. Done honestly, it is a credible account of how your product serves people with disabilities, a defensible record that reduces legal risk, and a working backlog that drives real improvement. Done dishonestly, it is a liability waiting to be exposed.

The deciding factor is always the testing behind the ratings. If you need an ACR you can put your name to — one grounded in automated scanning, manual audits, and evaluation by people with disabilities — explore our VPAT reports service, or request a demo to see how QualiBooth produces reports that hold up under scrutiny.