How to Write a VPAT / Accessibility Conformance Report (ACR)

Share on LinkedIn Comment

If you sell software to governments, universities or large enterprises, sooner or later a procurement team will ask: “Can you send us your VPAT?” For many product teams, that’s the first time accessibility becomes a sales issue rather than a nice-to-have.

I’ve prepared and reviewed VPATs for enterprise products, and the difference between a useful report and a damaging one is rarely the format. It’s honesty and evidence. This guide explains what a VPAT is, which edition to choose, how to fill it in, and the mistakes that make buyers stop trusting your report.

Key takeaways

A VPAT is a template; once completed for a product, it’s called an Accessibility Conformance Report (ACR).
Choose the edition that matches your markets: WCAG, Section 508, EU (EN 301 549) or INT, which covers all three.
Every claim should be based on actual testing, including manual testing with assistive technology.
“Partially Supports” with clear remarks is far more credible than “Supports” everywhere.
An ACR describes a specific product version on a specific date. Keep it current.

What is a VPAT?

VPAT stands for Voluntary Product Accessibility Template. It’s a document format maintained by the Information Technology Industry Council (ITI) that lets vendors describe how well a product meets accessibility standards. When you fill in the template for a specific product, the result is an Accessibility Conformance Report (ACR). People use both terms interchangeably, but buyers increasingly ask for “an ACR based on the latest VPAT”.

It originally grew out of US Section 508 procurement, where federal agencies must consider accessibility when buying technology. Today it’s used much more widely: by US state agencies and universities, by enterprises with accessibility policies, and increasingly by buyers in Europe referencing EN 301 549.

Which edition should you use?

ITI publishes several editions of the template:

Edition	Covers	Use when
WCAG	WCAG 2.x criteria	Buyers want WCAG conformance only
Section 508	Revised US Section 508 standards	Selling to US federal agencies
EU	EN 301 549	Selling to European public sector and EAA-related buyers
INT (International)	WCAG, Section 508 and EN 301 549 together	Selling to multiple markets; often the best default

Always download the current version from ITI’s website rather than reusing an old file. Check which WCAG version the edition covers, and say clearly in your report which version and level you evaluated against (for example WCAG 2.2 Level A and AA).

The structure of an ACR

A typical report contains:

Product information: name, version, date of the report, contact details.
Product description: what the product does and which parts were evaluated.
Evaluation methods used: how you tested, including tools, assistive technologies, browsers and whether testing was manual.
Applicable standards and guidelines: which standards the report covers.
Terms: definitions of the conformance levels.
Conformance tables: each criterion with a conformance level and remarks.
Legal disclaimer (optional, usually company-specific).

Conformance levels

Each criterion gets one of these:

Supports: the functionality meets the criterion without known defects, or meets it with equivalent facilitation.
Partially Supports: some functionality does not meet the criterion.
Does Not Support: the majority of functionality does not meet the criterion.
Not Applicable: the criterion isn’t relevant to the product. For example, 1.2.2 Captions (Prerecorded) when the product has no video.
Not Evaluated: the criterion wasn’t evaluated. In the WCAG tables this is generally only acceptable for Level AAA.

How to write good remarks

The remarks column is where buyers learn what they need to know. A good remark is specific, factual and tells the reader the impact.

Weak remark:

Partially Supports. Some images are missing alt text.

Strong remark:

Partially Supports. Most images have appropriate text alternatives. Exceptions: chart images on the Analytics dashboard do not have text alternatives, and some icon-only buttons in the report builder toolbar have no accessible name. A fix is planned for version 8.4.

Good remarks:

Name where the issue occurs (module, page, component)
Describe what the barrier is, not just the criterion number
Avoid internal jargon and ticket numbers that mean nothing to the buyer
Mention workarounds or planned fixes if you have them, without overpromising

Step-by-step process

1. Define the scope

Decide exactly which product, version and platforms the report covers: web app, iOS app, Android app, desktop client, documentation and support. Each may need its own report or clearly separated sections.

2. Test properly

An ACR is only as good as the testing behind it. Combine:

Automated scans across key pages
Manual testing of every criterion on representative pages and user journeys
Keyboard-only testing (see keyboard accessibility and focus management)
Screen reader testing with at least one common combination, such as NVDA with Chrome or Firefox and VoiceOver with Safari (see screen reader testing for beginners)
Zoom, reflow and contrast checks

Record which pages and tools you used. That goes in the “Evaluation methods” section.

3. Fill in the tables honestly

Go criterion by criterion. Where results are mixed, choose “Partially Supports” and explain. Resist pressure to round up. Experienced buyers will test your product, and a report that claims full support while basic barriers exist damages trust far more than an honest “Partially Supports”.

4. Review

Have someone who didn’t do the testing review the report for accuracy, clarity and consistency.

5. Publish and maintain

Date the report, keep it with the release it describes, and update it with major releases or at least annually. Many companies publish ACRs on an accessibility page so buyers can find them without asking.

Common VPAT mistakes

“Supports” for every criterion. Almost no complex product fully supports every WCAG criterion. Buyers know this.
No evaluation methods. Without them, the report looks like guesswork.
Outdated reports. A report for a version from three years ago tells the buyer nothing about today’s product.
Marking criteria “Not Applicable” to avoid them. If your product has forms, 3.3.1 Error Identification applies.
Copying a competitor’s or an old report. Each report must reflect your product’s actual testing.
Leaving out the Section 508 chapters on software, documentation and support when using the 508 or INT edition. These cover things like accessible help content and support channels.

Do you need a third-party audit?

A VPAT can be completed internally, and many companies do so. An independent audit adds credibility, especially for large deals or regulated buyers, and an experienced auditor will find issues internal teams miss. Whichever route you choose, the report must reflect real testing.

If you need an independent audit or help preparing an ACR, see my accessibility audit services.

Conclusion

A VPAT isn’t a compliance badge. It’s a factual description of how accessible your product is today. Choose the right edition, test properly with assistive technology, write specific remarks, keep it current, and be honest about gaps. Buyers don’t expect perfection; they expect accuracy, and a credible plan.