What is an Accessibility Conformance Report (ACR)?

What is an Accessibility Conformance Report (ACR)?

An Accessibility Conformance Report (ACR) is a document in which a vendor states how well one specific product meets accessibility standards such as WCAG, Section 508 or EN 301 549. It is the completed form of the VPAT template from the Information Technology Industry Council (ITI), and buyers use it to compare products during procurement.

An ACR is a self-report, not a certification. ITI does not review or approve VPATs, and a buyer may still require an independent audit in its solicitation. For each criterion the vendor picks one of four levels, Supports, Partially supports, Does not support or Not applicable, and adds remarks. For the template itself, see VPAT.

Why ACRs exist

Public bodies, universities and large companies need to compare many products on the same terms and to check accessibility before they buy. The ACR gives them one format to read.

• United States: the revised Section 508 standards apply to federal procurement of information and communication technology.
• European Union: EN 301 549 sets accessibility requirements for public procurement of ICT, and the European Accessibility Act has applied to many consumer products and services since 28 June 2025.
• Private buyers: many enterprise RFPs ask for an ACR even where no law requires it.

What an ACR contains

The current template is VPAT 2.5Rev (April 2025). It comes in four editions, and the vendor fills in the one the buyer asks for:

• WCAG: the Web Content Accessibility Guidelines, incorporating WCAG 2.2.
• 508: the revised Section 508 standards, incorporating WCAG 2.0.
• EU: EN 301 549, incorporating WCAG 2.1.
• INT: all three together, incorporating WCAG 2.2.

The WCAG rows follow the four principles of POUR (Perceivable, Operable, Understandable, Robust). For every criterion the report gives the conformance level and remarks: what was tested, on which platform, with which assistive technology, and what is known not to work. Version matters: WCAG 2.2 added 9 success criteria and removed 4.1.1 Parsing, so an ACR written against 2.1 does not answer the 2.2 criteria. See WCAG for the standard itself.

How to produce a credible ACR

1. Choose the edition and WCAG version the buyer asks for.
2. Fix the scope. Name the product, version and platform. A web app and an iOS app are different products and need their own scope or their own report.
3. Test, then write. Combine automated scans with manual tests: keyboard-only use and a screen reader on each platform you claim. Record the assistive technology and versions you used.
4. Be specific in the remarks. "Partially supports: all dialogs are keyboard operable except the date picker on the settings page" tells a buyer more than a bare "Supports".
5. Date it and refresh it with each major release. A report for last year's interface misleads the reader.
6. Add an independent audit when a contract asks for one.

Where automated tools fit

Automated scanners find only part of the WCAG problems, and an ACR cannot be generated from them. Lighthouse shows the point: its accessibility score is a weighted average of automated pass-or-fail audits, and the manual checks it lists, such as logical tab order and trapped focus, do not count towards the score. A page can score 100 and still fail criteria that need a human. Treat scans as an early warning and keep the manual evaluation behind the report. More on this in what performance testing can and cannot say about accessibility and in the roundup of accessibility testing tools.

LoadFocus does not produce ACRs or VPATs. What it does offer is trend tracking: page speed monitoring runs scheduled Lighthouse audits that record the Accessibility category next to Performance and Core Web Vitals, so a drop after a release shows up in the same history. That is a regression alarm for the automated part, not evidence of conformance.

Common ACR mistakes

• Claiming "Supports" without testing. Buyers run their own checks, and a report that falls apart costs trust.
• Bare answers with no remarks. A buyer needs to know what was tested and how.
• An outdated template or WCAG version that does not match what the buyer's solicitation names.
• Treating it as a sales sheet. An ACR is procurement documentation: technical and evidence-based.
• Never refreshing it after the product changes.
• Mixing platforms in one table without saying which result belongs to which.

FAQ: Accessibility Conformance Reports

Is an ACR the same as a VPAT?

Closely related. The VPAT is the blank template and the ACR is the version completed for a specific product. In practice buyers often say "VPAT" when they mean the ACR.

Is an ACR a certification?

No. It is the vendor's own statement. ITI does not review or approve VPATs, so its value depends on the testing and the honesty behind it.

Who writes an ACR?

Usually an accessibility lead or product owner, with the engineers and testers who evaluated specific features. Some vendors add an outside auditor for credibility.

Can automated tools generate an ACR?

No. Scanners such as Lighthouse check only part of WCAG, so the conformance claims in an ACR need manual evaluation with a keyboard and assistive technology.

Does my SaaS need an ACR if we do not sell to government?

No law says every vendor must have one. But universities, large companies and public bodies often ask for one in procurement, so it is worth having if you sell to them.