Skip to main content
Simkins & Elgazar
Contact us

How to Evaluate a Vendor's ACR Before You Sign

An ACR is the vendor's own claim. Check it for completeness, spot-check a few criteria, and require an Issue Detail Supplement and contract terms.

By Ahmed Elgazar. Published . 7 min read.

Topics: ACR, VPAT, procurement, WCAG 2.1

Treat a vendor's Accessibility Conformance Report (ACR) as a claim to verify. Check that it names the product version, report date and test method, that it is written against the standard you need, and that every "Partially Supports" or "Does Not Support" row explains itself. Then test a few criteria yourself, ask for the GSA Issue Detail Supplement, and put remediation and retest terms in the contract. Section508.gov's own advice is to "conduct independent conformance validation testing" before relying on vendor claims.

This is general information, not legal advice.

What does an ACR prove?

An ACR is a Voluntary Product Accessibility Template (VPAT) filled in for a specific product. ITI publishes the template as a reporting format. Section508.gov's FAQ says a product "will still be considered for purchase even if all of the Section 508 Technical Standards are not met," and that vendors are expected to test their own products and report the results.

So the report shows what the vendor says about its product. It becomes useful when you can see how the vendor got there and check a sample against the real product. Our post on how to read an ACR covers the layout. This one covers the buyer's side.

Does it say which standard it tested against?

Check this first, because the editions differ. ITI lists four: a 508 edition (which includes WCAG 2.0), an EU edition (EN 301 549, which includes WCAG 2.1), a WCAG edition (which includes WCAG 2.2) and an INT edition that combines all three.

Under the Title II web rule, a state or local government must make the web content and mobile apps it provides or makes available, "directly or through contractual, licensing, or other arrangements," meet WCAG 2.1 Level A and AA (28 CFR 35.200), by April 26, 2027 for entities of 50,000 or more (special districts excepted) and April 26, 2028 for the rest, unless the entity can show a fundamental alteration or undue financial and administrative burdens. An ACR built only on the 508 edition reports against 2.0. If you are buying software your public entity will provide to residents, ask for a report that evaluates against WCAG 2.1 AA or higher. See our deadline post for who gets which date.

What should a credible ACR contain?

Section508.gov's guidance on building an ACR lists the basics. Use it as a checklist:

  • Company and product name, with a version number.
  • A report date (month and year) and a contact.
  • A description of the evaluation methods.
  • A conformance level for every criterion in scope.
  • A remark explaining every "Partially Supports" and "Does Not Support" row.

If a report leaves out the version, the date or the method, ask for a corrected one before you go further. Section508.gov's FAQ says an updated ACR may be required whenever a product changes, a version change or bug fix for example, so a report written for last year's release may not describe what you are buying.

What are the red flags?

In the ACRWhat to do
"Not Evaluated" on criteria your users will hitSection508.gov says this "does not provide any assurance of accessibility." Ask the vendor to evaluate it or treat it as a gap.
"Partially Supports" with no remark, or a vague oneAsk which screens, components or workflows fail. The template calls for an explanation.
"Not Applicable" on a criterion that plainly applies, such as captions for a product with videoAsk why.
No version, no date, or no methodAsk for a complete report.
Report covers WCAG 2.0 onlyAsk for 2.1 AA, per 35.200(b).
"Supports" on every rowCheck the definition. Supports means at least one method meets the criterion "without known defects." Test some rows.

How do you spot-check an ACR yourself?

Pick three or four criteria that your core task depends on, and test them on the version you will actually run. The goal is to see whether the vendor's rows match reality, so a sample is enough.

Criterion (level)Quick check
SC 2.1.1 Keyboard (A)Complete the main task with the keyboard alone. All functionality must be operable through a keyboard interface.
SC 1.4.3 Contrast (Minimum) (AA)Measure body text and button text with a contrast checker. Normal text needs at least 4.5:1.
SC 4.1.2 Name, Role, Value (A)Turn on a screen reader and move through a custom control, such as a dropdown or dialog. Its name and role must be announced.
SC 1.2.2 Captions (Prerecorded) (A)If the product plays video, check that captions exist and cover dialogue.

If a row says "Supports" and you can break it in a few minutes, the rest of the report deserves less trust. For a deeper check on web content, Section508.gov points to the Trusted Tester process, "the standardized approach for manual inspection of Web content." Automated scans cover only part of the criteria, which we explain in manual vs automated testing.

What should you require beyond the ACR?

Section508.gov's buyer guidance for federal agencies lists three items as required documentation for off-the-shelf ICT: the ACR, a Supplemental Accessibility Report (SAR) describing evaluation methods and accessibility features, and the Issue Detail Supplement. A state or local buyer is not bound by that guidance, but can ask for the same three.

The Issue Detail Supplement is a GSA companion to the ACR (its page was last reviewed in August 2026). For each open issue the vendor gives a severity level (Critical, Major or Minor), the affected page, screen, component or workflow, the impacted user group, and any workaround. GSA recommends it "whenever a solicitation requires or requests an ACR."

Section508.gov's buyer guidance also suggests asking for remediation plans for features that do not fully conform, an accessibility test plan with typical user scenarios, and the right to do hands-on testing on the final commercially available release.

What belongs in the contract?

The ADA.gov first-steps page says a public entity is "still responsible for ensuring the accessibility of its web content and mobile apps, even if it outsources the accessibility work to somebody else," and tells entities to review existing vendor contracts. It lists practices some entities found helpful, including a warranty that the vendor meets stated technical standards, and says DOJ does not endorse any one approach. Terms worth considering. These are our suggestions, not rule requirements:

  • A named standard (WCAG 2.1 Level AA) and a representation that the ACR is accurate.
  • Acceptance testing before go-live, with your right to reject.
  • Deadlines to fix issues listed in the Issue Detail Supplement, by severity.
  • Your right to retest after fixes.
  • An updated ACR with each major release.

What does a real procurement dispute show?

This is a public case, not one of our engagements. In CourtSmart Digital Systems, Inc., decided by GAO on February 13, 2004, a Social Security Administration request for quotations required vendors to return a VPAT with their quotations. GAO recorded that "No other vendor's system was tested for section 508 compliance, although at least CourtSmart's quotation indicated that its system was section 508 compliant," and that "York's quotation indicated that its system was not section 508 compliant." GAO sustained the protest. GAO added that CourtSmart's quotation would have been acceptable "presuming its system was tested to verify its claim of section 508 compliance." The decision predates the Revised 508 Standards, so the rules have changed, but the point carries over: a VPAT states the vendor's claim, and testing is what confirms it.

If you are on the vendor side and need a report you can stand behind, see our VPAT and ACR preparation service.

Sources

Talk to a principal.

Small, direct and responsive. Both principals do the work on every project; no layered overhead.

Send a messageDownload the capabilities statement