How to fill out a VPAT

Two decisions come first, and getting either wrong means redoing the whole document.

Decide what "the product" is. A VPAT describes one product at one version. If your buyer is purchasing the application behind the login, evaluating your marketing site answers a question nobody asked. Write down the exact scope: the application, which modules, which user roles, and whether the mobile apps are included. Reviewers do read this.

Pick the edition your buyer procures against. WCAG edition for most commercial software, 508 edition for US federal buyers, EU edition for EN 301 549, INT for all three at once. The VPAT overview covers the differences. Download the current template from ITI rather than reusing a copy someone emailed you, because the editions get revised.

The opening block asks for the product name and version, the report date, contact information, and your evaluation methods. That last field is where inexperienced reports give themselves away.

"Evaluation methods used" should describe what you actually did: which automated tool, which assistive technologies and versions, which browsers, and which pages or flows you tested. A reviewer comparing two vendors will trust the one that says "axe-core plus manual keyboard and NVDA testing across twelve representative screens" over the one that says "internal review".

If you tested a sample rather than the whole product, say so and say how the sample was chosen. A representative sample is normal practice. Implying full coverage you do not have is the thing that damages you later.

The report is a series of tables, one per standard, each row a success criterion with a conformance level and a remarks cell. Working them in this order wastes the least time:

• Mark the Not Applicable rows first. If the product has no video, the captions and audio description criteria are Not Applicable, and saying so with a one line reason clears a surprising share of the document in minutes.
• Then the machine-checkable criteria. Contrast, image alternatives, form labels, accessible names, heading structure, language of page, and ARIA validity are settled reliably by automated testing across your real templates. This is roughly a third of WCAG and the part where a tool beats a person for consistency.
• Then the manual criteria. Keyboard operability, focus order, meaningful sequence, error identification and suggestion, consistent navigation, and anything requiring a judgement about whether content makes sense. This is the larger half and it needs a human at a keyboard and a screen reader.
• Leave nothing blank. An empty cell reads as an unfinished document. If you genuinely have not evaluated something, the honest entry is a note saying so, not silence.

The conformance level is a single word. The remarks column is where the report earns or loses trust, and it is the only part some reviewers read closely.

A weak remark repeats the criterion back: "All images have appropriate alternative text." A strong one is specific about scope, defect and plan:

Partially Supports. Decorative images in the reporting module carry redundant alt text that screen readers announce twice. Content images and controls are correct. Fix scheduled for the 4.2 release, October 2026.

Three habits make remarks credible. Name where the problem is, so the reviewer knows it was found rather than guessed. Say what still works, because "Partially" without a boundary reads worse than it is. Give a date only if you intend to keep it, since a missed remediation date in a document you signed is worse than no date.

Every product has some. Third party embeds you do not control, a payment step you cannot exercise in a test account, a criterion that depends on customer configuration.

Do not mark these "Supports" on the assumption they are probably fine, and do not mark them "Does Not Support" to look conservative, because both are claims you cannot defend. State the situation in the remarks: what the component is, why it was not evaluated, and who controls it. If a third party supplies it, ask them for their own conformance report and reference it. Procurement reviewers deal with this constantly and a straight answer is unremarkable to them.

Before sending, read the finished report as somebody deciding whether to trust your company with a contract.

• Does any table say "Supports" on every row? Almost no real product is perfect, and a clean sheet invites scrutiny rather than avoiding it.
• Does the header name a version you still ship, and a date within the last year?
• Would the remarks make sense to somebody who has never seen your product?
• Does the scope statement match what the buyer is actually purchasing?
• Has anybody outside the team that wrote it read it?

Then diary a refresh. A VPAT describes a moving product, so a report written once and never revisited stops being true the moment you ship something significant.