An Accessibility Conformance Report (ACR) is a document a vendor writes to show how its software, hardware or content meets a set of accessibility standards. Public buyers ask for one during market research and bid evaluation. It is often built on a template called a VPAT, and it is a vendor statement, not an audit.
Definitions in plain words
ICT means information and communication technology: software, web apps, hardware, documents and support material.
VPAT is the Voluntary Product Accessibility Template. Vendors fill it in to produce an ACR.
Revised 508 Standards are the accessibility requirements that apply to federal ICT purchases. The Access Board issued the updated rule on 18 January 2017 and it took effect on 18 January 2018.
The federal Section508.gov page on ACRs says buyers use them to assess ICT accessibility during market research and when evaluating proposals. It also recommends that vendors prepare an ACR for any ICT they plan to market to the federal government.
Why a security tool buyer sees this request
A scanner, a dashboard or an IDE plugin is still software that staff and sometimes students touch. Public buyers carry accessibility duties for the tools they roll out, so the intake form often asks for an ACR next to the security questionnaire. If you sell or evaluate developer security tooling, expect it.
What an ACR usually covers
| Part | What it tells the buyer |
|---|---|
| Product and version | Exactly which release was evaluated |
| Standards claimed | For example the Revised 508 Standards or a WCAG level |
| Evaluation method | Manual testing, automated testing, assistive technology used |
| Criterion table | Supports, partially supports, does not support, or not applicable, per criterion |
| Remarks | Where the product falls short and any workaround |
Section508.gov also describes an optional Issue Detail Supplement that gives buyers more product detail, and an ACR Editor that can produce machine readable reports in the OpenACR format.
How to read one without being fooled
- Check the version. A report for last year's release says little about this one.
- Look for "partially supports" rows. A report that claims full support everywhere deserves a closer look.
- Read the remarks. Good reports name the gap and the workaround.
- Check the method. Automated checks alone catch only part of the problem.
- Ask for a date and a contact who can answer follow up questions.
The same Section508.gov page describes ACRs as vendor prepared and does not describe independent verification of the claims. So treat the report as the start of a conversation. A short hands on test with a keyboard and a screen reader on your own workflows will tell you more than another page of prose.
Note that the Section508.gov ACR page is marked as last updated in March 2018, so check current federal guidance if a bid depends on the details.
If you are the vendor
Keep one ACR per major surface: the web dashboard, any desktop app, the command line documentation, and editor plugins. Update it with each major release. Publish it where buyers can find it, and be ready to explain every "partially supports" row.
Safeguard publishes a free scan at gold.safeguard.sh/scan if you want to see the product surface before asking for formal documents. Check with your own accessibility lead for what your institution needs.
Quick check
Is a VPAT the same as an ACR?
No. The VPAT is the template. The ACR is the finished report a vendor produces with it.
Does an ACR prove a product is accessible?
No. It is a vendor statement of conformance. Test the product yourself before relying on it.
Sources
- Section508.gov: Accessibility Conformance Reports
- Section508.gov: IT Accessibility Laws and Policies
Last reviewed: 19 October 2026.
