VPAT and ACR: What Procurement Reviewers Check First

Animated explainer: what a VPAT and an Accessibility Conformance Report are, how buyers verify them, the six things a reviewer checks first, and how to produce a report that survives review.

Read the transcript

Your VPAT is not a certificate. Buyers are checking it. Procurement has asked for your VPAT. You have ten days, a template from the internet, and the urge to write "Supports" in every row. Don't. A report that claims everything is the easiest kind to take apart. A VPAT is a template, published by the Information Technology Industry Council. The current version is 2.5Rev. Filled in, it becomes an Accessibility Conformance Report, an ACR. That is what the buyer reads. Three facts are widely misunderstood. There is no certification. Nobody reviews a completed report. And there is no pass/fail score. So an ACR is the vendor's own statement about its own product, with nobody checking in between. So careful buyers don't take it on trust. Federal guidance tells them to test the product against what the report says. "Partially Supports" and "Does Not Support" both mean it does not conform. "Not Evaluated" gives no assurance at all. That test is often Trusted Tester: manual, criterion by criterion, with the keyboard. If your report says "Supports" for keyboard access, and the reviewer cannot reach your date picker without a mouse, they stop weighing one gap. They start weighing whether to believe anything else in it. Why are more buyers asking? Federal agencies have for years, against WCAG 2.0 AA. The bigger change is state and local government. A 2024 rule under ADA Title II sets WCAG 2.1 AA for their websites and apps. In April 2026, the compliance dates moved back by a year. April 2027 for entities serving 50,000 people or more. April 2028 for smaller ones. The technical standard did not change. The rule also covers what a public entity provides through vendors. A county that buys your platform cannot hand its obligation to you. It can ask for evidence before it signs. The ACR is that evidence, and contracts signed this year will still be running in 2027. Six things a reviewer checks first. One. Every row says "Supports". A complex product that meets every criterion is rare. A clean column reads as a report nobody tested. Two. The wrong edition. The 508 edition covers WCAG 2.0. The EU edition, 2.1. The WCAG and INT editions, 2.2. Send 508 to a Title II buyer, and it never mentions the 2.1 criteria they are bound by, like Reflow and Non-text Contrast. Three. "Evaluation methods" says "automated scan". Then most criteria were never examined. A scanner cannot tell whether focus order makes sense, or whether an error message describes the error. Name the assistive technology, the browsers, and the manual method. Four. "Not Applicable", used to hide things. If there is an onboarding video, the captions criterion applies. If there is a sign-in timeout, Timing Adjustable applies. A reviewer will look for exactly these. Five. Empty remarks. "Partially Supports", with nothing in the remarks column, tells the buyer nothing. Say where the gap is and what it affects. "Data table headers are not associated in the reporting module. Other modules conform." Six. An old date and no version number. A report from three releases ago describes software the buyer is not buying. And a remark under 4.1.1, a criterion removed in WCAG 2.2, says the report was copied from an old template. A specific "Partially Supports" is a stronger sales document than a blanket "Supports". A gap you disclosed shows a vendor who knows its product. A gap you hid gives the reviewer a reason to doubt the rest. Name the gap, state a plan, and commit to a date only if you can meet it. To produce one that survives review. Fix the scope: product and version. Test manually, with the keyboard, a screen reader, and zoom at 400%. Record evidence per criterion. Match the edition to the buyer. Write remarks a reviewer can verify. Reissue it every major release. None of this makes a product compliant on its own. It gives you a documented, defensible position. If a buyer has asked, start with the testing, not the template. Manual testing and conformance reports run through EcomBack. The full article is at ranaahson.com.

Somebody in procurement has asked for your VPAT. You have ten days, a template from the internet, and a strong temptation to write “Supports” in every row.

Don’t. An accessibility report that claims everything is the easiest kind for a buyer to take apart, and buyers are increasingly told to check.

This is what a VPAT actually is, what a reviewer looks for, and why an honest report with gaps in it usually holds up better than a perfect-looking one.

A VPAT is a template. What you send is a claim.

The Voluntary Product Accessibility Template is published by the Information Technology Industry Council (ITI). The current version is VPAT 2.5Rev, released in April 2025. Once you fill it in, it becomes an Accessibility Conformance Report, or ACR. The ACR is the document a buyer reads.

Three facts about it are widely misunderstood, and ITI states all three on its own VPAT page:

There is no VPAT certification. Nobody can certify you against it.
ITI does not review or approve completed reports. Nobody checks your ACR before it reaches a buyer.
There is no pass/fail score. The report describes conformance one criterion at a time.

So an ACR is a statement made by the vendor, about the vendor’s own product, with nobody checking it in between. That is exactly why careful buyers do not take it on trust.

Buyers are told to verify you

The federal government’s own guidance is explicit. Section508.gov’s page on understanding vendor accessibility claims tells purchasers to run independent conformance validation testing against what the ACR says. For web products it points to Baseline-aligned test processes such as Trusted Tester, the Department of Homeland Security’s manual testing method.

It also spells out how the conformance terms are read. “Partially Supports” and “Does Not Support” both mean the product does not conform to that requirement. “Not Evaluated” gives no assurance at all.

I am a DHS Trusted Tester, so I know what that check looks like from the other side of the table. It is criterion-by-criterion manual testing, done with the keyboard and the inspection tools, page by page. It is designed to find exactly what an optimistic ACR leaves out.

If your report says “Supports” for SC 2.1.1 Keyboard and the reviewer cannot reach your date picker without a mouse, they are no longer weighing one gap. They are weighing whether to believe anything else in the document.

Why more buyers are asking

