VPAT and Accessibility Conformance Reports

What a VPAT Is

VPAT stands for Voluntary Product Accessibility Template. It is a reporting template, published by the Information Technology Industry Council, that a manufacturer or vendor fills in to describe how a technology product meets recognized accessibility standards. The template gives buyers and sellers a common structure, so that reports for different products can be read and compared in the same way.

The template itself is blank. It contains instructions, tables listing the requirements of one or more standards, and fields that the vendor completes. The current version is VPAT 2.5Rev, released in April 2025. The Information Technology Industry Council provides the templates as a free resource and states that it does not review, approve, or certify completed reports.

What an Accessibility Conformance Report Is

An Accessibility Conformance Report, usually shortened to ACR, is what the template becomes once it has been completed for a specific product. In the Information Technology Industry Council's own terms, a version of the VPAT that has been completed for a specific product is an ACR.

The distinction matters in practice. Purchasers often ask vendors for a VPAT when what they need is the completed report for the exact product and version under consideration. Asking for an ACR makes the request precise: the purchaser wants a document that makes specific claims about a specific product, not the empty form or a general statement of commitment.

The Four Editions and the Standards They Cover

The template is published in four editions, each built around different requirements. The 508 edition covers the Revised Section 508 Standards used in United States federal procurement. The EU edition covers EN 301 549, the European standard for accessibility requirements for information and communication technology. The WCAG edition covers WCAG 2.0, its equivalent international standard ISO/IEC 40500, WCAG 2.1, and WCAG 2.2. The INT edition combines all three in a single report.

Choosing the edition is part of reading the report. A report prepared against only the WCAG edition says nothing directly about hardware, software, or support documentation requirements that appear in the Section 508 or EN 301 549 tables. Purchasers should confirm that the edition, and the version of WCAG reported against, match the requirements that apply to their own procurement.

For how these standards relate to one another, see WCAG vs ADA vs Section 508.

Conformance Level Terms

For each requirement, the completed report states a conformance level. The template defines four principal terms: Supports, Partially Supports, Does Not Support, and Not Applicable. Supports means the product has at least one method that meets the criterion without known defects, or meets it through equivalent facilitation. Partially Supports means some functionality of the product does not meet the criterion. Does Not Support means the majority of the product's functionality does not meet it. Not Applicable means the criterion is not relevant to the product.

The template also provides Not Evaluated, which may be used only for WCAG Level AAA criteria. It cannot be used to leave Level A or Level AA requirements unassessed.

These terms describe the vendor's claim about each requirement. They are not scores, and the report is not designed to produce an overall pass or fail. A single Partially Supports entry for a critical task may matter more to a particular organization than several entries for features its users will never encounter.

Remarks and Explanations

Each row of the report includes a field for remarks and explanations, and this is often the most informative part of the document. The federal Section 508 program advises that any criterion marked Partially Supports or Does Not Support should include a comment indicating how the standard is not met or not fully met.

Good remarks identify which features or workflows are affected, describe the effect on users, and mention any known workaround or planned correction. A Supports entry can also benefit from a remark explaining how the requirement is met, particularly where the answer is not obvious. Rows that contain only a conformance term and no explanation give a purchaser very little to act on.

Who Prepares an ACR

The report is prepared by or on behalf of the organization that owns the product. The Information Technology Industry Council notes that the original manufacturer is usually the best source to conduct the testing needed to complete it, although a reseller may also complete one. There is no VPAT certification, and the template does not require independent third-party review, although some solicitations do.

Many vendors engage accessibility specialists to evaluate the product and draft the report, while others prepare it internally. Either approach can produce a reliable document. What matters is whether the report is based on competent, documented evaluation of the actual product, and whether the people who prepared it understood the standards they were reporting against.

Evaluation Methods and Evidence

The template includes a field for the evaluation methods used, and that field deserves close reading. A credible report describes how the product was tested: which standards and versions, which parts of the product, what combination of automated tools, manual inspection, and assistive technology testing, and which screen readers, browsers, and operating systems were used.

An ACR is only as reliable as the evaluation behind it. A report prepared from an automated scan alone, or from a general knowledge of the product rather than testing of it, cannot support the claims in its tables with confidence. For how accessibility is evaluated in practice, see Accessibility Testing and Evaluation.

Purchasers are entitled to ask for evidence. Reasonable requests include a summary of the testing performed, the date of the evaluation, and a demonstration of key tasks using assistive technology.

Scope, Version, and Date

A report describes a particular product at a particular point in time. It should identify the product name and version, the report date, the edition of the template used, and contact information for questions. The product description should make clear what is and is not covered: a web application, its mobile app, its administrative interface, its documentation, and its customer support channels may each have different accessibility characteristics.

When the scope is unclear, a report can appear to cover more than it does. A report written for a customer-facing portal may say nothing about the staff interface that employees will use every day. Purchasers should confirm that the report covers the components their users will actually rely on.

Keeping Reports Current

Products change continuously, and each release can introduce or remove accessibility barriers. The federal Section 508 program notes that every time a product is changed or updated, an updated ACR may be required to address changes in its accessibility.

A report that is several years old, or that names a product version no longer offered, describes a different product from the one being purchased. Vendors that take accessibility seriously typically update their reports on a regular schedule and when significant changes are released, and they make the current report easy to find.

