Category: Compliance and Reporting

Accessibility Conformance Report

Also known as: ACR, Completed VPAT, VPAT report

Simply put

An Accessibility Conformance Report (ACR) is a formal document that describes how well a product or service meets established accessibility standards. It is often produced by completing a template called a VPAT, and it helps buyers, such as government purchasers, understand a product's accessibility before making a decision. Because it is typically a self-assessment prepared by the vendor, its accuracy depends on how the evaluation was conducted.

Formal definition

An Accessibility Conformance Report (ACR) is a document that discloses how a specific information and communication technology (ICT) product or service conforms to defined accessibility standards. ACRs are commonly generated by completing a Voluntary Product Accessibility Template (VPAT), which structures the report around a title page and evaluation tables that record conformance levels for applicable success criteria. ACRs are frequently used by federal agency contracting officials and government buyers to assess ICT during market research and proposal evaluation. Because an ACR is generally a self-assessment prepared by or on behalf of the supplier, it reflects the vendor's stated evaluation rather than an independent audit, and its reliability depends on the rigor and methodology of the underlying testing.

Why it matters

An Accessibility Conformance Report gives buyers a structured way to understand how a product or service measures against recognized accessibility standards before they commit to a purchase. This is especially significant in government procurement, where Section 508 obligations lead federal agency contracting officials and government buyers to assess information and communication technology (ICT) during market research and proposal evaluation. A clear, well-documented ACR can differentiate competing products and reduce the risk of acquiring technology that later proves difficult or impossible for people with disabilities to use.

The value of an ACR, however, is only as strong as the evaluation behind it. Because an ACR is generally a self-assessment prepared by or on behalf of the supplier, it reflects the vendor's stated evaluation rather than an independent audit. A report that relies solely on automated testing may overstate conformance, since automated tools detect only a portion of accessibility issues and cannot substitute for manual review and testing with assistive technology. Buyers should treat an ACR as a starting point for due diligence rather than a guarantee of accessibility or of legal compliance.

It is also important to keep the ACR's role in perspective: meeting the criteria described in a report does not guarantee an accessible experience for every user, nor does it confer immunity from legal claims. Accessibility requirements evolve through regulation and case law, and an ACR documents a product's status at a point in time using the standards and methodology the evaluator chose. Organizations making procurement or compliance decisions should consult qualified legal counsel and consider current agency rulemaking rather than relying on an ACR alone.

Who it's relevant to

Government and Institutional Buyers

Federal agency contracting officials and other government purchasers use ACRs to assess ICT during market research and proposal evaluation, particularly in contexts subject to Section 508. An ACR supports comparison of products but should be verified against the buyer's own requirements rather than accepted at face value.

Vendors and Suppliers

Companies that sell ICT products or services often prepare an ACR, typically by completing a VPAT, to disclose how their offering conforms to applicable accessibility standards. Because the report is generally a self-assessment, vendors are responsible for ensuring the underlying evaluation is thorough and honestly documented.

Accessibility Engineers and Testers

Those who conduct the evaluation behind an ACR determine its reliability. Their work should combine automated testing with manual review and assistive technology testing, since automated tools identify only a portion of accessibility issues and cannot fully validate conformance on their own.

Procurement and Compliance Officers

Staff responsible for purchasing decisions and standards compliance use ACRs as part of due diligence. They should treat a report as documentation of a product's stated status at a point in time, not as proof of an accessible user experience or as legal assurance, and should involve qualified legal counsel where obligations are unclear.

Inside ACR

VPAT Basis

An ACR is typically produced using the Voluntary Product Accessibility Template (VPAT), a document format maintained by the Information Technology Industry Council (ITI). The completed VPAT becomes the ACR once a specific product has been evaluated against the applicable standard.

Standard or Guidelines Evaluated

The report identifies which standard the product was assessed against. VPAT editions commonly address WCAG (for example 2.0, 2.1, or 2.2), Section 508 (applicable to federal agencies and covered federal contexts), and the EN 301 549 standard used in the European Union. The report should state the specific version and conformance level, such as WCAG Level AA.

Conformance Level Terminology

Each success criterion is generally rated using terms such as Supports, Partially Supports, Does Not Support, or Not Applicable, with accompanying remarks explaining the rating.

Success Criteria Tables

The core of the report consists of tables listing each applicable success criterion, its conformance status, and explanatory notes. When multiple WCAG versions apply, criteria added in later versions should be attributed to the correct version.

Remarks and Explanations

