WCAG & Accessibility·4 min read

How to Fill In a VPAT: A Plain Guide to the ACR

A buyer's procurement form asks for your VPAT, and nobody on the team has written one. The request is ordinary: public agencies, universities and large companies use these reports to compare how accessible competing products are before they sign. The format is fixed, the vocabulary is small, and the hard part is honesty rather than paperwork. This guide explains what goes in each part of the report, how to choose a conformance level for every WCAG criterion, and how the free VPAT Generator turns your findings into a Word file the buyer can read.

Open the free VPAT Generator All insights

VPAT and ACR: two names for one job

Template versus finished report.

The Voluntary Product Accessibility Template, or VPAT, is a blank form published by the Information Technology Industry Council (ITI). It lists accessibility standards as tables and leaves space for you to say how your product measures up. Once you fill it in for a specific product and version, the document is properly called an Accessibility Conformance Report, or ACR. Buyers use the two terms interchangeably, so when a form asks for a VPAT, it wants the completed report.

ITI publishes several editions. The WCAG edition covers web content only. The Section 508 edition adds US federal requirements for hardware, software and support documentation. The EU edition maps to EN 301 549, and the international edition combines all three. Most web products start with the WCAG edition, which is the layout the generator follows, with an optional table for the Section 508 functional performance criteria.

The parts of an Accessibility Conformance Report

Same order every time.

Buyers often read several reports side by side, so the order matters. The report opens with product information: the name and version, the report date, a short description and a contact for accessibility questions. Next comes the evaluation methods section, where you say how you tested. Name the tools, the manual checks, and the screen reader and browser pairs, for example NVDA with Firefox and VoiceOver with Safari.

Then come the applicable standards, stating which WCAG version and levels the report covers, and a short terms section that defines the conformance labels. The body is a set of tables, one per WCAG level, with a row for every success criterion. Each row holds the criterion, a conformance level and your remarks. A legal disclaimer closes the report. In the generator you fill in the product fields once, choose WCAG 2.0, 2.1 or 2.2, tick Level AA or AAA, and the tables are built for you.

Choosing a conformance level for each criterion

Five labels, one rule: be accurate.

Supports means the product meets the criterion without known defects, or meets it through an equivalent alternative. Partially Supports means some functionality does not meet it. Does Not Support means most functionality fails it. Not Applicable means the criterion has nothing to act on, such as audio description in a product with no video. Not Evaluated is only allowed for Level AAA criteria.

Take 1.4.3 Contrast (Minimum). If your main screens pass 4.5:1 but the disabled buttons and placeholder text do not, that is Partially Supports, not Supports. If the product has no color contrast testing at all, you cannot claim anything yet; leave the row unassessed and test it. The generator marks unrated Level A and AA rows as not yet assessed in the export, so a half-finished report never looks complete by accident.

One row gets special handling. For WCAG 2.0 and 2.1, the W3C errata published in 2023 state that 4.1.1 Parsing is always satisfied for HTML and XML content, so the generator fills that row with Supports and an explanation. WCAG 2.2 removed the criterion, so it does not appear in a 2.2 report.

Writing remarks buyers trust

Specific beats reassuring.

Procurement reviewers skim the labels and read the remarks. A useful remark names the feature, describes the barrier and mentions any workaround or plan. Compare two versions for 2.1.1 Keyboard. The weak one says the product is mostly keyboard accessible. The strong one says the date picker in the booking form cannot be opened with the keyboard, users can type the date into the text field instead, and a fix is planned for version 5.2.

Remarks for Supports rows can be short, but a line on how you verified it helps, such as tested with keyboard only on all main screens. For Not Applicable, say why. Avoid promising dates you cannot keep, because the report may end up attached to a contract.

Using automated results without overclaiming

A head start, not a verdict.

Automated testing is a sensible first step. Run a page through the WCAG Accessibility Checker, download the JSON result, and use Import checker result in the generator. Criteria with failed automated checks become Partially Supports, and the failures are listed in the remarks with how many times each was found.

The import never marks a row as Supports, and that is deliberate. A clean automated result shows that certain machine-detectable problems are absent. It cannot show that alt text is accurate, that focus order makes sense or that captions match the audio. Rate those rows only after manual testing, and change imported rows to Does Not Support when the failure affects most of the product.

Exporting and keeping the report current

Every release, not every few years.

When the tables are done, download a Word file with landscape pages and real tables, an HTML page, a CSV for your own tracking, or Markdown for a repository. Add your logo and formatting in Word if the buyer expects a branded document. Everything is built in your browser and nothing is stored on a server, so click Save draft to keep a JSON file of your answers.

Update the report for each major release, after each audit, and whenever a fix changes a conformance level. Many buyers expect a date within the last year. Load the saved draft, change the version number and report date, adjust the rows that changed, and export again. Pair the report with a public accessibility statement from the Accessibility Statement Generator so customers and buyers read the same story.