Why Purchasers Request ACRs

Organizations request ACRs because accessibility is far easier to secure before a product is bought than after it has been deployed. Public agencies, schools, colleges and universities, health systems, and businesses all acquire software and services that their employees, students, patients, and customers will be expected to use.

In United States federal procurement, the Revised Section 508 Standards establish accessibility requirements for information and communication technology, and ACRs are a standard way for vendors to describe how their products meet them. The federal Section 508 program maintains guidance for both buyers and sellers, along with an ACR Library. Many state agencies, educational institutions, and private organizations use ACRs in the same way in their own purchasing processes.

An ACR helps a purchasing team compare products, identify gaps before committing, and plan accommodations or contract terms for known limitations. It also establishes a written record of what the vendor represented.

Questions to Ask a Vendor

A purchasing team can learn a great deal from a few direct questions. Is this report for the exact product and version being purchased, and when was it prepared? Which edition of the template and which version of WCAG were used? Who performed the evaluation, and what methods and assistive technology were used? Which parts of the product were included, and which were not?

Further questions address what happens next. For each item marked Partially Supports or Does Not Support, what is the effect on users, is there a workaround, and is a correction planned, with what expected timing? How are accessibility problems reported and resolved after purchase? How often is the report updated, and will the vendor provide an updated report after major releases?

The answers matter as much as the document. A vendor that responds clearly and specifically is usually better prepared to support accessibility after the sale than one that cannot explain its own report.

Warning Signs in Accessibility Documentation

Some reports raise concerns on first reading. Common warning signs include a report with no date or no product version, an outdated template edition, every criterion marked Supports with no remarks, remarks that repeat the criterion text without explaining how it is met, and an evaluation methods field that is blank or names only an automated tool.

Other concerns include Not Applicable used for requirements that plainly apply, such as marking captions not applicable for a product that plays video; claims of full conformance that conflict with what a short keyboard or screen reader check reveals; and marketing statements or overlay certificates offered in place of a completed report. None of these proves that the product is inaccessible, but each is a reason to ask further questions before relying on the document.

An ACR Is Not a Guarantee

An ACR is a vendor's statement about its product. It is not an independent certification, and the existence of a VPAT or ACR does not prove that a product is accessible. A carefully prepared report can still contain errors, and a report can become inaccurate as soon as the product changes.

For that reason, the federal Section 508 program encourages buyers to validate vendor claims through their own testing and evaluation, particularly for products that will be widely used or that support essential functions. Validation can be as simple as a structured keyboard and screen reader check of key tasks, or as extensive as a full conformance evaluation.

Where the ACR Fits in Accessible Procurement

An ACR is one input into a broader purchasing process, not the whole of it. Accessible procurement typically begins by stating accessibility requirements in the solicitation, continues with reviewing ACRs and validating the claims that matter most, and carries through into contract terms that address known gaps, remediation commitments, and responsibilities for future updates.

After purchase, the same attention continues. Products should be configured accessibly, retested when significant updates are released, and supported by a clear process for users to report barriers. Some organizations also ask vendors for supplementary detail; the federal Section 508 program, for example, has published an Issue Detail Supplement that records the severity of each issue, the user groups affected, and any available workarounds.

Used this way, the ACR is a practical tool for asking better questions and making better decisions. It works best when purchasers read it critically, confirm it against the actual product, and keep it current for as long as the product is in use.

Related AssistiveTechnology.org Resources

For how accessibility is evaluated in practice, see Accessibility Testing and Evaluation. For what the guidelines are and how conformance levels work, see WCAG Overview. For how WCAG relates to specific United States laws, see WCAG vs ADA vs Section 508. For documents in every format, see Accessible Documents. For a general orientation to the subject, see Digital Accessibility, and for further reading across topics, see Resources. For the purchasing process as a whole, see Accessible Procurement.

Request accessibility services

Authoritative Sources

Information Technology Industry Council: Voluntary Product Accessibility Template, including the VPAT 2.5Rev editions, conformance level definitions, and frequently asked questions.

U.S. General Services Administration, federal Section 508 program: guidance on Accessibility Conformance Reports for sellers and buyers, the ACR frequently asked questions, the ACR Library, and the Issue Detail Supplement.

U.S. Access Board: Revised Section 508 Standards, including the incorporation of WCAG 2.0 Level A and Level AA.

World Wide Web Consortium: Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation.

Last Standards Review

Last standards review: September 24, 2026. On that date the current VPAT version and release date, the four template editions and the standards each covers, the conformance level definitions including the limited use of Not Evaluated, and the federal Section 508 program guidance described here were verified against current Information Technology Industry Council and federal Section 508 program sources.

About This Page

This page provides general educational information about Voluntary Product Accessibility Templates and Accessibility Conformance Reports. It is prepared by The Accessibility Clinic Inc. as educational information only. VPAT is a registered service mark of the Information Technology Industry Council. This page is not legal advice, and it does not guarantee that any specific website, application, document, or product meets a particular standard or legal requirement. Organizations should evaluate their own obligations in light of their specific circumstances and consult qualified counsel when needed. Standards and regulations change; the last standards review date above indicates when the statements on this page were most recently verified against primary sources.