Accessibility Conformance Report: What It Is, Why It Matters, and How to Create One

An Accessibility Conformance Report (ACR) is a formal document that explains how a digital product (a website, web app, PDF library, or software platform) conforms to accessibility requirements such as WCAG. It’s often requested during procurement, compliance reviews, partnership onboarding, or internal governance—because it translates “we care about accessibility” into verifiable evidence.

Done well, an ACR supports inclusive design, reduces legal and reputational risk, and gives product teams a clear, actionable roadmap. Done poorly, it becomes a vague statement that can’t stand up to scrutiny. This guide explains what an ACR includes, how it connects to VPATs and WCAG, and how to build a report that’s credible and useful.

What is an Accessibility Conformance Report (ACR)?

An ACR is a structured assessment of accessibility conformance against a recognized standard. In many organizations, “ACR” is used interchangeably with a VPAT-based report—especially in U.S. and public-sector procurement. Technically:

• VPAT (Voluntary Product Accessibility Template) is the standard template used to document conformance to accessibility requirements.
• ACR is the completed report produced from that template, containing your product-specific results and explanations.

Most ACRs are aligned to one or more of these frameworks:

• WCAG (often WCAG 2.1 or 2.2 at Level AA) for web content and user interfaces
• Section 508 (U.S.) for federal procurement requirements
• EN 301 549 (EU) for ICT accessibility in procurement and compliance

If you work across regions, it’s helpful to understand how requirements map. For example, teams aligning with European expectations often rely on EN 301 549; see EN 301 549 Compliance: A Practical Guide for Digital Accessibility for practical context.

Why ACRs matter (beyond “checking the box”)

An ACR is valuable because it creates shared clarity for multiple stakeholders:

• Procurement and legal can assess risk and contract language based on documented conformance and known limitations.
• Product teams get a prioritized list of issues and exceptions tied to specific success criteria.
• Customers and users gain transparency about what works, what doesn’t, and what support exists.

ACRs also connect accessibility to inclusive experiences. Whether you’re designing for different languages and regulations (as discussed in Germany’s Accessibility Standards, Decoded: What Digital Teams Need to Know) or building experiences that are welcoming across identities and abilities (see Pride Month & June Observances: Digital Accessibility, Inclusive Design, and WCAG Compliance), a credible ACR makes accessibility measurable.

When you typically need an Accessibility Conformance Report

You may be asked for an ACR when:

• You’re responding to an RFP (especially government, education, healthcare, or enterprise)
• You’re launching a new product or major redesign and need release readiness
• You’re entering a new market with stricter accessibility expectations
• You’re developing an accessibility governance program and need baseline reporting

ACRs are particularly common in procurement workflows, but they can also support ongoing monitoring. An ACR should not be a “one-and-done” document; accessibility changes as code changes, content changes, and third-party components update.

What a strong ACR includes

1) Product scope and tested experience

Define exactly what was evaluated: URLs, application areas, user journeys, authenticated vs. unauthenticated experiences, supported browsers, mobile views, and any native apps. Clarity here prevents misunderstandings like “the report says accessible, but checkout isn’t included.”

2) Standard and conformance target

State the standard (e.g., WCAG 2.2 Level AA) and why it applies. If you must align to multiple frameworks (WCAG + Section 508 + EN 301 549), say so explicitly and describe how you approached overlaps.

3) Evaluation methods and tools

Credible ACRs explain how findings were produced, typically combining:

• Automated testing (fast detection of many common issues)
• Manual expert review (essential for keyboard access, focus order, labeling intent, error prevention, and more)
• Assistive technology checks (screen readers, zoom/magnification, voice control as relevant)

Using an accessibility platform like Corpowid (corpowid.ai) can help teams run automated audits and ongoing monitoring so the ACR is backed by repeatable evidence rather than a single snapshot.

4) Findings mapped to success criteria

This is the core: for each criterion, document the conformance level and notes. In VPAT/ACR language, you’ll often see outcomes like “Supports,” “Partially Supports,” “Does Not Support,” and “Not Applicable,” with explanations and issue references.

5) Exceptions, limitations, and third-party dependencies

Many products rely on embedded widgets, payment providers, maps, video players, or analytics dashboards. Your ACR should describe what’s third-party, what is configurable, and what is outside your control—while still documenting user impact and any mitigations (alternative flows, support channels, or accessible equivalents).

6) Remediation plan and timelines

Stakeholders want to know: if something doesn’t conform, what happens next? Include a realistic plan (priorities, owners, target dates). Even when you cannot commit to a date, provide a structured approach and explain how issues are tracked.

How to create an ACR step by step

Step 1: Set the conformance target and audience

Decide whether the ACR is for procurement, internal governance, or customer transparency. Procurement-focused ACRs often require VPAT alignment and very explicit “supports/partially supports” language.

Step 2: Define the test scope (and keep it defensible)

Pick representative templates and journeys (home, navigation, forms, authentication, search, purchase or sign-up, account management, error states). Include edge cases like modals, dynamic updates, and file downloads.

Step 3: Run audits and validate manually

Automated tools catch many issues quickly, but they can’t judge intent or usability. Confirm core experiences with keyboard-only navigation, visible focus, correct headings/landmarks, meaningful labels, error identification, and color contrast. If you publish content frequently, monitoring helps you catch regressions early; Corpowid (corpowid.ai) can support that ongoing cycle.

Step 4: Write clear, specific notes

Avoid vague phrasing like “supports with exceptions.” Instead, document:

• Where the issue occurs (page type, component, step in journey)
• User impact (who is affected and how)
• Workarounds (if any)
• Planned fix or mitigation

Step 5: Review internally and publish appropriately

Have accessibility specialists, product owners, and legal/procurement stakeholders review the ACR. Decide how it will be shared: on request, in trust portals, or alongside an accessibility statement. If you operate in multiple markets, align disclosures with regional expectations; for example, different locales may emphasize different compliance narratives (see Digital Accessibility in Georgia: Bridging the Gap for a regional lens).

Common mistakes to avoid

• Treating the ACR as marketing copy: It should be precise, evidence-based, and transparent.
• Overstating conformance: If checkout fails keyboard access, “Supports” is not defensible.
• Skipping assistive technology checks: A page can “pass” automation and still be unusable with a screen reader.
• Ignoring content and PDFs: Many user journeys include documents, help articles, and embedded media.
• Letting it go stale: If your UI changes monthly, your ACR should be reviewed on a defined cadence.

How an ACR supports inclusive design in practice

Inclusive design isn’t only about compliance—it’s about predictable navigation, understandable forms, accessible media, and flexible experiences for different needs. An ACR can highlight patterns that improve usability for everyone, such as consistent headings, clearer error messages, and better focus management. It also helps teams prioritize improvements that matter to real users, like accessible ticketing and live-score experiences (related considerations appear in Summer Sports Beyond the World Cup: Accessible Digital Experiences for Every Fan).

Conclusion: make your ACR a living, trustworthy document

An Accessibility Conformance Report is most effective when it’s accurate, scoped, and tied to a continuous accessibility process. Combine automated testing, manual validation, and ongoing monitoring; document what conforms, what doesn’t, and what you’re doing next. With the right workflow—and tools that help you audit and track issues over time—you can turn an ACR from a procurement hurdle into a practical blueprint for better digital accessibility.