Blog

Accessibility Conformance Report (ACR): The Complete 2026 Guide

TestParty
TestParty
November 5, 2026

Last updated: November 5, 2026. This guide is general information based on public sources and TestParty's audit experience β€” it is not legal advice.

An Accessibility Conformance Report (ACR) is a completed VPAT: the same standardized template, filled in with real per-criterion findings for one specific product, and handed to a buyer who asked for it. This guide covers which VPAT edition to file under, how to mark conformance levels honestly with real example rows, the mistakes that get ACRs rejected in review, who should author one, and how it fits alongside EAA obligations in 2026.

Key numbers: ITI publishes the VPAT in its 2.5Rev edition (April 2025) across four editions β€” 508, EU, WCAG, and INT β€” the template every ACR is built on (ITI). WCAG 2.2 defines 86 success criteria in force, 55 of them at Levels A and AA β€” the set a WCAG or INT edition ACR maps against (W3C). Automated tooling detects roughly 60–70% of issues in TestParty's audit work across 100+ brands; the remaining findings require manual assistive-technology testing, and an ACR row marked "Supports" without that manual pass is unverified. As of 2026, TestParty has remediated 35 million-plus accessibility issues β€” the evidence base a credible ACR's remarks column has to describe accurately.

What Is an Accessibility Conformance Report?

An Accessibility Conformance Report is a VPAT template completed with actual test findings for one product, submitted to answer a specific buyer's procurement question β€” not a certification, and not the blank form itself.

The distinction trips up almost everyone the first time a buyer asks for one. ITI, the Information Technology Industry Council, publishes the VPAT β€” Voluntary Product Accessibility Template β€” as a blank, standardized shell with a row for every applicable success criterion. Nobody "has" a VPAT in any meaningful sense; a vendor downloads the shell, tests the product, and fills in every row, and the resulting document β€” the ACR β€” is what gets emailed to a buyer. Four groups ask for one routinely: enterprise procurement and security-review teams screening a SaaS purchase; U.S. federal agencies and contractors, where Section 508 makes an ACR close to mandatory for ICT purchases; school districts and universities, often via similar state-level procurement language; and, increasingly since the EAA took effect, EU buyers whose own compliance obligations now flow down to their vendors. Our VPAT vs. ACR vs. accessibility statement comparison covers how this document sits next to the other two people confuse it with; this page is the how-to for producing the ACR itself.

Which VPAT Edition Do You Fill Out?

ITI publishes four VPAT 2.5Rev editions β€” 508, EU, WCAG, and INT β€” and the buyer's own legal exposure decides which one they'll actually accept.

EditionStandard it maps toWho typically requires it
508Revised Section 508U.S. federal agencies and federal contractors
EUEN 301 549EU public-sector buyers and EAA-covered private services
WCAGWCAG 2.0, 2.1, or 2.2Enterprise buyers with no statutory standard in mind
INTAll three above, side by sideVendors selling across U.S., EU, and general enterprise markets at once

A vendor selling only into U.S. federal procurement has no reason to complete the EU columns, and one selling only to EU public bodies can skip the 508-specific language entirely. Most Shopify-adjacent platform vendors default to INT anyway, since one completed document then answers whichever edition an RFP names. Whichever edition you pick, the underlying testing barely changes: EN 301 549's current web clause maps to WCAG 2.2 Level AA, the same set the WCAG and INT editions score against β€” only the column headers differ by edition.

How Do You Complete One Honestly?

Every applicable row gets one of four conformance levels β€” Supports, Partially Supports, Does Not Support, or Not Applicable β€” backed by a remarks entry naming what was actually tested, not a marketing description of the feature.

An all-"Supports" ACR is not good news; it is the fastest way to signal that nobody tested the product against every row. Here is what honest rows look like for a composite Shopify apparel brand, Kestrel Outfitters, on its WCAG 2.2 AA edition:

CriterionConformance LevelRemarks
1.1.1 Non-text Content, APartially SupportsProduct photography carries descriptive alt text; swatch-color thumbnails on variant selectors are missing alt text. Fix scheduled Q1 2027.
1.4.3 Contrast (Minimum), AAPartially SupportsBody text and primary buttons meet 4.5:1; sale-price text on product cards renders at approximately 2.8:1 against its background.
2.4.7 Focus Visible, AASupportsVerified via keyboard traversal across storefront, cart, and checkout in Chrome and Safari; focus indicator meets contrast and thickness requirements.
4.1.2 Name, Role, Value, ADoes Not SupportCustom quantity stepper on product pages exposes no accessible name to assistive technology; native fallback control in development.
1.4.10 Reflow, AANot ApplicableNo content requires two-dimensional scrolling at 320px width; layout reflows to a single column across every template tested.

The honesty rule behind every row: a procurement reviewer, or an opposing expert in a later dispute, reads a "Supports" claim against the live product, not the vendor's intentions. Base every row on testing that actually happened β€” in TestParty's audit work, that means roughly 60–70% automated coverage (axe-core, WAVE, Lighthouse) plus manual testing with screen readers and keyboard-only navigation, scoped with WCAG-EM sampling so tested pages represent the product's real templates, not just its homepage. A remarks column reading "Partially Supports β€” see above" with no description of what "above" tested is not a finding; it's a placeholder wearing a checkbox.

What Mistakes Get ACRs Rejected?

