An ACR (Accessibility Conformance Report) is a completed accessibility audit document that records how a digital product conforms to WCAG, Section 508, or EN 301 549, required for procurement under U.S. federal law and the European Accessibility Act.
An Accessibility Conformance Report (ACR) is a formal document that records how well a digital product or service conforms to established accessibility standards such as WCAG 2.2, Section 508, and EN 301 549. ACR stands for Accessibility Conformance Report. It is produced by completing a Voluntary Product Accessibility Template (VPAT®) and is the standard evidence format required in government and enterprise procurement. Without an ACR, vendors are routinely disqualified at the RFI/RFP stage.
An ACR provides a structured, criterion-by-criterion account of how a product meets or falls short of each requirement within the chosen standard. Each criterion is assigned a conformance level: Supports, Partially Supports, Does Not Support, or Not Applicable.
Unlike a pass/fail certificate, an ACR is tied to a specific product version and must be updated with each major release. Procurement officers, IT governance teams, and disability rights advocates use these reports to compare vendors and verify ongoing accessibility compliance.
For vendors, providing an accurate ACR signals transparency. Even a "Partially Supports" rating is typically viewed more favourably than no documentation, because it demonstrates awareness of barriers and a commitment to remediation.
Accessibility is increasingly a legal requirement, not a best practice. Several major regulations either mandate ACR documentation directly or create procurement environments where one is effectively unavoidable.
Regulation | Who it applies to | Maximum penalty |
|---|---|---|
Section 508 (U.S.) | Federal agencies and vendors supplying ICT to the U.S. federal government | Contract termination; legal action under the Rehabilitation Act |
European Accessibility Act (EAA) | Private-sector companies with products/services sold in the EU | Up to €100,000+ (varies by member state); product withdrawal |
EN 301 549 | Public sector bodies across the EU; EAA-regulated products | Enforcement by national accessibility regulators |
ADA Title III (U.S.) | Businesses open to the public, including websites | Up to $75,000 (first violation); $150,000 (subsequent) |
The terms VPAT and ACR are used interchangeably in most business conversations, but they refer to two distinct things. Understanding the difference matters for documentation accuracy.
Aspect | VPAT® | ACR |
|---|---|---|
What it is | The blank template | The completed report |
Full name | Voluntary Product Accessibility Template | Accessibility Conformance Report |
Created by | Information Technology Industry Council (ITI) | The vendor, developer, or third-party auditor |
When it exists | Before evaluation | After the evaluation is completed |
Purpose | Provides a standardised structure for assessment | Communicates actual conformance findings |
Content | Empty fields and criteria headings | Filled-in conformance levels, remarks, and methodology |
What people mean when they ask | "Send us your VPAT" almost always means: send your completed ACR | — |
In plain terms, the VPAT is the blank form; the ACR is the filled-in form. When a procurement team asks for your "VPAT," they want the ACR.
The VPAT template itself is freely available from the IT Industry Council (ITI). There are four editions: WCAG, Section 508, EU (EN 301 549), and INT (all three combined). Most vendors use the INT edition to cover all major procurement requirements in a single ACR document.
A high-quality Accessibility Conformance Report (ACR document) includes several standardised sections:
Conformance level | Meaning |
|---|---|
Supports | At least one method in the product facilitates this requirement without known defects |
Partially Supports | Some functionality of the product does not meet this criterion |
Does Not Support | The majority of product functionality does not meet the requirement |
Not Applicable | This criterion is not relevant to the product (e.g., a video criterion for a text-only tool) |
Producing an accurate ACR for accessibility requires a structured evaluation process. Here are the five stages:
1. Select the applicable standard(s). Choose which framework(s) to evaluate against: WCAG 2.1 Level AA, WCAG 2.2, Section 508, EN 301 549, or a combination. The choice depends on the regulatory environment of the product's intended market.
2. Define the product scope. Specify the product name, version, and exact components being evaluated: web interface, mobile app, API, and documentation. The scope sets clear boundaries for what the ACR report does and does not cover.
3. Conduct the accessibility evaluation. Combine automated scanning (using tools such as Axe, Deque, or Clym's accessibility scanner), manual expert review, and testing with assistive technologies, including screen readers (NVDA, JAWS, VoiceOver) and keyboard-only navigation.
4. Assign conformance levels to each criterion. For each success criterion in the chosen standard, assign one of the four conformance levels above and provide explanatory remarks for any criterion that does not fully support or is not applicable.
5. Publish and maintain the ACR document. Record the evaluation methodology, tools used, and date of evaluation. Publish the completed ACR on your website or provide it to procurement contacts on request. Update it with each major product release.
Neither Section 508 nor the EAA mandates the VPAT/ACR format by name, but both create legal environments where an ACR becomes practically unavoidable.
Under Section 508, U.S. federal agencies must ensure that any ICT they procure meets the Section 508 standards. Procurement officers are directed to obtain vendor documentation demonstrating conformance. In practice, a completed ACR using the VPAT template is the universally accepted format. Without one, a vendor is unlikely to pass the supplier qualification stage.
Under the European Accessibility Act (EAA), businesses must ensure that in-scope products and services meet EN 301 549 requirements from June 2025. The EAA requires technical documentation demonstrating conformance. An ACR structured against EN 301 549 is the established method for meeting this documentation obligation.
In both cases, an ACR helps organisations:
Scenario | Expected response | Practical outcome |
|---|---|---|
Criterion rated "Partially Supports" | Vendor provides remarks and remediation timeline | The product may still qualify if barriers are minor or being actively addressed |
Criterion rated "Does Not Support" | Procurement team assesses risk; may request a remediation plan | The product may be conditionally accepted or disqualified depending on the criterion's criticality |
No ACR provided | The procurement team cannot assess conformance | Vendor is typically disqualified at the RFI/RFP stage |
ACR is outdated (wrong product version) | Procurement team flags version mismatch | The vendor must supply an updated ACR before review continues |
Generating an accurate ACR requires deep technical understanding of WCAG criteria across every component of a digital product. Manual evaluation alone is time-consuming and prone to inconsistency. Most organisations use specialised ACR compliance tools to support the process:
Clym's accessibility tools provide automated scanning and remediation guidance, giving teams the data-driven findings needed to populate an ACR with accurate, version-stamped results. Rather than a one-time exercise, Clym supports ongoing monitoring so ACRs remain current as products evolve.
An ACR is one component of a comprehensive accessibility compliance programme. Within a broader strategy, it becomes part of continuous evidence of compliance.
Compliance area | What it covers | Relationship to the ACR |
|---|---|---|
Accessibility audit | Technical evaluation of a product against WCAG criteria | The audit produces the findings that populate the ACR |
Accessibility statement | Public declaration of a product's accessibility status | References and links to the published ACR |
Remediation programme | Systematic fixing of identified barriers | Informed by ACR findings, drives improvements in future ACR versions |
Assistive technology testing | Real-world testing with screen readers, switch access, etc. | Provides the human-validation layer of ACR evidence |
Monitoring and scanning | Ongoing automated checks between major evaluations | Flags regressions before the next ACR update are needed |
Training and governance | Developer and designer accessibility education | Ensures future product versions require fewer remediations in subsequent ACRs |
Clym provides a unified digital accessibility platform combining automated scanning, issue reporting, remediation guidance, and accessibility statements, giving your team the foundation needed to produce and maintain an accurate ACR.
An Accessibility Conformance Report is a formal document that records how well a digital product meets established accessibility standards such as WCAG 2.2, Section 508, or EN 301 549. It is produced by completing a VPAT® and is the standard format used in government and enterprise procurement to verify accessibility.
ACR stands for Accessibility Conformance Report. It is always used alongside the VPAT (Voluntary Product Accessibility Template), the blank template used to produce the report. The two terms are often used interchangeably, but technically, VPAT is the empty form, and ACR is the completed document.
The VPAT is the blank template created by the IT Industry Council (ITI); the ACR is the completed, filled-in version of that template. When a procurement team asks for your "VPAT," they are requesting your completed ACR. The VPAT is the tool; the ACR is the output.
No regulation mandates the VPAT/ACR format by name, but both Section 508 and the EAA create procurement environments where an ACR is effectively required. U.S. federal agencies must verify ICT accessibility before purchasing, and the EAA requires technical documentation demonstrating EN 301 549 conformance. An ACR is the universally accepted way to provide this evidence.
An ACR is tied to a specific product version and does not technically expire, but it becomes unreliable as the product evolves. Best practice is to produce an updated ACR with each major product release or at least annually. Procurement teams will often reject an ACR if the product version it references is significantly out of date.
The VPAT template, used to create an ACR, is freely available from the IT Industry Council (ITI) at itic.org. There are four editions: WCAG, Section 508, EU (EN 301 549), and INT (all three combined). Most vendors use the INT edition to produce a single ACR document covering all major markets.
An accessibility statement is a short, public-facing page on your website declaring your product's current accessibility status and providing contact details for users who encounter barriers. An ACR is a detailed technical document recording criterion-by-criterion conformance findings. The accessibility statement often links to the ACR, but they serve different audiences: the statement is for end users; the ACR is for procurement and legal teams.
For most organisations, WCAG 2.2 Level AA is now the correct choice, as it supersedes WCAG 2.1 and adds nine new success criteria. Section 508 formally references WCAG 2.0 but accepts 2.1/2.2 evaluations, while EN 301 549 (2021 edition) maps to WCAG 2.1. Many vendors evaluate against WCAG 2.2 and Section 508 simultaneously to cover all major procurement requirements in a single ACR. Clym recommends targeting WCAG 2.2 Level AA as the baseline.
Adam is the Head of Digital Marketing at Clym, where he leverages his diverse expertise in marketing to support businesses with their compliance needs and drive awareness about data privacy and web accessibility. As one of the company’s original team members, Adam has been instrumental in shaping its journey from the very beginning. When he’s not diving into marketing strategies, Adam can be found cheering on his favorite sports teams or enjoying fishing.
