How to write an Accessibility Conformance Report procurement trusts

An Accessibility Conformance Report earns trust by showing exactly where your product falls short. Procurement reviewers read a great many of these, and the report that says "Supports" on every row is the one they set aside.

An ACR is a completed VPAT®, the Voluntary Product Accessibility Template published by the Information Technology Industry Council (ITI), which holds the VPAT name as a registered service mark. Buyers use your ACR to compare products and to plan around gaps, and in government and higher education it often travels into the contract. Nobody issues it but you. That's why its credibility depends entirely on how it was made, and why experienced reviewers read it skeptically.

Start from the current template and the right edition

Use the current template, which is VPAT® 2.5Rev. A report on an older version tells the reviewer, before they read a single row, that nobody has looked at it in a while.

Then choose the edition your buyers need:

• Section 508 edition for U.S. federal buyers. The revised Section 508 standards incorporate WCAG 2.0 Level AA by reference, and this edition adds chapters on functional performance criteria, software, and support documentation.
• EU edition for buyers who reference EN 301 549, the European standard for ICT accessibility, including public-sector bodies in the EU.
• WCAG edition for buyers who ask about WCAG alone, which is common in private-sector and higher-education procurement.
• INT edition when you sell in several markets and want one report covering Section 508, EN 301 549, and WCAG.

Within any edition, state which WCAG version and level you evaluated. Many buyers now ask about WCAG 2.1 or 2.2 AA, even where a regulation references an older version. Reporting against the newer version is fine, as long as the audit actually tested it.

Base every row on an audit you can show

An ACR is a summary of evidence. The evidence is an audit of the specific product version named on the report: which screens and flows were tested, on which platforms, with which methods, by whom, and when. Without that, the report is an opinion.

Define the scope the way W3C's evaluation methodology, WCAG-EM, describes. Identify the product's key functions, choose a structured sample covering every distinct screen type and component, and add a few randomly selected screens to keep yourselves honest. Test that sample by hand against every criterion, with a keyboard and with screen readers, and use automated tools as a first pass, not the whole pass.

Reviewers can tell when a report was written from memory or from a scanner run. The remarks are generic, the criteria that need judgment say "Supports" with no explanation, and the methods never mention keyboard or assistive technology testing. Keep the audit's findings register. When a buyer asks what "Partially Supports" means on 1.4.3, the answer should be a ticket number, not a meeting.

Write remarks a reviewer can use

The conformance terms are fixed: Supports, Partially Supports, Does Not Support, and Not Applicable, plus Not Evaluated, which the template allows only for Level AAA criteria. The remarks column is where trust is won or lost. A useful remark says what fails, where it fails, who is affected, whether there's a workaround, and when a fix is planned.

Choose between the two failure levels deliberately. The template defines Partially Supports as some functionality not meeting the criterion, and Does Not Support as most functionality not meeting it. Neither definition weighs importance, so your remarks have to. A keyboard trap on the login screen may affect one screen out of two hundred, but if it stops people from signing in, say so plainly in the first sentence of the remark.

Compare those with the rows reviewers see far too often: "Supports" beside an empty remarks cell, or "Partially Supports" with a note that some features may not be fully accessible. The second is worse than useless. It tells the buyer you know about problems and won't say what they are.

Two smaller habits help. When the report covers more than one kind of content, prefix each remark with the part it applies to (Web, Electronic Documents, Software, Authoring Tool), as the template's own format suggests. And make sure "Not Applicable" is actually true. A product with onboarding videos can't mark the prerecorded captions criterion as not applicable.

Put methods, dates, and versions up front

The first page of the template asks for the product name and version, the report date, a product description, contact information, notes, and the evaluation methods used. Reviewers read that page first, and many decide there whether to read on.

• Product version and date. A report without both can't be matched to what the buyer is actually purchasing.
• Evaluation methods. Be concrete: manual keyboard testing; NVDA and JAWS with Chrome and Firefox on Windows; VoiceOver with Safari on macOS and iOS; automated testing with axe-core; color contrast analysis. List the versions you used.
• Who tested. Say whether testing was in-house or by a third party. Independent testing carries more weight, but an in-house audit described honestly beats an outside one cited vaguely.
• Scope notes. Say what's out of scope and why: a legacy admin console, a third-party payment iframe, a beta feature. Silence about a known area reads as concealment.

Red flags reviewers notice

Experienced procurement and accessibility reviewers look for the same tells:

• Every row says "Supports."
• Remarks are blank, one word long, or copied identically down the table.
• The template version is out of date, or a product released last year reports only against WCAG 2.0.
• There's no product version, no date, or a date several years old.
• No evaluation methods, or methods that never mention a keyboard or a screen reader.
• "Not Applicable" on criteria that obviously apply.
• Rows that contradict each other, such as "Supports" for 4.1.2 Name, Role, Value next to "Does Not Support" for keyboard access on the same custom widgets.
• Legal conclusions in place of technical findings, or conformance credited to an overlay or other third-party widget.

Each of these suggests the report was produced to clear a checkbox rather than to describe the product. A reviewer who spots one will discount the rest of the document, including the rows you got right.

A roadmap turns gaps into a plan

Every "Partially Supports" and "Does Not Support" row should map to an issue with an owner and a target release. You can summarize that roadmap in the remarks, as in the table above, or attach it as a separate document. Buyers often ask for one, and some write it into the contract. That's a good outcome. A gap with a dated plan is something a buyer can accept; a gap discovered after signing undermines every other row in the report.

Update the ACR whenever the product changes materially, and at least once a year. Version it alongside the product, so the report a buyer receives always matches the release they're evaluating.

Before you send the next one

Open your current ACR and check the first page: template version, product version, date, and methods. Then read the remarks column as a skeptical buyer would. If the report doesn't survive that reading, our VPAT® and ACR service writes reports from a fresh WCAG 2.2 accessibility audit, with remarks specific enough to answer the buyer's next question, starting at $1,900 with a Baclion audit.

Sources

1. Information Technology Industry Council (ITI), VPAT
2. U.S. Access Board, Information and Communication Technology: Revised 508 Standards and 255 Guidelines
3. Section508.gov: How to Create an ACR with a VPAT
4. W3C WAI: Website Accessibility Conformance Evaluation Methodology (WCAG-EM)
5. Understanding WCAG 2.2: Understanding Conformance