Last spring a client forwarded me an email from a federal contracting officer. Their SaaS product had been shortlisted for a six-figure agency contract, and the officer’s single comment was: “Your ACR is dated and references the wrong edition. Resubmit.” The founder had paid a generalist agency $3,000 for that document twelve months earlier. Nobody told him the template had been revised, that “supports with exceptions” was retired terminology, or that an ACR older than one year gets flagged on sight in government reviews. We rewrote the report in ten days. They won the contract. That story repeats weekly, and it is almost always preventable.
What a VPAT and an ACR actually are
A VPAT is the blank form. An ACR is the finished report. The template is published and maintained by the Information Technology Industry Council (ITI), and the current release is VPAT Version 2.5Rev, published in April 2025. The template is free to download from ITI’s accessibility page and ships as Microsoft Word files in four editions:
| Edition | Standard reported against | WCAG version | Buyer type |
|---|---|---|---|
| VPAT 2.5Rev 508 | Revised Section 508 Standards | WCAG 2.0 | US federal agencies and their contractors |
| VPAT 2.5Rev EU | EN 301 549 | WCAG 2.1 | European public sector |
| VPAT 2.5Rev WCAG | WCAG only | WCAG 2.2 | Enterprise and private sector buyers |
| VPAT 2.5Rev INT | All three combined | WCAG 2.0, 2.1, 2.2 | Vendors selling across jurisdictions |
The edition follows the buyer, not your preference. If a solicitation cites the Revised 508 Standards, a WCAG edition ACR is a mismatch and reviewers will send it back. The INT edition costs more effort but covers nearly every reviewer you will face. For background on how these reports fit the broader buying process, see our earlier breakdown of how VPATs and ACRs work in procurement, or reference our structured VPAT checklist guide for procurement teams.
The structural anatomy of a credible ACR
An ACR has four mandatory content blocks before any conformance tables: the product name and version, the report date, a plain-language product description, and contact information for follow-up questions. Skip any of these and the document fails its first automated sanity check in a reviewer’s workflow.
The conformance tables follow, organized by success criteria. Each row needs a conformance level (Supports, Partially Supports, Does Not Support, or Not Applicable) and, for anything short of Supports, remarks explaining the limitation and the workaround. This is where most vendor reports collapse under scrutiny. One sentence per exception, tied to a specific, reproducible behavior.
Three rules govern the remarks column:
- Name the actual component or flow, not the criterion. “The data table in the export preview lacks header cell associations” passes review. “We are working on table accessibility” does not.
- State the user impact in one clause, then the workaround. Reviewers scan for both.
- Never claim conformance for functionality you did not test. Tested scope is the first thing a technical evaluator cross-checks.
Why most vendor ACRs get rejected
After reviewing dozens of procurement submissions and talking with Section 508 program managers, the same rejection triggers come up again and again. Federal buyers describe their evaluation expectations in plain terms on Section508.gov, and the pattern of rejections tracks that guidance closely.
| Rejection trigger | What the reviewer sees | The fix |
|---|---|---|
| ACR older than 12 months | Stale report date | Date every ACR and refresh on each major release |
| Wrong edition for the solicitation | WCAG edition submitted for a 508-cited contract | Match the edition to the cited standard |
| All “Supports” rows | Claims without evidence of testing | Include test methodology and dates |
| “Supports with exceptions” | Retired terminology from pre-2.4 templates | Use “Partially Supports” |
| Vague remarks | Generic statements, no component names | Name the flow, impact, and workaround |
| No product version | Cannot tie report to a release | Always state product name and exact version |
| Marketing copy in description | Reads like a sales deck | Plain functional description, third person |
What Most Guides Get Wrong
Most VPAT writing advice treats the document as a legal formality: fill every row with “Supports,” ship it, and apologize later. That advice is expensive. Procurement teams and accessibility program managers compare ACRs against each other. A report that admits three well-documented exceptions with workarounds scores higher than a spotless one with no evidence, because evaluators know a perfect claim for a complex web application is not credible. The contrarian truth: an honest “Partially Supports” with a dated remediation plan closes more deals than a wall of unqualified “Supports” rows. Reviewers at agencies cross-reference the ACR with the ICT Testing Baseline and the actual product. The fastest way to lose a bid is to make claims the product contradicts in a five-minute screen reader test.
Which edition and which WCAG version to target
WCAG 2.2 became a W3C Recommendation in October 2023 and is the version referenced by the WCAG edition of VPAT 2.5. The revised Section 508 standards, administered by the US Access Board under Section 508 of the Rehabilitation Act, incorporate WCAG 2.0 Level AA by reference, and the Access Board has open rulemaking activity on future updates, so the edition landscape can shift. The European Accessibility Act, in force since June 2025, pushed EN 301 549 requirements into private-sector buying across the EU, which is why the EU edition now appears in US vendor solicitations with multinational buyers.
My practical guidance for vendors: default to the INT edition unless the solicitation names a standard. It costs one extra table set and future-proofs the document against multi-jurisdiction RFPs. If you only sell into US federal agencies, the 508 edition is sufficient and slightly faster to complete.
Testing before you write a single row
An ACR is only as good as the audit behind it. Before writing, run a full manual and automated pass against the product, covering keyboard-only operation, screen reader flows (at minimum NVDA with Chrome and VoiceOver with Safari), zoom and reflow at 400 percent, and form error identification. Automated scanners catch 20 to 30 percent of WCAG failures on a typical web application, as we analyzed in our breakdown of AI accessibility testing tools. The remainder, the ones auditors find first, are semantic and interaction-level issues that only manual testing surfaces.
Tie your methodology to the W3C’s Web Content Accessibility Guidelines 2.2 and the Section 508 ICT Testing Baseline so the report cites recognizable, verifiable procedures. Record dates, testers, environments, and assistive technology versions. When a reviewer asks how you reached a “Supports” claim, you should be able to hand over the test evidence within a day.
For teams newer to the standard itself, our WCAG walkthrough for website owners covers the success criteria structure that the ACR tables mirror row for row.
A working checklist for the writing phase
Use this sequence when drafting or refreshing an ACR. Each step maps to a rejection trigger above.
- Download the current VPAT 2.5Rev edition directly from ITI. Never reuse an older ACR as your starting file.
- Confirm the solicitation’s cited standard and pick the matching edition: 508, EU, WCAG, or INT.
- State the product name, exact version, report date, and a functional product description on page one.
- Document your test methodology, dates, environments, and assistive technology before filling conformance rows.
- Fill every row with one of the four current levels: Supports, Partially Supports, Does Not Support, Not Applicable.
- For every exception, write a remark that names the component, states the user impact, and gives a workaround.
- Remove every instance of “supports with exceptions” and any pre-2.5 terminology.
- Add a contact email for accessibility questions. A named owner beats a generic inbox.
- Have someone who did not write the report spot-check five claims against the live product.
- Calendar a review date twelve months out, or tie the refresh to your next major release.
- Cross-check your public accessibility statement so it matches the ACR. Contradictions between the two are a red flag for legal exposure, a pattern we detail in our ADA website lawsuit trends analysis.
- Store the ACR and its test evidence together so any renewal request is a same-day response.
Costs, timelines, and when to bring in help
DIY ACR writing, assuming the product is genuinely close to conformant, takes 30 to 60 hours for a mid-size web application. External accessibility consultancies commonly quote $3,000 to $8,000 for a full audit plus a defensible ACR, and the market now includes cheaper template-fill services that produce exactly the weak reports reviewers reject. My rule: if you cannot reproduce a “Supports” claim in a five-minute test, pay for a real audit first. The Department of Justice’s ADA web accessibility guidance makes clear that businesses open to the public face standing exposure on accessibility regardless of procurement, so the audit has value beyond the RFP.
Keeping the ACR alive after submission
Treat the ACR as a living artifact tied to your release cycle, not a one-time PDF. Every significant UI change can invalidate a conformance row. The vendors who win repeat government and enterprise business keep three habits: a dated ACR refresh on each major release, a public accessibility page that mirrors the report’s claims, and a remediation log that converts “Partially Supports” rows into “Supports” with version numbers and dates. That log is the single most persuasive artifact in a renewal review because it demonstrates an operating process, not a one-off document scramble.
Conclusion
A winning ACR in 2026 is current, correctly edition-matched, honestly marked, and backed by recorded testing. The vendors who lose bids are not the ones who admit partial conformance. They are the ones who submit stale, vague, or overclaimed reports that a reviewer can puncture in minutes. Download the current 2.5Rev template from ITI, match the edition to the solicitation, test before you claim, write remarks a stranger could act on, and refresh on every release. Do that, and the ACR stops being a procurement obstacle and becomes one of the strongest trust documents your sales process has.
