Quick answer
An Accessibility Conformance Report (ACR) is a document that records how a specific product, at a specific version, measures against a defined accessibility standard such as WCAG. It's a criterion-by-criterion record, usually built on the VPAT template, showing which requirements a product meets, partially meets, or doesn't meet at all.
What is an Accessibility Conformance Report?
An Accessibility Conformance Report (ACR) is a document that explains how well a digital product, website, or application meets recognized accessibility standards such as WCAG, Section 508, or EN 301 549.
An ACR is typically created using the Voluntary Product Accessibility Template (VPAT) and provides information about a product's accessibility features, limitations, and level of conformance with specific accessibility criteria.
What is the purpose of an Accessibility Conformance Report?
The purpose of an Accessibility Conformance Report (ACR) is to provide a clear overview of how a digital product, website, or application performs against accessibility standards such as WCAG, Section 508, or EN 301 549.
An ACR helps organizations communicate their accessibility status, identify areas that need improvement, and provide transparency to customers, procurement teams, and other stakeholders.
Why is an Accessibility Conformance Report used?
An ACR is commonly used to:
- Demonstrate accessibility efforts — show how a product has been evaluated against recognized accessibility requirements.
- Support procurement decisions — help organizations and buyers understand the accessibility capabilities of a product before purchase.
- Identify accessibility gaps — highlight areas where improvements may be needed.
- Document evaluation results — provide a record of testing methods, findings, and conformance levels.
An Accessibility Conformance Report does not guarantee full accessibility or act as a certification. Instead, it documents the results of an accessibility evaluation and helps organizations make informed decisions about accessibility improvements.
How is an Accessibility Conformance Report different from a VPAT?
An Accessibility Conformance Report (ACR) and a Voluntary Product Accessibility Template (VPAT) are closely related, but they are not the same thing.
A VPAT is a template used to evaluate the accessibility of a product against standards such as WCAG, Section 508, or EN 301 549. An organization completes the VPAT by documenting how the product performs against specific accessibility criteria.
An Accessibility Conformance Report (ACR) is the completed document that presents the results of that evaluation. In other words, a VPAT is the reporting framework, while an ACR is the final accessibility evaluation report created from it.
Key differences between VPAT and ACR
| VPAT | ACR |
|---|---|
| A template used to conduct an accessibility evaluation | The completed report containing evaluation results |
| Provides the structure and criteria for assessment | Documents conformance levels and findings |
| Used as the foundation for creating an accessibility report | Shared with customers, procurement teams, or stakeholders |
A VPAT does not represent a certification, and an ACR does not guarantee that a product is fully accessible. Instead, both are tools for documenting accessibility performance and providing transparency about a product's current accessibility status.
Which accessibility standards are included in an ACR?
The VPAT template that underlies most ACRs is built around three standards, and a single report can reference one, two, or all three depending on which markets and buyers the vendor is targeting: WCAG, Section 508, and EN 301 549. Each standard has its own edition history and its own table within the template, so an ACR referencing multiple standards isn't three separate reports stapled together — it's one product tested against overlapping but distinct criteria sets.
Which standards actually appear in a given ACR usually reflects who the vendor expects to read it. A company selling only to U.S. federal agencies may produce a report referencing Section 508 alone; a company selling internationally typically includes WCAG and EN 301 549 as well, since those cover buyers outside U.S. federal procurement.
How does WCAG apply to an Accessibility Conformance Report?
WCAG supplies the technical success criteria that most of an ACR's findings are actually tested against, since Section 508 and EN 301 549 both incorporate WCAG rather than defining a separate technical benchmark of their own. In practice, this means the "WCAG" section of an ACR is often the most detailed part of the report — it's where criterion-by-criterion findings for things like color contrast, keyboard operability, and text alternatives actually live.
Most ACRs report against WCAG 2.1 or 2.2, Level AA, because that's the level referenced by the procurement rules and legal precedent most buyers care about. A report that only claims Level A conformance is claiming something narrower than what most buyers are actually looking for, even though Level A is technically a valid, testable claim.
How does Section 508 relate to an Accessibility Conformance Report?
Section 508 is the U.S. federal law requiring federal agencies to procure accessible information and communication technology, and it's also the origin of the VPAT template that most ACRs are built on. An ACR referencing Section 508 is making a claim specifically relevant to that procurement context — it tells a federal buyer whether the product meets the technical requirements the agency is legally required to consider before purchasing.
The Section 508 table in an ACR maps closely to WCAG criteria, since the current revision of Section 508 incorporates WCAG 2.0 Level AA by reference rather than defining separate technical requirements. What Section 508 adds on top of WCAG is scope — it also covers things like software platforms, authoring tools, and support documentation, not just web content.
How does EN 301 549 fit into an ACR?
EN 301 549 is the technical standard referenced across EU accessibility law, and an ACR that includes it is signaling relevance to buyers operating under EU public-sector procurement rules or the European Accessibility Act. Like Section 508, it builds on WCAG for web content, but it also extends further — covering telecommunications equipment, hardware, and other ICT that WCAG alone was never written to address.
For a vendor selling into both U.S. federal and EU markets, a Section 508-only ACR isn't sufficient for EU obligations, even though both standards share a WCAG foundation. The overlap in technical content doesn't mean the compliance scope is the same, which is why an ACR aimed at both markets typically reports against all three standards side by side rather than treating one as a substitute for another.
Which products can have an Accessibility Conformance Report?
Any product that can be tested against a defined set of accessibility criteria can have an ACR — the format isn't limited to websites. Websites and web applications are the most common subject, but the same VPAT-based template also covers native mobile apps, desktop software, hardware devices, and even authoring tools and documentation.
What makes a product eligible isn't its category; it's whether it has a fixed, testable version. A SaaS product that changes weekly still gets tested and reported against one specific release, which is also why an ACR for a fast-moving product needs to be reissued more often than one for software that changes rarely.
Who uses Accessibility Conformance Reports?
Procurement and purchasing teams
Request the ACR as a required piece of vendor due diligence before a contract is signed, treating it as a gate rather than a nice-to-have.
Compliance and legal teams
Keep the ACR on file as documentation of due diligence, something to point to if an accessibility complaint or audit later asks what was checked.
Vendors and product teams
Produce the ACR as a sales-enablement document; the earlier and more honestly it's assembled, the fewer procurement cycles are lost.
Accessibility consultants and auditors
Are often the ones who actually run the testing behind the report, translating raw findings into the criterion-by-criterion format the template requires.
The document itself doesn't change between these readers — what changes is whether someone is requesting it as a condition of purchase or producing it as an asset to close a sale.
How is an Accessibility Conformance Report created?
Scoping
Deciding exactly which product, which version, and which platform (web, mobile, desktop) the report will cover. Testing means nothing until that scope is fixed.
Testing
Evaluating the product against each relevant success criterion under whichever standards the report will reference. This usually combines automated scanning with manual testing using a keyboard and screen reader.
Completing the template
The VPAT template gets filled in last, and it has to be last — the tables ask for a conformance level and remarks per criterion, and those don't exist until testing has actually produced findings.
Ongoing revision
Once published, the report isn't a one-time deliverable. It needs to be revisited whenever the product changes enough to affect any tested criterion.
What do accessibility conformance levels mean?
Each success criterion is rated using one of four conformance levels, and those levels are what actually carry the report's information — not the presence of WCAG references alone.
Supports
The product fully meets the criterion with no known exceptions; a reviewer can treat this as a clean pass for that specific requirement.
Partially Supports
Some but not all aspects of the criterion are met; a credible ACR explains what's missing in the remarks column rather than leaving the reader to guess.
Does Not Support
The criterion isn't met at all; this is the rating that should trigger the most scrutiny from a buyer, since it identifies a concrete, known gap.
Not Applicable
The criterion doesn't apply to this particular product, such as a caption requirement on a product with no audio or video content.
A report where every single criterion is marked "Supports" is worth extra scrutiny rather than extra confidence. Real products almost always have at least a few partial or unsupported criteria, so a uniformly perfect scorecard more often signals an under-tested report than a flawless product.
What information should be included in an Accessibility Conformance Report?
A usable ACR needs enough context for a reader to know exactly what was tested and how much confidence the findings deserve — not just a table of pass/fail ratings.
Product name and version
The specific release being described, since conformance claims don't transfer automatically to the next update.
Report date
When the testing was actually performed, which is what tells a reader whether the findings are still current.
Evaluation methods used
Whether findings came from automated testing, manual testing, or both, since that mix determines how thorough the report actually is.
Applicable standards and target
Which of WCAG, Section 508, or EN 301 549 were tested against, and which level (typically WCAG 2.1 AA).
Criterion-by-criterion results
A conformance level and explanatory remarks for each success criterion, not a single overall verdict.
Contact information
A named point of contact for follow-up questions, which is also one of the signals that distinguishes a credible report from a boilerplate one.
Leaving out any of these doesn't necessarily make the report dishonest, but it does make it harder to evaluate — a reader can't judge how much to trust a set of ratings without knowing when they were produced or how they were tested.
What are the benefits of an Accessibility Conformance Report?
For buyers: a concrete document to review
Gives procurement a document to request and review before signing a contract, instead of relying on a vendor's verbal assurance.
For buyers: risk shifted earlier
A gap found during vendor comparison can be raised before purchase, not discovered after deployment when the institution already owns the consequences.
For vendors: shorter sales cycles
With buyers who require accessibility documentation as a matter of policy, since the report is ready to hand over rather than assembled under deadline pressure.
For vendors: an internal record
Creates a record of what's actually been tested, useful for the product team's own roadmap even independent of any external request.
Trade-off worth naming: an ACR only reflects the version and scope it was tested against. A vendor that ships frequent updates but rarely refreshes its ACR is giving buyers a document that looks current but may no longer describe the product they'd actually be purchasing.
Frequently asked questions
Not exactly — a VPAT is the blank template, and an ACR is the completed version of that template for a specific product. In everyday conversation people often say "VPAT" to mean the finished report, and that shorthand is usually harmless, but the distinction matters the moment someone accepts an unfilled template as evidence of conformance.
No law directly mandates producing an ACR by that name, but the practical picture varies by jurisdiction and buyer. Section 508 requires U.S. federal agencies to procure accessible ICT and effectively expects vendors to document conformance, which is where the ACR format originated. Outside federal procurement, requirements vary by sector and region, so it's worth checking the specific procurement rules that apply to a given buyer.
A vendor's own internal team can prepare an ACR, provided they have the expertise to test against WCAG, Section 508, or EN 301 549 criteria accurately. Many organizations instead use an independent accessibility consultant or testing firm, since third-party testing carries more credibility with buyers who have no way to verify an internal team's self-assessment on their own.
An ACR should be updated whenever the product changes enough to affect any previously tested criterion — a new feature, a redesigned component, or a platform change can all shift the findings. A report describing a version that's a year or more out of date tells a buyer little about what they'd actually be purchasing today.
No — an ACR documents the result of testing at one point in time; it doesn't guarantee that the product will remain conformant as it continues to change. It also doesn't guarantee that every page or feature was tested with equal depth, which is why the evaluation methods section of a credible report matters.
Yes — while the ACR format originated in U.S. federal procurement, private-sector buyers, educational institutions, and enterprise vendor-risk teams now request it for the same reason federal agencies do: it's a concrete, checkable document rather than a general accessibility claim.
