Accessibility Compliance
VPAT and ACR Explained: What Buyers Want and How to Produce One
If you sell software to a US federal agency, a university, a health system or a large enterprise, sooner or later procurement will ask for your VPAT. Vendors who cannot produce a credible one get filtered out before the demo. This guide explains what the document actually is, which edition to complete, how to fill it in without overstating, and what a good report looks like to the person reviewing it.
VPAT vs ACR - the distinction that trips people up
The Voluntary Product Accessibility Template (VPAT) is a blank template published by the Information Technology Industry Council (ITI). When you complete it for your product, the resulting document is an Accessibility Conformance Report (ACR).
In everyday procurement conversation the two words are used interchangeably, and asking for 'your VPAT' almost always means 'your completed ACR'. It is worth using the terms correctly in your own documentation, because it signals to a technical reviewer that you know the process.
Choosing the right edition
The template comes in several editions. Picking the wrong one is a common reason a report gets bounced back by procurement.
- WCAG edition - the W3C success criteria alone. Appropriate for commercial buyers with no statutory basis.
- Revised Section 508 edition - for US federal agencies and their contractors.
- EN 301 549 edition - for European public-sector procurement.
- INT (International) edition - combines all of the above. Usually the right default if you sell across regions, because one document answers every buyer.
The conformance levels, and what they really signal
Each success criterion is marked with a conformance level and, critically, a remarks column. Reviewers read the remarks far more carefully than the level.
- Supports - the functionality meets the criterion without known defects.
- Partially Supports - some functionality does not meet the criterion. Explain precisely what fails and where.
- Does Not Support - the majority of the functionality does not meet the criterion.
- Not Applicable - the criterion is not relevant to the product (for example, no pre-recorded audio anywhere in the product).
- Not Evaluated - permitted only for Level AAA criteria. Using it for A or AA criteria reads as an incomplete report.
Why an honest report beats an optimistic one
There is a strong commercial temptation to mark everything 'Supports'. It is a bad trade. Accessibility reviewers at large buyers test claims, and a report that collapses under a fifteen-minute screen-reader check destroys credibility for the entire bid - and sometimes for future bids.
A report that says 'Partially Supports' with a clear description of the gap and a remediation timeline is routinely accepted. Buyers are generally not looking for perfection; they are looking for a vendor who knows the state of their own product and has a plan. Overstated conformance can also create contractual and legal exposure if accessibility warranties are written into the agreement.
What goes into producing a credible ACR
A defensible report is the output of real testing, not a desk exercise. The work behind ours looks like this:
- Define the scope precisely - product name, version, platforms and the specific features evaluated.
- Automated scanning to establish a baseline and catch machine-detectable failures.
- Manual testing with real assistive technology - NVDA, JAWS, VoiceOver and TalkBack - plus keyboard-only and zoom/reflow testing.
- Criterion-by-criterion determination with evidence for each call, not a blanket judgement.
- Plain-language remarks that a non-engineer in procurement can understand.
- A dated report tied to a product version, with a stated re-evaluation cadence.
Keeping it current
An ACR describes a specific version of a product at a specific date. A report that is three years old and references a version you no longer ship is worse than useless - it tells a buyer your accessibility programme has stalled.
Re-evaluate at least annually, and after any significant redesign or framework migration. Treat it as a living artefact of your release process rather than a one-off sales document.
Need help with this in practice?
A5 Cyber Nexus audits, remediates and certifies against these frameworks.
Frequently asked questions
What is the difference between a VPAT and an ACR?
The VPAT is the blank template published by ITI. Once you complete it for your product, the finished document is an Accessibility Conformance Report (ACR). Buyers usually say 'VPAT' when they mean the completed ACR.
Which VPAT edition should we use?
If you sell internationally, the INT edition is usually the best default because it covers WCAG, Revised Section 508 and EN 301 549 in one document. Use a single-standard edition only if you sell into one market exclusively.
Can we complete a VPAT ourselves?
You can - it is a self-report by design. But buyers increasingly discount self-authored reports that show no evidence of assistive-technology testing, and an inaccurate report creates real contractual risk. Independent evaluation carries considerably more weight.
Is a VPAT legally required?
The template itself is voluntary. What is not voluntary is the underlying obligation - Section 508 for US federal procurement, EN 301 549 for EU public-sector procurement, and accessibility requirements in most large enterprise contracts. The ACR is simply how you evidence it.
How often should a VPAT be updated?
At minimum annually, and after any major release, redesign or platform migration. The report should always name the product version it describes and the date it was produced.
Related on A5 Cyber Nexus
Make it accessible.
Make it attack-ready.
Prove both before launch.
Bring us your app, audit deadline, or security concern. We'll map the fastest path to WCAG conformance, VAPT coverage, and regulator-ready evidence.
