What Is a VPAT? Accessibility Conformance Reports Explained

What a VPAT Actually Is

A VPAT (Voluntary Product Accessibility Template) is a standardized template that a technology vendor fills out to describe how a specific product — a piece of software, a hardware device, a web application, a digital service — conforms to one or more accessibility standards. It was created by the Information Technology Industry Council (ITI), working with the U.S. General Services Administration (GSA), so that buyers evaluating competing products would receive accessibility information in a consistent, comparable format instead of ad hoc marketing claims.

Once a vendor completes the template, the resulting document is formally called an Accessibility Conformance Report (ACR). In everyday usage, "VPAT" and "ACR" are used interchangeably — people ask for "your VPAT" and mean the finished report, not the blank form. This guide follows that convention.

If you only need the short definition, see our VPAT glossary entry. This guide is the practical companion: how to read one, who asks for one, and the caveat every buyer and vendor needs to understand before treating a VPAT as proof of anything.

The Four VPAT Editions

ITI publishes the current VPAT template (version 2.5 at time of writing) in four editions, each built around a different accessibility standard:

• WCAG Edition — reports conformance against the W3C's Web Content Accessibility Guidelines only. Useful when a buyer cares about WCAG conformance specifically, independent of any government procurement framework.
• Revised Section 508 Edition — reports conformance against the U.S. Access Board's Section 508 standards, which reference WCAG 2.0 Level AA for web and electronic content plus additional requirements for hardware, software, and functional performance. This is the edition federal agencies most commonly request.
• EN 301 549 Edition — reports conformance against EN 301 549, the European standard for accessibility requirements for ICT products and services, used across EU procurement.
• International (INT) Edition — combines WCAG, Section 508, and EN 301 549 criteria into a single document, so a vendor selling into multiple markets can produce one report instead of three.

Each edition uses the same underlying reporting structure — one table per standard, one row per criterion — so switching between editions is mostly a matter of which criteria set applies, not a different format to learn.

Who Actually Asks for a VPAT

VPAT requests cluster around a few recurring buyers:

• Federal agencies. Section 508 requires federal agencies to procure accessible information and communication technology (ICT). Requesting a VPAT from every bidding vendor is the standard mechanism procurement officers use to document that consideration during the buying process.
• State and local governments, and public universities. Many state procurement policies mirror Section 508 or reference WCAG directly, and public universities receiving federal funding face their own Section 504 obligations. VPATs have become a common ask even outside the federal government proper.
• Enterprise buyers with vendor-risk programs. Large companies in regulated industries — finance, healthcare, insurance, ed-tech — increasingly build accessibility into vendor onboarding and procurement checklists, independent of any legal requirement to do so, because the software they buy becomes part of their own compliance surface.
• Prime contractors. A prime contractor delivering a system to a federal agency will often require VPATs from every subcontractor whose component feeds into the final product, pushing the requirement down the supply chain.

Notably absent from that list: everyday ADA Title III enforcement. A private business selling directly to consumers is not typically asked to produce a VPAT for its own public website — that obligation runs through WCAG conformance and, if it comes to it, litigation, not a procurement template. VPATs live primarily in the B2B and B2G technology-purchasing world.

How Conformance Levels Are Reported

For every criterion in the applicable standard — for example, WCAG Success Criterion 1.1.1 (Non-text Content) or 2.1.1 (Keyboard) — the vendor selects one of four conformance levels:

• Supports — the product fully meets the criterion as written.
• Partially Supports — some functionality meets the criterion, but not all of it. This is where the most useful information usually lives.
• Does Not Support — the product fails to meet the criterion in a material way.
• Not Applicable — the criterion does not apply to this particular product (for example, a criterion about video captions on a product with no video content).

Each row also carries a Remarks and Explanations field. This is what separates a genuinely useful VPAT from a decorative one. A remark that just restates the conformance level ("This criterion is supported") tells a buyer nothing. A remark that says exactly what was tested, what works, and what does not — including known gaps and remediation timelines — gives a procurement officer or a downstream developer something they can actually act on.

A VPAT Is Not an Audit

This is the single most important thing to understand about VPATs, and it is worth stating plainly: a VPAT is normally a self-reported document, and there is no mandatory independent verification built into the process. ITI's template does not require third-party testing before a vendor publishes a VPAT. In practice, most VPATs in circulation were filled out by the vendor's own product or engineering team, sometimes with limited formal accessibility testing behind the ratings.

That does not make VPATs worthless — a detailed, specific, honestly-written VPAT is genuinely useful information, and the exercise of completing one often surfaces accessibility issues a team didn't know it had. But it does mean a VPAT sits in a different category than an independent accessibility audit. An audit — the kind described in our guide to the ADA audit process — is conducted by someone with no stake in the product's marketed accessibility claims, typically combines automated scanning with manual testing using real assistive technology, and produces findings tied to specific pages, components, and criteria.

A VPAT can be produced from that kind of rigorous audit, or it can be produced from a developer's best guess filled in over an afternoon. The document looks identical either way. Buyers who treat a clean VPAT as equivalent to a passed audit are taking the vendor's word for it — sometimes reasonably, sometimes not.

How VPATs Connect to Section 508 and ADA Procurement

Section 508 of the Rehabilitation Act requires federal agencies to ensure the ICT they procure, develop, maintain, and use is accessible. VPATs exist almost entirely to serve that requirement: they give an agency's Section 508 coordinator a standardized way to compare vendor claims during a purchase decision.

The ADA is a separate, related thread. Title II — which the DOJ's 2024 final rule extended to require state and local government websites to conform to WCAG 2.1 Level AA — governs what a government entity's own website and services must look like, not what template its software vendors fill out. A city government redesigning its permitting portal has its own WCAG 2.1 AA obligation under Title II regardless of what any vendor's VPAT says about the underlying software platform. That said, government buyers increasingly ask for VPATs from software vendors specifically because a platform with known, undisclosed accessibility gaps can put the buying agency's own Title II conformance at risk once that software is deployed to the public.

For private businesses under ADA Title III, there is no direct requirement to produce or request a VPAT. If you buy a piece of SaaS software and embed it in your public-facing website, your own site's WCAG conformance is still your responsibility — a vendor's VPAT is useful due diligence, not a liability shield.

A Short Checklist for Reading Someone Else's VPAT

Before relying on a vendor's VPAT in a purchasing decision:

• Confirm the product name, version, and components actually tested match what you are buying.
• Check the evaluation date — a VPAT more than a year or two old may not reflect the current product.
• Read the remarks column, not just the Supports/Does Not Support ratings.
• Ask whether the evaluation was self-assessed or independently reviewed, and by whom.
• For anything mission-critical, spot-check a handful of criteria yourself — try the product with a keyboard only, or run it past a screen reader on one key workflow — rather than relying solely on the document.

Ready to take the next step? Grow Wild Agency offers a free preliminary WCAG 2.1 AA scan of your own website, so you know exactly where you stand before you're the one being asked for accessibility documentation instead of requesting it.