Mend

Guide

VPATs and ACRs

A VPAT is the blank template. An ACR is the finished report. Here is what they contain, who asks for one, and how to tell a careful report from a careless one.

Last reviewed: 20 July 2026

The 30-second version

A VPAT — Voluntary Product Accessibility Template — is a blank form published by the Information Technology Industry Council (ITI). An ACR — Accessibility Conformance Report — is what you get once a vendor fills that form in for a specific product at a specific version.

Template, then completed document. In conversation people say “send us your VPAT” when they mean the ACR, and that is harmless. The distinction starts to matter when you are the one answering: what a buyer wants is not the empty template, it is your evaluated, dated, product-specific report.

You may also see the ACR called a “VPAT 2.5”, a “completed VPAT”, or just “the accessibility documentation”. These all describe the same deliverable.

What is in one

ITI publishes the template in four editions, so you fill in the one matching the standard your buyer cares about. The current release is VPAT 2.5Rev, published in April 2025.

  • 508 edition — the Revised Section 508 Standards, the US federal accessibility requirement.
  • EU edition — EN 301 549, the European standard used in public procurement.
  • WCAG edition — the W3C's Web Content Accessibility Guidelines alone. The current edition covers WCAG 2.2.
  • INT (international) edition — all three of the above in one document. This is the one to reach for if you sell into more than one market and would rather maintain a single report.

Inside, the body of the report is a set of tables — one row per success criterion. Each row carries the criterion, a conformance level, and a remarks column. The conformance level is chosen from a fixed vocabulary:

  • Supports — the product has at least one method that meets the criterion without known defects, or meets it with equivalent facilitation.
  • Partially Supports — some functionality of the product does not meet the criterion.
  • Does Not Support — the majority of product functionality does not meet the criterion.
  • Not Applicable — the criterion is not relevant to the product.
  • Not Evaluated — permitted only in the Level AAA table, which is the one table not required to be completed. It is not an escape hatch for Level A or AA rows you would rather not answer.

The remarks column is where the honesty lives. Remarks are required whenever a row says Partially Supports or Does Not Support, and encouraged even when a row says Supports. A report is only as useful as that column: the level tells a buyer there is a problem, the remark tells them what it is and whether it affects them.

A report also carries an evaluation-methods section describing how the product was tested — manual, automated, or both — and which tools were used. Read on for why that section deserves more attention than it usually gets.

Who asks, and why

US federal procurement. This is the original driver. Agencies buying information and communication technology need to document conformance with the Revised Section 508 Standards, so vendors selling to them are routinely asked for an ACR. Using the VPAT template is not itself mandatory — but producing the report, in some form, is how the sale proceeds.

State, local, and education buyers. Many have adopted procurement policies modelled on Section 508, and universities in particular have become consistent about asking. Requirements here vary far more than at federal level.

Enterprise vendor-risk review. Large private buyers increasingly fold accessibility documentation into the same questionnaire that asks about security and data handling.

The European market. The European Accessibility Act applies to a broad range of products and services sold in the EU, which has made conformance documentation an ordinary part of doing business there rather than a public-sector speciality.

For what these regimes actually require — and which of them applies to you — see accessibility laws and legal compliance.

How to read one critically

If you have been sent an ACR and need to judge it, the useful signals are rarely in the summary.

  • An unbroken wall of “Supports” with an empty remarks column is a smell, not a triumph. Real products have rough edges. A report claiming none usually means nobody looked hard.
  • Read the evaluation-methods section first. Who tested this, using what, and how? “Automated scan” with no manual or assistive-technology testing tells you the report covers only what a scanner can see.
  • Check the date and the product version. An ACR describes one version at one moment. A report two years and six releases old describes software your users are not running.
  • Specific, dated remarks beat unqualified perfection. A vendor writing “Partially Supports — the date picker in the booking flow is not reachable by keyboard; fix scheduled for Q3” is telling you they tested properly and know their product. That is a better partner than one claiming flawlessness.
  • Check it covers what you will actually use. Reports are scoped to a product, and the scope statement may exclude the admin console, the mobile app, or the very module you are buying.

How to produce a credible one

If you are on the answering side, the shape of the work is consistent.

  • Start from the real template. Download the current edition from ITI rather than working from a competitor's PDF or a blog's reconstruction.
  • Test before you fill anything in. Automated checks first, because they are fast and repeatable and will find the mechanical failures. Then manual testing: keyboard-only operation, screen-reader passes, zoom and reflow, and human judgement about whether alternative text and error messages actually communicate anything.
  • Be specific in remarks. Name the component, the condition, and where it appears. Vague remarks read as evasion even when they are not.
  • Version it and re-issue it. An ACR describes a point in time; when the product changes materially, the report needs revisiting.
  • Do not outsource the claim to a tool. This is the important one. Automated testing verifies only a subset of each success criterion — it reliably catches missing alternative text, insufficient contrast, and unnamed controls, and it cannot assess meaning, context, or what using the product with assistive technology is actually like. A row marked Supports on the strength of a clean scan alone is a claim nobody has checked. Signing a conformance report is a human act, and it needs human evaluation behind it.

How Mend helps

Mend's audits map every finding to the WCAG success criteria it relates to, which is the raw material the conformance table is built from — it turns “this image has no alternative text” into “this is evidence about criterion 1.1.1”.

If you have an account, Mend can also assemble that data into a VPAT-format report covering WCAG 2.2 Level A and AA, generated on demand from your stored audits.

That report is an automated assessment, and it says so on its face. It is a starting point for the work described above — a human completes it — not a finished conformance claim. Where it marks a criterion Supports, that means the automated checks found no failures, which is not the same as the criterion being met.

Common questions

Is a VPAT legally required?

No law requires you to publish a VPAT. The pressure is commercial: US federal agencies need conformance documentation for the technology they buy, so vendors who want those sales produce an ACR. Using ITI's template specifically is a convention, not a mandate — it is simply the form everyone recognises. Separately, accessibility law may well apply to your product regardless of whether anyone asks for paperwork.

How often should it be updated?

Whenever the product changes in a way that would change an answer — a version release, a redesign, a fix to something the report flagged. Guidance from Section508.gov is that an updated report may be required every time the product is changed or updated. In practice, teams re-issue on a regular cadence and after any significant release, and always date the document.

Can an automated tool generate my ACR?

Partly — and the part it cannot do is the part that matters most. A scanner can populate the criteria it is able to test and give you evidence for the remarks column, which is real work saved. It cannot judge whether alternative text is meaningful, whether a page is navigable by screen reader, or whether an error message helps. A report generated by a tool and shipped unreviewed is a claim about your product that no person has verified.

How is this different from an accessibility statement?

An accessibility statement is a public, plain-language page on your website describing your commitment, known limitations, and how to contact you about a barrier. An ACR is a structured, criterion-by-criterion technical document, usually sent to a specific buyer on request. Different audiences, different purposes; many organisations maintain both.

What does it cost to have one produced?

It varies enormously with product size and how much accessibility work has already been done, and quoted figures age badly, so we will not invent a number. The honest framing: most of the cost is the evaluation, not the paperwork. If your product has never been tested against WCAG, the report is the small part and the testing — plus fixing what it finds — is the large part. Vendors who test continuously find re-issuing a report comparatively cheap.

A note on the name

VPAT® is a registered service mark of the Information Technology Industry Council. ITI publishes the template and its instructions, and its page at itic.org/policy/accessibility/vpat is the authoritative source for the current version and editions — this guide summarises it, and where the two disagree, ITI is right. For the procurement side, Section508.gov's guidance on creating and reading an ACR is the equivalent primary reference.

← All guides