What is an Accessibility Conformance Report (ACR)?

What is an Accessibility Conformance Report (ACR)?

An Accessibility Conformance Report (ACR) is a document that declares the extent to which a digital product (website, web app, mobile app, software, hardware) conforms to accessibility standards — primarily WCAG (Web Content Accessibility Guidelines) and Section 508 of the US Rehabilitation Act. ACRs are typically authored using the VPAT (Voluntary Product Accessibility Template) published by the Information Technology Industry Council (ITI), which provides a standardized format for reporting against each WCAG success criterion.

An ACR isn't a certification or audit — it's a vendor self-attestation. The vendor lists every applicable WCAG criterion and reports whether the product Supports, Partially Supports, Does Not Support, or Not Applicable. Honest ACRs include explanatory notes on edge cases and known issues. Marketing-driven ACRs claim full support without evidence — and usually fall apart under real audits.

Why ACRs exist

Three drivers:

• US federal procurement. Section 508 requires federal agencies to buy accessible technology. ACRs are the standard way vendors demonstrate conformance during procurement — required by GSA Schedule 70 and most agency RFPs.
• Higher education and large enterprise procurement. Universities and Fortune 500 buyers increasingly require ACRs as part of their RFP responses. Procurement teams use them as a filter.
• EU EAA (European Accessibility Act). Effective June 2025, the EAA requires accessibility statements for many digital products sold in the EU. Vendors with ACRs are pre-positioned to meet the EAA's requirements with minimal extra work.

What an ACR contains (VPAT 2.x format)

The current VPAT 2.5 format (latest as of 2026) covers four standards in one document:

• WCAG 2.1 (Levels A and AA). 50+ success criteria across the four POUR principles (Perceivable, Operable, Understandable, Robust).
• Revised Section 508. US federal procurement standard, harmonized with WCAG 2.0 since 2018.
• EN 301 549. European standard for ICT accessibility, mandated under the EAA.
• WCAG 2.2 (in VPAT 2.5+). Newer success criteria (target size, focus appearance, etc.).

For each criterion, the ACR lists:

1. Conformance level (Supports / Partially Supports / Does Not Support / Not Applicable).
2. Remarks and explanations — concrete details on what was tested, known issues, workarounds, and roadmap for unsupported criteria.

How to write a credible ACR

Test before you write

The biggest mistake: writing the ACR from feature documentation without actually testing. Before any criterion gets "Supports", run automated scanners (axe, WAVE) AND manual screen reader testing (NVDA on Windows, VoiceOver on Mac/iOS, TalkBack on Android). Document what you tested, on what platforms, with what assistive technologies.

Be honest about "Partially Supports"

Almost every real product partially supports many criteria. Common honest partial-support scenarios: "keyboard navigation works for the main flows but the dropdown widget on the settings page traps focus", or "alt text is provided for product images but auto-generated charts don't have descriptive text alternatives". Documenting these honestly builds buyer trust; hiding them surfaces in the buyer's own audit and kills the deal.

Update with each major release

An ACR snapshot from 18 months ago is worse than no ACR — it actively misleads buyers about current state. Re-test and republish with each major UI release.

Get an external audit for high-stakes deals

For large government or higher-ed contracts, buyers may require third-party audited ACRs. Specialist firms (Deque, Level Access, TPGi) audit your product against WCAG and produce an audited ACR. More expensive but more credible.

Common ACR mistakes

• Claiming "Supports" without testing. Sales-driven ACRs that say everything works fail buyer audits and damage reputation.
• Outdated VPAT version. Buyers expect VPAT 2.4 or 2.5; submitting a 2.0 from 2018 looks careless.
• No remarks. Just listing "Supports" without explanation provides no useful information. Buyers want to know what was tested and how.
• Treating ACR as marketing. An ACR is procurement documentation, not a sales sheet. Honest, technical, evidence-based.
• Forgetting to update. Stale ACRs are worse than missing ACRs — they actively misrepresent current state.
• Mixing platforms. If your product has a web app + iOS app + Android app + desktop app, each may need its own ACR (or a clearly-segmented combined one).

FAQ: Accessibility Conformance Reports

Is an ACR the same as a VPAT?

Closely related but technically different. The VPAT is the template (a blank form). The ACR is the filled-in document (a completed VPAT for a specific product). In practice the terms are often used interchangeably — "send me your VPAT" usually means "send me your ACR".

Who writes the ACR?

Typically: an internal accessibility lead or product manager + engineers who tested specific features + sometimes an external auditor for verification. Larger companies have dedicated accessibility programs; smaller companies often hire specialists for VPAT engagements.

How long does it take to write an ACR?

For a small product: 2-4 weeks of focused effort, mostly testing time. For a large enterprise app: 2-3 months including coordination with product, design, and engineering teams. Audited ACRs take longer.

How much does an external audit cost?

$10,000-50,000+ depending on product complexity. Worth it for high-value contracts where buyers require independent verification or where reputation matters.

Can automated tools generate the ACR?

No — automated tools (axe, WAVE, Pa11y) catch maybe 30-40% of accessibility issues. They're useful for scanning at scale but the ACR's credibility comes from manual testing with assistive technologies. Tools augment human testing; they don't replace it.

Does my SaaS need an ACR if we don't sell to government?

Recommended even without government customers. Higher education, Fortune 500 enterprises, and EU customers (under the EAA from June 2025) increasingly request ACRs. Having one published on your website signals procurement-readiness and accelerates enterprise deals.

How LoadFocus relates to accessibility audits

While LoadFocus focuses on performance not accessibility, accessibility audits often need performance verification too — pages that fail Core Web Vitals create accessibility issues for users on slow networks or low-end devices. Pair your VPAT/ACR work with LoadFocus speed audits across regions to validate accessibility-supporting performance baselines (e.g. ensuring screen reader users on 3G connections still get reasonable page-load times).