VPAT vs. ACR: What Are They and How Are They Different?

Accessibility documentation isn’t optional, especially for government agencies or large enterprises. But when someone asks for your “VPAT” or your “ACR”, it’s easy to feel lost in a sea of acronyms. 

The short answer is that a VPAT and an ACR are related but not identical. Understanding that distinction matters most in procurement, where buyers ask for a VPAT but evaluate you on the ACR. Submit the wrong document, or a thin one, and you risk stalling in security review, getting disqualified from a bid, or handing a competitor the edge.

What is a VPAT?

A VPAT, a Voluntary Product Accessibility Template, is a standardized document that shows how well your digital products, including software, websites, mobile applications, electronic devices, etc., meet specific accessibility standards. Created by the Information Technology Industry Council (ITI), the template provides a structured way to describe whether a product conforms, partially conforms, or does not conform to guidelines like:

• Section 508 of the Rehabilitation Act (U.S. federal government accessibility requirements)

• The Web Content Accessibility Guidelines (WCAG)

• EN 301 549(opens in a new tab)(downloads a file), the European Accessibility Standard 

One thing to call out: VPATs are completely voluntary. There is no legal requirement to produce one unless it’s part of a procurement process or a client request. A VPAT itself is also self-reported, so accuracy depends on your expertise and honesty. It doesn’t guarantee real-world usability for people with disabilities, nor does it replace user testing or independent audits.

What is an ACR?

An Accessibility Conformance Report (ACR) is the completed document produced by filling out a VPAT. Like a VPAT, the ACR summarizes how well a specific product meets accessibility standards like WCAG, Section 508, and EN 301 549. Unlike the VPAT, an ACR includes actual findings, details, and explanations about how and where a product conforms, partially conforms, or does not conform to specific accessibility requirements. 

Each criterion in an ACR gets one of four conformance levels:

• Supports: The product meets the criterion without known defects.

• Partially supports: The product meets some criteria but has known gaps.

• Does not support: The product does not meet the criterion.

• Not applicable: The criterion does not apply to the product as evaluated.

The conformance level is only half the answer. Every criterion is paired with a remarks and explanations column, and that column is where the report earns credibility. Strong remarks describe what was tested, which platform and assistive technology combinations were used, where the failure appears in the interface, how it affects the user, and whether a fix is planned or a workaround exists. Vague entries like “mostly accessible” or a blank cell next to “partially supports” tell a buyer nothing, and experienced reviewers read that as a gap in testing rather than a gap in writing. 

It also shapes how buyers read it. Procurement and accessibility reviewers tend to scan the conformance column, then spend their time reviewing the remarks. A report full of “supports” with thin explanations often raises more questions than a candid report that documents partial support and describes the fix plan behind it.

Put simply, the VPAT is the template, and the ACR is the filled-in template. If you’re bidding on a contract or responding to a procurement request, the ACR is the document you send, and the depth of testing behind it is what buyers actually weigh. 

Which One is Your Buyer Actually Asking For?

Typically, buyers are asking for your ACR. When a procurement officer emails “please send your VPAT,” they want the completed report, not the ITI template. The shorthand stuck because “VPAT” became the industry name for the whole document, and that habit is now baked into how buyers write requests. 

RFP and solicitation language reflect the same slippage. You’ll see requirements phrased as “vendor shall provide a current VPAT,” “submit a VPAT 2.1 Rev WCAG conformance report,” or “provide documentation of Section 508 conformance.” All three are asking for a filled-in report tied to a named standard and version. The tell is any word implying evidence: current, completed, documented, conformance report, or a specific WCAG level.

When the request is ambiguous, send the ACR. It answers both the narrow and broad questions at once, since a completed report inherently shows which template edition you used. Include the evaluation date, the product version tested, and the standard applied so the reviewer doesn’t have to ask.

The most common vendor error is sending a blank template. It happens when someone downloads the VPAT from ITI, sees “VPAT” in the file name and the RFP, and forwards it to a reviewer who reads it as a vendor with nothing to report.

Who Should Produce Your ACR?

You have two paths: author the report yourself, or have it assessed by a third party.

A self-authored report is legitimate and common. Your developers or compliance team evaluate the product against each criterion and document what they find. It costs less and moves faster, and for a low-risk deal, it may be all a buyer needs.

A third-party assessment carries more weight because a qualified assessor does things that automated tooling alone cannot. Scanners reliably detect issues such as missing alt text, contrast failures, and unlabeled form fields. They cannot determine whether alt text is meaningful, whether a focus order matches the visual reading order, whether an error message is actually announced, or whether a custom component behaves the way its ARIA role promises. Those criteria require someone to operate the product and form a judgment.

That’s also what makes remarks defensible. “Focus stays inside the modal when tested with NVDA on Windows” is verifiable. “No issues detected” is not.

Slightly unbalanced scale in front of a stylized web browser. The heavier side of the scale is holding the accessibility symbol.

Does a VPAT or ACR Protect You From Legal Risk?

Neither document protects you from an accessibility lawsuit. What an ACR does is create a dated, specific record that you evaluated your product against a named standard and documented what you found. That record is the protection, and it only works if the report is accurate.

Legal Protection and Risk Mitigation

If you receive an ADA demand letter or face an accessibility lawsuit, an ACR can serve as evidence of a good-faith effort to meet your accessibility obligations. It shows you assessed the product, identified gaps, and, if your remarks indicate, planned fixes. It does not establish conformance or resolve a claim.

The reverse is also true, and it’s the part that vendors underestimate. An inaccurate report is worse than no report. A public document claiming “supports” on criteria that the product visibly fails gives an opposing party a written statement to point at. Candid remarks documenting partial support and a fix timeline are more defensible than an optimistic one.

General Services Administration (GSA) Recommendations

The GSA publishes guidance on accessible technology procurement. Its expectations for reports come down to three things:

• Use the current VPAT template edition so your report aligns with the standards buyers are evaluating against.

• Write clear, specific conformance statements. Vague or generic language invites additional scrutiny or outright rejection.

• Explain any partial support and known gaps in the remarks, and include your fix plans where applicable. 

Meeting those expectations reduces the chance of delays or rejection in federal and state procurement.

Beyond the Paperwork: Conformance You Can Prove

A VPAT and an ACR are useful tools. Both help you see how your website, app, or digital product compares to accessibility standards. But documentation has limits. These reports show your level of conformance and demonstrate your commitment to accessibility. They don’t guarantee full compliance or remove accessibility risk. 

Real accessibility goes beyond paperwork. It takes a partner who combines automation with expert fixes, which is exactly what AudioEye does. 

AudioEye combines AI-powered automation with Expert Audits to detect and fix accessibility issues. Independent research found AudioEye detects up to 2.5 times more WCAG issues than any other tool, helping you achieve industry-leading WCAG coverage. AudioEye Assurance backs all of this for added legal protection. 

AudioEye also offers a VPAT service. Our team documents how your digital content meets technical standards and shows your commitment to accessibility and legal compliance. 

Ready to move beyond paperwork and put accessibility into action? Get in touch with our team.