VPAT and ACR: what enterprise buyers are asking for, and how to produce one

At some point in a deal with a university, a hospital system, a bank, or any US federal agency, someone in procurement asks for your VPAT. It is usually the first time the question has come up, it usually arrives with a deadline, and the document is not something you can reasonably fill in during the afternoon it is requested.

Here is what is actually being asked for, and how to produce something that survives review.

VPAT and ACR are two different things

The Voluntary Product Accessibility Template is a blank template published by the Information Technology Industry Council. It is free, it is a Word document, and on its own it says nothing about your product. Once you complete it with your own testing results, the finished document is an Accessibility Conformance Report.

So the buyer says VPAT and means ACR. Section508.gov puts it plainly: the ACR is the report that records how a product meets the standards, and the VPAT is the most common method for completing one.

Who asks for one, and why

The request almost always comes from procurement rather than from the team that wants your product, and it is usually driven by an obligation the buyer carries rather than curiosity about you. US federal agencies must buy accessible ICT under Section 508, so their contracting officers ask every vendor. State and local government buyers are working toward the Department of Justice's Title II web rule, which sets WCAG 2.1 Level AA as the standard and compliance dates in April 2027 for entities serving 50,000 or more people and April 2028 for smaller ones. Universities, hospital systems, banks and large retailers ask because their own vendor-risk process tells them to.

That matters for how you respond. The buyer is not trying to catch you out; they are trying to close a checklist item and record that they asked. A specific, honestly-scoped report with visible gaps clears that bar. A report that reads as marketing does not, because it gives the reviewer nothing to file.

The four editions, and which one to send

ITI publishes four editions so vendors can report against the standard the buyer actually cares about. The current release is VPAT 2.5Rev, published 24 April 2025.

• VPAT 2.5 WCAG — WCAG only, covering 2.0, 2.1 and 2.2. Send this when the buyer is a private company, or when the request just says 'we need your accessibility documentation' with no standard named. Of the four, only this edition and the INT edition report against WCAG 2.2.
• VPAT 2.5 508 — the Revised Section 508 standards, which incorporate WCAG 2.0 Level A and AA. Send this to US federal agencies and to anyone selling into a federal contract. Note the version: Section 508 still references WCAG 2.0, not 2.1 or 2.2, and reporting against the wrong one is a common error.
• VPAT 2.5 EU — EN 301 549, incorporating WCAG 2.1. Send this for EU public-sector procurement and, increasingly, for EU enterprise buyers since the European Accessibility Act.
• VPAT 2.5 INT — all three standards in one document. Send this if you sell into more than one of those markets and would rather maintain one report than three.

The four conformance levels

For each success criterion you declare one of four levels: Supports, Partially Supports, Does Not Support, or Not Applicable. Version 2.5 also gives you a remarks and explanations column, and that column is where the document earns or loses its credibility.

Partially Supports is not an admission of failure — it is the normal, honest state of most products, and a reviewer reading a report that says Supports on every row will assume nobody tested anything. What a reviewer is looking for is whether you know where you stand and whether the gaps are described specifically enough to assess the risk.

The remarks column is the document

The conformance level is one word. The remarks and explanations column is where a reviewer decides whether to believe it, and it is the most common place an ACR falls apart. Three habits separate a usable remark from a useless one.

• Name the component and the context, not the criterion. 'Partially Supports — the date picker in the booking form is operable by mouse only; keyboard users can type a date into the field, which is the documented alternative' is assessable. 'Partially Supports — some components have keyboard issues' is not.
• Say what the user experiences, not what the code does. A reviewer is modelling risk to a person, so describe the barrier and any workaround.
• Include the remediation position where you have one. 'Scheduled for the Q1 release' is legitimate information and reviewers weigh it. An unqualified gap with no stated intent reads as abandoned.

How to fill one in

1. Define the scope precisely. Which product, which version, which platforms, which URLs or screens. A report that covers 'our website' without saying what was tested is not usable.
2. Test against the standard, criterion by criterion. Automated scanning clears the mechanical rows quickly; the rest need a person with a keyboard and a screen reader. Both halves get recorded.
3. Record the method. Reviewers want to know what tools, what assistive technology, what browsers, and what pages. Vague methodology is the most common reason a report gets sent back.
4. Write the remarks per row, not per report. 'Supports' with no note is fine. 'Partially Supports' with no note is not — say which component fails, in what context, and what the user experiences.
5. Do not leave rows blank. Not Applicable is a valid answer when the criterion genuinely cannot apply; an empty cell reads as unexamined.
6. Date it and name an owner. An undated ACR is treated as stale on arrival.

What gets a report rejected

• Supports on every criterion, with no remarks column filled in.
• The wrong edition — a WCAG-edition report sent to a federal agency that needs the Revised 508 edition.
• No test methodology, so the reviewer cannot tell whether a human was involved.
• A date two or three product versions ago.
• Scope written so broadly that the reviewer cannot map it to the thing they are buying.
• Declaring conformance for third-party components you embed but never tested.

How often to update it

Section508.gov's guidance is that every time your product is changed or updated — a version change, a bug fix — an updated ACR may be required. In practice, most vendors regenerate on a fixed cadence and out of band after any significant UI change, because the cost of a stale report is a deal that stalls in review.

Tie it to your scanning schedule rather than treating it as an annual project. If the underlying audit is running monthly, the report is a few hours of writing rather than a re-test from scratch.

Where AdaChecked fits

The Site Scanner produces an ACR / VPAT compliance report on the Pro and Business plans, generated from your latest scan so the criterion-level rows reflect what testing actually found rather than what someone hoped. The Shopify app's Pro plan produces an ACR-lite report for stores facing the same request from a wholesale or marketplace partner. Both are on the pricing page.

A generated report covers the automated half well and gives you the structure and the scope statement. The judgment rows — is that alt text meaningful, does that error message actually help — still want a human reviewer, and the report marks which rows those are rather than filling them in silently.

← All posts