Accessibility Conformance Report (ACR): What It Is, What to Include, and How to Use It

An Accessibility Conformance Report (often abbreviated ACR) is a structured document that explains how a website, web app, or software product conforms to accessibility standards—most commonly WCAG (Web Content Accessibility Guidelines). It is used to communicate what’s accessible today, what’s partially supported, what isn’t supported, and what evidence backs those claims. In other words, an ACR turns accessibility from a vague promise into measurable, reviewable information.

Because accessibility is both a user experience issue and a compliance requirement, an ACR is increasingly important for procurement, vendor risk management, and ongoing governance. It helps buyers understand what they’re getting, and it helps product teams prioritize fixes based on real gaps rather than assumptions.

What is an Accessibility Conformance Report (ACR)?

An ACR is a report that maps a product’s accessibility support against a defined standard (such as WCAG 2.1 AA or WCAG 2.2 AA) and explains the level of conformance for each criterion. Many ACRs are created using the VPAT (Voluntary Product Accessibility Template) format, which is widely used in enterprise and government procurement. If you’ve heard “VPAT” and “ACR” used interchangeably, you’re not alone—VPAT is the template, and ACR is the completed report.

For a deeper explanation of the terminology and why it matters in purchasing workflows, see VPAT vs ACR: What They Mean for Accessibility Compliance (and Procurement).

Why ACRs matter beyond compliance

• Transparency: Stakeholders can see where accessibility works and where it doesn’t.
• Accountability: ACRs create a baseline for improvement and retesting.
• Better planning: Clear gaps help teams estimate effort, budget, and timelines.
• Reduced risk: Demonstrates due diligence, which can help when responding to legal or regulatory questions.

When do you need an ACR?

Not every organization needs an ACR on day one, but many end up needing one sooner than expected. Common scenarios include:

• Enterprise sales or vendor onboarding: Large customers often require an ACR before purchase.
• Public sector or education procurement: Formal accessibility documentation may be mandatory.
• Regulated industries: Travel, airlines, and hospitality frequently need accessible booking and customer flows, where reporting becomes part of compliance readiness.

If your product supports online booking or customer journeys, accessibility requirements can surface quickly. These sector-specific guides provide context on what “conformance” looks like in practice: Digital Accessibility for Airlines: WCAG, Inclusive Booking, and Compliance and Digital Accessibility for the Travel & Hospitality Industry: WCAG, Inclusive Design, and Compliance.

What should an Accessibility Conformance Report include?

ACRs vary in depth, but strong reports consistently include the elements below. The goal is to make claims that are specific, testable, and tied to real user experiences—not just a checkbox status.

1) Scope and product description

Define what’s being assessed so the reader knows exactly what the ACR covers. Include:

• Product name, version, and release date
• Platforms and environments tested (web, iOS, Android, specific browsers)
• Key user flows in scope (login, checkout, account settings, etc.)
• Any out-of-scope areas (legacy pages, third-party embedded widgets)

2) Standards and conformance target

State the standard(s) you’re reporting against, such as WCAG 2.1 Level AA or WCAG 2.2 Level AA. If you’re using the VPAT format, specify the VPAT edition and which tables are included (WCAG, Section 508, EN 301 549, etc.).

3) Methodology and testing evidence

A credible ACR explains how results were obtained. Include:

• Automated testing: What tools were used and what they can/can’t detect.
• Manual testing: Keyboard-only navigation, focus order, visible focus, error identification, zoom/reflow checks.
• Assistive technology testing: Screen readers (e.g., NVDA/JAWS/VoiceOver), speech recognition if applicable.
• Sampling approach: Which pages/templates were tested and why.

Tools can streamline repeatable checks. For example, Corpowid (corpowid.ai) can help teams run automated accessibility audits and monitoring to catch regressions between releases—useful when the ACR needs to be updated regularly rather than treated as a one-time document.

4) Findings mapped to WCAG criteria

This is the heart of the report: a criterion-by-criterion assessment. In VPAT-style ACRs, each row typically includes a conformance level (such as Supports/Partially Supports/Does Not Support) and remarks. High-quality remarks include:

• Which components fail and under what conditions
• Examples of affected screens/pages
• User impact described in plain language (e.g., “screen reader users can’t determine required fields”)
• Known workarounds (if any) and their limitations

How to write stronger “remarks and explanations”

Many ACRs become hard to trust because the remarks are too generic (“Some images missing alt text”). Strong remarks connect evidence to user impact to remediation intent. Use this simple structure:

• Where: “Checkout page > Shipping step”
• What: “Error message is shown visually but not programmatically associated with the field.”
• Who it affects: “Screen reader users may not learn why the form submission failed.”
• Why (WCAG link): “Related to WCAG 3.3.1 Error Identification and 1.3.1 Info and Relationships.”
• Status/plan: “Fix planned for Q3; retest after release 4.2.”

Common pitfalls to avoid

• Over-claiming “Supports” when only a small sample was tested
• Ignoring third-party content that is essential to the user journey (payments, chat, maps)
• No dates or versions, making the report impossible to validate later
• No assistive tech coverage, which often misses critical usability barriers

Keeping your ACR current (the part most teams miss)

An ACR is most useful when it reflects the product customers will actually use. If you ship frequently, a report created once a year can become misleading. Consider an “ACR maintenance” practice:

• Update triggers: New UI framework, major redesign, new checkout flow, or new PDFs/documents.
• Scheduled revalidation: Quarterly or per major release, depending on change volume.
• Regression monitoring: Repeat automated checks on key templates and track trends over time.

This is where pairing documentation with ongoing monitoring helps. Corpowid (corpowid.ai) can support continuous checks and centralized issue tracking, which makes it easier to justify ACR updates with clear before/after evidence.

ACR and the accessibility statement: how they work together

An ACR is often written for buyers and auditors, while an accessibility statement is written for the public. They complement each other:

• ACR: Detailed criterion-level conformance, methodology, and limitations.
• Accessibility statement: Commitment, known issues (high level), contact channel, and alternative access options.

If you sell software to enterprises, the ACR may be a gating requirement for deals. This guide provides a sales-oriented view of why the documentation matters and how to approach it: VPAT for SaaS Vendors: A Practical Guide to Accessibility Compliance and Enterprise Sales.

Practical checklist before you publish an ACR

• Does it clearly state the version, date, and tested environments?
• Are remarks specific enough that another tester could reproduce findings?
• Have you included at least keyboard and screen reader coverage for critical flows?
• Are third-party components addressed transparently?
• Is there a plan to maintain the report as the product changes?

Conclusion: treat your ACR as a living accessibility contract

An Accessibility Conformance Report is not just paperwork—it’s a practical tool that connects WCAG requirements to real product behavior. When written with clear scope, credible testing, and specific remarks, it builds trust with customers and creates a roadmap for continuous improvement. Treat it as a living document, update it as your product evolves, and pair it with repeatable audits and monitoring so conformance doesn’t drift between releases.

Accessibility expectations are rising globally, sometimes in quiet but meaningful ways. For an example of how accessibility momentum can build through policy and practice, read Lithuania's Quiet Push Toward an Accessible Web.