A software vendor came to me last year after losing a $380,000 federal contract. Their product scored high in the technical evaluation. Their pricing was competitive. They lost because the solicitation asked for an Accessibility Conformance Report and they attached a two-paragraph marketing letter claiming their application was fully accessible. The contracting officer disqualified them without a second round.
That story repeats every quarter. Enterprise and government buyers now treat accessibility documentation as a strict requirement, not an optional feature. If you sell software, a web platform, or any digital product to large organizations, you will be asked for a VPAT or an ACR. This post explains what those documents actually represent, which version your buyer expects, and how to produce one that passes procurement review instead of killing your deal.
The VPAT Is the Template, the ACR Is the Report
The terms get mixed up frequently, and that confusion causes friction during procurement. A VPAT, or Voluntary Product Accessibility Template, is a blank document. It is a standardized template maintained by the Information Technology Industry Council (ITI) that lists accessibility success criteria in tabular form and asks you to report your product’s conformance level for each one. You can download the current official editions directly from the ITI VPAT page.
An ACR, or Accessibility Conformance Report, is what you produce after you fill the VPAT out. It is the finished, product-specific report that a procurement team actually evaluates. When an RFP says “submit your VPAT,” they almost always mean “submit your completed ACR.” Nobody wants your blank template.
This distinction matters because of what it implies about effort. An ACR is a formal claim, backed by systematic testing, about how your interface behaves against specific technical standards. Producing one means your team tested the product with assistive technology, documented specific observations, and wrote remarks explaining gaps. Buyers can tell the difference between verified testing and a marketing PDF in thirty seconds.
The Four Editions and Which One Your Buyer Needs
The VPAT comes in four distinct editions. Submitting the wrong edition is a fast way to get your paperwork rejected.
| Edition | Standards Covered | Who Asks For It | Typical Use Case |
|---|---|---|---|
| WCAG | WCAG 2.0, 2.1, or 2.2 only | Private-sector corporations, commercial SaaS | Web-only apps, client portals, SaaS platforms |
| Section 508 | Revised Section 508 (incorporates WCAG 2.0 AA + Chapter 5/6) | U.S. federal agencies, federally funded bodies | FAR acquisitions, DoD, GSA, federal contractors |
| EN 301 549 | European standard (WCAG + European public procurement rules) | EU public sector, global firms selling in Europe | European tenders, European Accessibility Act compliance |
| INT | All three standards combined in one document | Global enterprise procurement teams | Cross-border vendors selling across US and EU |
The rule of thumb: if you sell to the U.S. federal government, use the Section 508 edition, with no substitutions. If the buyer is a state university, a hospital system, or a Fortune 500 company, ask their procurement contact which edition they prefer. Most accept the INT edition because it covers all three frameworks, though it is the longest to complete.
The Section508.gov VPAT guidance is valuable reading before you begin. It outlines what federal reviewers expect, including an explicit warning: an ACR with every single row marked “Supports” and no substantive remarks is treated as a major red flag.
Scope is equally important. The World Wide Web Consortium established WCAG 2.2 as the official recommendation in late 2023, and most modern enterprise RFPs specify WCAG 2.1 AA or 2.2 AA. An ACR claiming conformance only to WCAG 2.0 signals stale documentation. Our web accessibility WCAG guide details how specific criteria relate across versions if you need background on the underlying technical requirements.
How to Fill Out an ACR That Survives Review
A credible ACR requires three components: a stated testing methodology, honest conformance levels, and detailed remarks that confirm human verification. Omit any one of them and an experienced reviewer will spot the shortcut.
1. State Your Testing Methodology
The ACR has a dedicated section for evaluation methods. Never write generic phrases like “tested for accessibility.” Document the exact tools and procedures applied. A credible methodology statement specifies the exact assistive technology versions, browsers, and manual techniques used during testing:
Evaluation methods: Manual inspection with NVDA 2025.3 on Chrome 131,
JAWS 2025 on Microsoft Edge, and VoiceOver on Safari 18 (macOS and iOS).
Full keyboard-only navigation testing across all primary user workflows.
Automated accessibility linting with axe DevTools 4.10 used as a secondary check.
Color contrast ratios evaluated with Colour Contrast Analyser 3.5 against
WCAG 2.2 AA requirements.That paragraph shows a reviewer two things: you tested with real assistive technologies, and you recognize that automated testing catches only a fraction of issues, typically between 30% and 40% of all WCAG defects. If your stated methodology is “we ran Lighthouse,” you inform the procurement officer that manual verification never occurred. If you want to see how professionals structure this testing pipeline, our breakdown on AI website accessibility auditing details the workflow mechanics.
2. Use Conformance Levels Honestly
Each success criterion receives one of four standardized ratings:
- Supports: The functionality of the product has been evaluated and meets the criterion without known defects.
- Partially Supports: Some functionality meets the criterion, but at least one documented aspect does not satisfy the requirement.
- Does Not Support: The majority or entirety of the functionality fails the criterion.
- Not Applicable: The criterion does not apply to the product (such as audio-only descriptions for an app with zero multimedia).
Product teams often feel pressured to mark every row “Supports.” That instinct damages credibility. Every software application has accessibility defects. A complex SaaS platform claiming 100% support across 78 WCAG 2.2 AA criteria is either a single static page or an untested submission.
“Partially Supports” is not a disqualification. It is the standard rating for mature software. Procurement reviewers read the accompanying remarks to evaluate whether defects affect their users. A contrast issue on an administrative settings panel presents far less operational risk than an unlabeled submit button in a student enrollment flow.
3. Write Remarks That Prove Real Evaluation
Remarks determine whether procurement approves your document. Contrast these two entries for WCAG criterion 1.3.1 (Info and Relationships):
Weak Remark:
“Product supports this criterion.”
Strong Remark:
“Partially Supports. All form fields in primary user flows contain programmatic label associations. The administrative reporting table uses presentational markup without header cell associations on three custom views; remediation is scheduled for release 4.2 in Q2 2027. Workaround: raw data exports in CSV format contain full semantic headers.”
The strong remark names the specific component, identifies the exact defect, gives a release target for remediation, and provides an immediate workaround. That specificity allows the buyer’s risk committee to evaluate the software fairly.
Section 508 Chapter 5 vs Chapter 6: Software and Support Documentation
When filling out a Section 508 VPAT, many teams focus solely on the WCAG table and ignore Chapters 5 and 6. This is an immediate disqualifier for federal contracts.
Revised Section 508 contains distinct technical chapters:
- Chapter 5 (Software): Covers non-web applications, platform accessibility services, focus indication, assistive technology interoperability, and user preferences (such as respecting system-level high contrast modes).
- Chapter 6 (Support Documentation and Services): Governs user guides, training manuals, support portals, and customer service channels.
If your product exports statements, manuals, or invoices as PDFs, Section 508 requires those documents to meet accessibility standards. You cannot mark Chapter 6 as “Not Applicable” if you distribute PDF user manuals or provide web-based technical support. Our walkthrough on PDF compliance guide explains the structure required for digital documents, while our notes on PDF remediation tips help remediate legacy attachments.
Why Self-Attested ACRs Get Rejected
First-party ACRs are legally permissible. Nothing in the ITI guidelines requires an external author. In practice, self-attested reports get dismissed frequently for three consistent reasons:
- The Perfection Bias: Internal engineering teams are emotionally attached to their work. They test standard paths and overlook keyboard trap conditions or dynamic aria-live announcements.
- Boilerplate Text: Reviewers process dozens of ACRs each month. Generic remarks copied across 50 rows indicate that testing never took place.
- Missing Audit Logs: When procurement officers request raw screen reader transcripts or defect tickets during diligence, self-attesting vendors cannot produce them.
We saw this pattern directly during client audits. Early reports produced by internal dev teams often looked tidy on paper, but lacked concrete defect tickets. When we introduced rigorous manual validation into our web compliance guide process, clients started reporting actual flaws alongside remediation timelines. Acceptance rates in procurement increased because buyers trust honest documentation.
When to Hire an External Auditor
Independent third-party audits become necessary when specific conditions are met:
- The contract value exceeds your tolerance for deal slippage.
- The buyer is a federal entity, a state higher education system, or a regulated healthcare provider.
- Your product has never undergone manual assistive technology testing.
- Your previous ACR is older than twelve months, and you have shipped substantial UI changes.
A full third-party audit for a web application including a completed ACR typically costs between $8,000 and $25,000 depending on workflow depth, and requires three to six weeks. Cheap automated scan tools marketed as instant VPAT generators produce shallow summaries that fail procurement screening, forcing vendors to restart the entire review cycle under tight deadlines.
Retesting Cadence: Maintaining an ACR Over Time
An ACR is a snapshot of an application at a specific version. When you deploy a redesign, update your design system, or introduce major workflows, parts of your report become inaccurate.
Maintain this schedule:
- Annual Audit: Re-evaluate your core user journeys every twelve months to catch cumulative drift.
- Release Verification: When deploying a major release, run targeted manual tests on affected components and update corresponding remarks.
- Version Numbering: Always display the software version number and audit completion date on the cover page. An ACR dated three years ago signals an unmaintained accessibility posture.
Turning the ACR into a Sales Advantage
Most software companies treat accessibility documentation as a hurdle to clear when an RFP forces the issue. Forward-thinking sales teams treat it as a commercial asset.
Place your ACR on your security and trust portal alongside your SOC 2 summary and privacy policy. Provide the document to account executives so it accompanies initial enterprise proposals. When competing against vendors who scramble for weeks to assemble accessibility paperwork, having a verified, detailed ACR immediately available shortens sales cycles and establishes operational trust.
10-Point Pre-Submission Audit Checklist
Before sending your completed ACR to an enterprise or government procurement team, run through this verification checklist:
- Correct edition selected (Section 508 for US federal, WCAG for commercial SaaS, EN 301 549 for Europe, INT for global enterprise).
- Stated methodology specifies exact assistive technologies, versions, and browsers used.
- No universal “Supports” across all criteria without detailed remarks.
- All “Partially Supports” entries list specific components and remediation targets.
- Workarounds documented for any known accessibility blockers in core workflows.
- Section 508 Chapters 5 and 6 filled out if software or documentation is included.
- Software version number and evaluation date clearly stated on the report cover.
- External dependencies and third-party widgets explicitly documented in remarks.
- Alt text, keyboard tab order, and screen reader announcements verified manually.
- Contact email provided for accessibility inquiries and defect reporting.
Summary
The VPAT is a template; the ACR is the completed report that procurement officers inspect. Choose the correct edition for your target market, detail your manual testing setup, score conformance honestly, and provide concrete remarks detailing component status and remediation timelines. When you approach accessibility reporting with technical rigor, your ACR becomes a powerful asset that protects deals and accelerates enterprise revenue.
