VPATs and accessibility conformance reports (ACRs) explained

The terms

• VPAT: the blank template published by the Information Technology Industry Council (ITI).
• ACR: the Accessibility Conformance Report, which is the VPAT after a vendor fills it in for a specific product and version.

In practice people say "VPAT" for the finished report as well. The template has editions that map to different standards: WCAG, Revised Section 508 and EN 301 549 (and an international edition covering all three).

Who asks for one

• U.S. federal agencies evaluating technology under Section 508.
• State and local governments and public universities preparing for the ADA Title II web rule.
• Large enterprises with procurement checklists.
• EU buyers, using the EN 301 549 edition (European Accessibility Act).

What goes in it

For each WCAG success criterion the report lists a conformance level (supports, partially supports, does not support or not applicable) and remarks explaining the evidence. The strength of the report depends on the testing behind it. Buyers often ask who tested, when, with which tools and assistive technology, and on which version of the product.

How to prepare one

1. Define the product, version and what is in scope.
2. Test against the WCAG criteria in the edition you need, using automated tools plus manual and assistive technology testing.
3. Fix what you can before you publish, and describe what remains honestly.
4. Fill in the template with specific remarks, not just ratings.
5. Date it and update it with each major release.

Where Clir fits

A Clir report gives you the technical evidence that feeds into a VPAT or conformance report. It documents automated findings and review items for the pages you test, which can feed into the testing a VPAT needs. A conformance report still requires human evaluation of the full product. See the methodology.

The four editions of the template

The VPAT is a template maintained by the Information Technology Industry Council. It comes in editions, so a vendor can report against the standard a buyer cares about. Once completed, the document is called an Accessibility Conformance Report, or ACR.

The conformance levels you can report

• Supports: the functionality meets the criterion with no known defects.
• Partially Supports: some functionality does not meet the criterion.
• Does Not Support: the majority of functionality does not meet the criterion.
• Not Applicable: the criterion does not apply to the product.
• Not Evaluated: the product has not been evaluated against the criterion. This is available only on the WCAG edition at Level AAA.

For every row, the Remarks and Explanations column is where the real information lives. "Supports" with no explanation tells a buyer very little.

How to fill one out honestly, step by step

1. Pick the product and version. The report describes one thing, so name it, with the release or date.
2. Pick the edition. Match the buyer's request. If unsure, ask.
3. List the tasks. Record the main things a user does with the product.
4. Test each criterion. Use automated tools, keyboard checks and a screen reader for every row. Do not guess.
5. Record evidence. For each row, note what you tested and what you found. Link to screenshots or test notes.
6. Choose the level honestly. If part of a criterion fails, use Partially Supports and say which part.
7. Add a summary and contact. Give a name or address for questions.
8. Date it. Reports go stale, so state the date and plan the next review.

Common mistakes in reports

• Marking every row "Supports" without testing.
• Copying the previous version's report.
• Describing a product the buyer is not purchasing.
• Leaving remarks empty.
• Reporting only automated test results.
• Omitting any contact or date.

Do you need one?

If you sell software, a website tool or an online service to governments, universities or large companies, you will probably be asked for one. If you run a small store that sells to consumers, you probably will not. In that case an accessibility statement and a record of your testing are the more useful documents.

What a scan contributes to a conformance report

An automated scan can supply some of the evidence for rows that depend on detectable issues, such as labels, names and contrast. It cannot fill in rows that need judgment, such as keyboard operation, focus order or the quality of captions. A scan report is also not a VPAT, and a VPAT is not a certification. It is a vendor's own statement about a product, which a buyer may check. See what scanners find best.

A worked example of two rows

To see how remarks make a report useful, compare two ways of filling in the same row for a hypothetical product.

The useful entries tell a buyer what works, what does not, how it was tested and what to do. They also make the vendor look more trustworthy, not less.

Who should prepare the report

Ideally, someone who understands the product and the standard. In small companies that is often a developer with help from a consultant. An outside evaluator can add credibility, but the vendor remains responsible for the content. Whoever prepares it should keep notes of the test method, so the report can be updated later.

Using the report in a sale

• Share it early. Buyers appreciate not having to ask.
• Be ready to explain any "Partially Supports" row and to describe the plan to fix it.
• Offer a time to demonstrate the product with a screen reader, if the buyer is interested.
• Give the buyer a contact for accessibility questions, not only for sales.
• Update the report whenever a significant release changes the picture.

What buyers do with it

Procurement staff often compare several reports side by side. They look for consistent testing, evidence of effort, honest gaps and a believable plan. A report full of unexplained "Supports" ratings tends to draw skepticism, and an experienced buyer may test the product to check. If the product is used by employees, schools or the public, buyers also think about who will need support and how quickly problems get fixed.

A realistic timeline for a first report

If you cannot yet meet the standard

Many early-stage products have gaps, and buyers know it. The answer is to be open. Complete the report with honest levels, a short roadmap and the dates you expect to fix key items. If the buyer needs something you cannot yet provide, say so and suggest a workaround, such as an alternative way to do the task. A frank report that shows you understand the problems is often more convincing than a flawless one that raises doubts.

Checking a vendor's report as a buyer

1. Confirm the product name, version and date match what you are buying.
2. Choose three tasks your users will perform and test them yourself with a keyboard.
3. Look for remarks on every row, especially the ones marked Supports.
4. Ask what testing was done and by whom.
5. Add the key gaps to your contract, with dates and a way to escalate.

VPAT, ACR and the other documents buyers mention

People sometimes use these terms interchangeably, and that creates confusion. When a buyer asks for a VPAT, they almost always mean a completed ACR for the product they are considering. If you are unsure, ask what the buyer wants to see, which edition they prefer and how recent the report should be.

Plain-language summary

A VPAT is a form. An ACR is the form filled out about one product. It is the vendor's own statement, and it is only as good as the testing behind it. For a small business that sells to consumers, an honest accessibility statement and a record of testing are usually more useful than a formal report. For a company that sells to governments or large organizations, a well-prepared ACR can shorten a sale and prevent unpleasant surprises.

Your questions about VPATs and reports

• Do I need an outside evaluator? Not required. An independent evaluation adds credibility, particularly for large sales, but a careful internal evaluation with good notes is acceptable for many buyers.
• Can I reuse last year's report? Only if the product has not changed in ways that affect accessibility. Otherwise, update it and change the date.
• What if we fail many rows? Report that honestly. Buyers often accept gaps when there is a clear plan, and may ask for fixes as a contract term.
• Should I publish the report? Many vendors do, which saves repeated requests. Make sure it is current and that the page hosting it is accessible.
• What if the buyer has its own form? Complete it, but a VPAT-based report often provides most of the evidence.

A short checklist before you send a report

1. The product name, version and date are correct.
2. The edition matches the buyer's request.
3. Every row has a level, and every Partially Supports or Does Not Support row has an explanation.
4. A contact for accessibility questions is named.
5. The document itself is accessible, for example a tagged PDF or a web page.
6. Someone other than the author has read it.

Whichever side of the table you are on, treat the report as the start of a conversation. A buyer who asks good questions and a vendor who answers honestly will usually reach a sensible agreement about what to fix and when.

If you are the buyer: how to read one

1. Check the product name, version and date. A report for last year's release says little about this one.
2. Look for who tested and how: automated tools only, or also manual and assistive technology testing.
3. Be cautious of a report where every row says Supports with no remarks.
4. Read the rows for the features you will use, such as login, forms and reports, not just the summary.
5. Ask what the vendor plans to fix and when, and put it in the contract if it matters.