Reviewers reject ACRs for patterns, not typos: a document that is all "Supports" with no stated methodology, no product version or evaluation date, marketing language standing in for a remarks entry, a scanner-only basis for every claim, or a report that quietly went stale after the last major release.

All-"Supports," no methodology. A spotless table with no line describing how it was tested reads as unverified to anyone who has reviewed more than one ACR β€” real products fail some rows, and zero failures gets treated as marketing collateral, not evidence. Missing version and date. A claim with no product version and no evaluation date can't be checked against anything; it describes an unspecified snapshot of an unspecified build. Marketing language in the remarks column. "Fully accessible and inclusive by design" tells a reviewer nothing about what was tested and reads as copy pasted from a landing page. Scanner-only basis. A methodology note naming only an automated tool discloses, correctly, that roughly 30% of applicable criteria were never evaluated β€” reviewers who know that ceiling treat the report as partial. Stale reports. An ACR describing a product version from before a major redesign is worse than none at all, since it invites a direct comparison between the claim and the current site.

Who Should Author It β€” and Can You Self-Author?

Either a vendor's own team or an independent third-party auditor can author an ACR, and both are legitimate β€” the difference is which one a given buyer will actually accept without follow-up questions.

A self-authored ACR is faster, cheaper, and often sufficient for smaller commercial buyers who trust a vendor's own testing process. It carries less weight the moment a government agency or a large enterprise security team wants independent verification β€” at that point, buyers specifically ask who performed the testing and what credentials they hold. Recognized markers here are IAAP's CPACC, WAS, and CPWA certifications, plus DHS's Trusted Tester for Web among federal vendors; naming a certified tester by role, not just a headcount, is what a rigorous questionnaire is actually probing for. A third-party-audited ACR carries the auditor's name and methodology on the document itself, which is what most public-sector and enterprise reviews specifically request.

In TestParty's audit work, an ACR's rows are built from the same findings register that comes out of a scoped accessibility audit β€” daily automated scans plus monthly expert manual testing feed a dated evidence file, and the remarks column is drawn directly from it rather than reconstructed from memory when an RFP lands. That pipeline matters more than who signs the document: an ACR built from real audit evidence, self-authored or not, survives a reviewer's follow-up question; one built from a best guess does not.

How Do ACRs Fit the EAA and Procurement in 2026?

An ACR and an EAA accessibility statement are two different documents answering two different questions β€” a buyer's procurement question and a regulator's statutory one β€” and EU-facing vendors typically need both, not one instead of the other.

For EU buyers, the EU or INT VPAT edition maps to EN 301 549, the harmonized standard the European Accessibility Act's Annex I references, which is why an EU procurement questionnaire increasingly names a VPAT edition even outside government contracts. That's separate from the EAA's own requirement that covered providers publish a public accessibility statement describing their service's conformance β€” our EAA accessibility statement guide covers that requirement in full; neither document substitutes for the other. The case for getting this right is a revenue one as much as a compliance one: enterprise and government RFPs routinely screen out vendors who can't produce a current, credible ACR before a deal reaches legal review, making the document a sales unlock, not just paperwork. Keeping the underlying evidence current β€” the same cadence that feeds a WCAG compliance report β€” is what lets a vendor answer an RFP's accessibility section in days instead of scrambling against a deadline. The broader discipline this depends on is covered in our guide to accessibility compliance documentation.

Frequently Asked Questions

Is an ACR the same thing as a VPAT? No, though the terms get used interchangeably in casual conversation. The VPAT is the blank template ITI publishes; the ACR is that template filled out with real conformance findings for a specific product. When a buyer says "send us your VPAT," they almost always mean the completed ACR.

Can we self-author our ACR, or do we need an outside auditor? Both are legitimate, and the right choice depends on the buyer. Self-authored ACRs work for most commercial buyers who trust internal testing; government agencies and large enterprise security reviews more often want a third-party-audited ACR naming an independent tester and methodology.

How many rows should be "Supports" on a real ACR? However many the testing actually found β€” there is no target percentage. An ACR where every applicable row reads "Supports" with no stated methodology is a red flag to an experienced reviewer, not a selling point, since almost no real product clears every WCAG 2.2 AA criterion.

Does an ACR mean our product is legally compliant? No. An ACR is a vendor's representation of test findings, not a certification β€” there is no government or W3C certification of ACR accuracy. A false or unverifiable "Supports" claim invites more scrutiny than an honest "Partially Supports" would have.

How often should we update our ACR? After every release that touches the tested product, and at minimum annually regardless. An ACR describing a version of the product that no longer exists invites a direct comparison between the document's claims and the current build.

Where do we get the actual VPAT template to fill out? Download the current edition directly from ITI's VPAT page. For U.S. federal buyers specifically, Section508.gov's ACR guidance also covers OpenACR, a machine-readable alternative some agencies now accept alongside the traditional document format.

Like everything at TestParty, this article reflects our cyborg philosophy: AI handles the heavy lifting, humans bring the expertise. The data and opinions here are based on publicly available sources as of publication. TestParty is a participant in the accessibility market β€” we believe in transparency, so we encourage you to cross-reference our claims and evaluate all options for your business.

Stay informed

Accessibility insights delivered
straight to your inbox.

Contact Us

Automate the software work for accessibility compliance, end-to-end.

Empowering businesses with seamless digital accessibility solutionsβ€”simple, inclusive, effective.

Book a Demo