Federal agencies have asked for these reports for years. Under the Section 508 refresh, which took effect on 18 January 2018, federal ICT must conform to WCAG 2.0 Level AA, incorporated by reference.

The bigger change is state and local government. The Department of Justice’s 2024 rule under ADA Title II sets WCAG 2.1 Level AA as the technical standard for public entities’ web content and mobile apps. On 20 April 2026 the DOJ published an interim final rule pushing the compliance dates back by a year: 26 April 2027 for entities serving 50,000 people or more, and 26 April 2028 for smaller entities and special districts. The technical standard did not change.

The rule also covers content a public entity provides through contracts and other arrangements with outside parties. A state university or a county that buys your platform cannot hand its own obligation over to you. What it can do is ask for evidence before it signs and write accessibility into the contract. The ACR is that evidence.

The deadline moved, but the purchasing cycles leading up to it did not stop. Contracts signed this year will still be running in 2027. How the rule applies to any particular contract is a question for your counsel; I am not an attorney, and none of this is legal advice.

Six things a reviewer checks first

These are the patterns that make a reviewer start testing, roughly in the order they notice them.

1. Every row says “Supports”

A product of any real complexity that conforms to every WCAG 2.1 AA criterion without exception is rare. A clean column reads as a report nobody tested, and it invites the reviewer to prove it wrong.

2. The wrong edition for the buyer

VPAT 2.5 comes in four editions. The 508 edition covers WCAG 2.0. The EU edition covers WCAG 2.1 through EN 301 549. The WCAG and INT editions include WCAG 2.2.

Send the 508 edition to a buyer working to Title II and it doesn’t answer their question. It never mentions the WCAG 2.1 additions they are bound by: SC 1.3.4 Orientation, SC 1.4.10 Reflow, SC 1.4.11 Non-text Contrast, SC 2.5.3 Label in Name, among others. Pick the edition that matches the buyer’s standard, or use INT and cover all of them.

3. “Evaluation methods” says “automated scan”

The template asks how you tested. If the answer is a scanning tool alone, the reviewer knows most of the criteria were never actually examined. Automated tools catch only a minority of WCAG failures, so they cannot tell you whether a focus order makes sense (SC 2.4.3) or whether an error message actually describes the error (SC 3.3.1). I covered the gap between scanning and manual testing in the Shopify theme audit patterns. Name the assistive technology, the browsers, and the manual method you used.

4. “Not Applicable” used to hide things

“Not Applicable” is for criteria the product genuinely cannot trigger. If your product has an onboarding video, the captions criterion (SC 1.2.2) applies. If it has a sign-in timeout, SC 2.2.1 Timing Adjustable applies. A reviewer will open the product and look for exactly these.

5. Empty remarks

“Partially Supports” with nothing in the remarks column tells the buyer nothing, and section508.gov specifically tells them to find out which aspects are only partially supported. Say where the gap is and what it affects. For example: “Data table column headers are not programmatically associated in the reporting module (SC 1.3.1). Other modules conform.”

6. An old date and no version number

An ACR describes one version of a product on one date. A report dated three releases ago describes software the buyer is not purchasing. Reviewers check the report date and product version against what is actually live.

The honest report wins more often

This is the position I’d take with any vendor: a specific “Partially Supports” is a stronger sales document than a blanket “Supports”.

A reviewer who finds a gap you disclosed sees a vendor who knows its own product. One who finds a gap you hid has a reason to doubt the rest of the document.

Honest reports also hold up under contract terms. Buyers can write accessibility warranties and remediation obligations into their agreements, and Section508.gov publishes contract language templates for exactly that. Whatever your ACR says is likely to be quoted back to you if a problem is reported later.

Disclosing a gap also gives you a chance to explain it. A remark that names the gap and states a remediation plan answers the reviewer’s next question before they ask it. Commit to a date only if you can meet it. A missed date in a signed contract is worse than no date.

One technical note that catches people out: SC 4.1.1 Parsing was removed in WCAG 2.2 as obsolete, and W3C’s errata for 2.0 and 2.1 treat it as always satisfied for HTML and XML content. Writing a remark about markup validation under 4.1.1 tells a reviewer the report was copied from an old template.

How to produce one that survives review

Fix the scope. Name the product, version, and the specific pages, flows, or modules tested. A product line is not a scope.
Test manually against the criteria. Use the keyboard alone, a screen reader (NVDA and VoiceOver at minimum), zoom to 400% for reflow, and inspect names, roles and states. Use automated tools to cover more ground, not to replace that work.
Record evidence per criterion. What was tested, where, what passed, what failed. The ACR is a summary; the evidence is what you defend it with.
Choose the edition that matches the buyer’s standard: WCAG 2.0 for 508, WCAG 2.1 for Title II and EN 301 549, or INT if you sell to all of them. If you are deciding which standards apply to your business, start with which accessibility law applies.
Write remarks a reviewer can verify. Specific components, specific criteria, no marketing language.
Reissue it on a schedule. At minimum, reissue it on each major release, with a new date and version.

None of this makes a product compliant on its own, and no ACR guarantees a contract or protects you from a complaint. What it gives you is a documented, defensible position: what was tested, what was found, what is being fixed, and when.

Where to start

If a buyer has asked and you have no report, start with the testing, not the template. Writing the ACR is the last step.

At EcomBack (opens in a new window) we test products manually against WCAG 2.2 AA and Section 508, then write the ACR from that evidence, in the edition your buyer expects. You can see the full scope on the services page.

Book a call (opens in a new window) and bring the procurement request with you. We will tell you what it actually requires and how long it takes to answer it honestly.

Your VPAT Is Not a Certificate. Buyers Are Checking It.