Narrative notes accompany each rating to describe how the product meets, partially meets, or fails a criterion, and to document known limitations or exceptions.

Product and Evaluation Metadata

Identifying details such as the product name and version, the date of evaluation, the evaluation methods used, and the party who prepared the report.

Common questions

Answers to the questions practitioners most commonly ask about ACR.

Does an Accessibility Conformance Report prove that a product is fully accessible or legally compliant?

No. An ACR documents a supplier's evaluation of how a product measures against a chosen standard, such as WCAG success criteria, at a point in time. Conformance as reported in an ACR does not guarantee an accessible experience for every user, nor does it provide immunity from legal claims. Automated testing detects only a portion of accessibility issues, and manual and assistive technology testing are generally required to give a meaningful picture. An ACR should be treated as one input into a broader evaluation, not as proof of compliance. For questions about legal exposure, consult qualified legal counsel.

Is an ACR the same thing as a VPAT?

They are related but not identical. A VPAT (Voluntary Product Accessibility Template) is a template published to help suppliers document accessibility. When that template is completed with a product's actual evaluation results, the resulting document is commonly referred to as an Accessibility Conformance Report. In short, the VPAT is the blank form and the ACR is the filled-in report, though the terms are often used loosely and sometimes interchangeably in practice.

Which standard should an ACR be evaluated against?

The applicable standard depends on the context and the audience for the report. Reports are commonly produced against WCAG at a specified version and conformance level, most often Level AA, and against Section 508 requirements when a federal context applies. Templates typically offer editions covering these standards. The report should clearly state which version and level were used so readers can interpret the results correctly, since success criteria differ across WCAG 2.0, 2.1, and 2.2.

How should each criterion's conformance status be described in an ACR?

ACRs generally use standardized conformance terms such as 'Supports', 'Partially Supports', 'Does Not Support', and 'Not Applicable', accompanied by explanatory remarks. The value of the report lies largely in these remarks, which should describe how a criterion is met, where gaps exist, and any known limitations. Vague or unsupported claims of full support reduce the report's usefulness, so specific, evidence-based explanations are preferred.

How often should an ACR be updated?

Because an ACR reflects a product at a specific point in time, it can become outdated as the product changes. It is generally advisable to review and update the report when significant releases, feature changes, or remediation work occur, and to note the product version and evaluation date in the report. Readers should check the date and version an ACR references before relying on it.

What testing methods should support the findings in an ACR?

A defensible ACR is generally supported by a combination of methods rather than automated tools alone. Automated testing detects only a portion of issues, so manual review and testing with assistive technologies such as screen readers, keyboard-only navigation, and magnification are typically needed to evaluate many success criteria accurately. The report may describe the testing approach used, which helps readers judge how thoroughly the evaluation was conducted.

Common misconceptions

An ACR proves a product is fully accessible or legally compliant.

An ACR documents the results of an evaluation against a chosen standard at a point in time. It does not guarantee an accessible experience for all users, nor does it provide immunity from legal claims. Conformance, usability, and legal compliance are distinct, and requirements evolve through regulation and case law.

A VPAT and an ACR are the same thing.

The VPAT is the template format, while the ACR is the completed report resulting from evaluating a specific product against a standard. The terms are often used interchangeably in practice, but the distinction is that the ACR reflects actual evaluation findings.

A rating of Supports means every issue has been caught and resolved.

Ratings reflect the scope and methods of the evaluation. Automated testing detects only a portion of accessibility issues, so a credible ACR should also reflect manual and assistive technology testing. Ratings can be incomplete or inaccurate if testing was limited.

Best practices

Confirm which standard and version the ACR was evaluated against (for example WCAG 2.1 Level AA, Section 508, or EN 301 549) and ensure it matches your own requirements before relying on the report.

Look beyond the summary ratings to the remarks column, where partial support and known limitations are documented, and treat vague or absent explanations as a signal to request clarification.

Verify that the evaluation combined automated, manual, and assistive technology testing rather than relying on automated checks alone, since automated tools detect only a portion of issues.

Check the evaluation date and product version, and request an updated ACR when the product changes, since conformance is assessed at a point in time.

Do not treat an ACR as proof of legal compliance; use it as one input alongside your own testing and, where appropriate, consult qualified legal counsel and current agency guidance.

When you are the party producing an ACR, use qualified, accurate language, attribute criteria to the correct WCAG version, and avoid overstating conformance to reduce the risk of misleading procurement decisions.