How to fill out a VPAT that a government reviewer trusts

Filling out a VPAT is not difficult in the mechanical sense. The template is a document with a header and some tables. What is difficult is filling it out so that a government reviewer, reading it against a solicitation, believes it. This guide covers how to fill out a VPAT 2.5 with that reader in mind.

A reviewer is not checking whether your product is perfect. They are checking whether your report is evidence. The difference shows up in a handful of decisions you make before and while writing it.

Start with the right edition

ITI publishes VPAT 2.5 (current revision 2.5Rev) in four editions:

Edition	Covers
WCAG	WCAG 2.0, 2.1 and 2.2
Revised 508	The US Revised Section 508 Standards, which incorporate WCAG 2.0
EU	EN 301 549
INT	All of the above in one report

The template's own instruction is to decide which standards the report will cover and use the matching file. For US public-sector buyers, that choice is usually driven by the solicitation:

• A federal agency buying under Section 508 will expect the Revised 508 edition or INT.
• A state or local government preparing for the ADA Title II web rule will generally be asking about WCAG 2.1 Level AA. A Revised 508 edition does not answer that, because its tables cover WCAG 2.0 criteria only.
• If you sell to both, the INT edition, or a WCAG edition reporting 2.1 or 2.2 alongside a 508 report, avoids being asked for a second document later.

Our note on which edition buyers require goes into the mismatches that cause the most rework.

Scope the product and the version precisely

The template requires the "Name of Product/Version", including the version identifier if one exists. Be precise. A reviewer comparing your report to the version in your proposal will notice a mismatch.

If the product has several parts, say which ones the report covers. A citizen-facing portal, an administrator console and a native mobile app are three different user interfaces. ITI's best practices allow multiple reports for complex products, as long as each report's Notes section explains the split and where to find the others.

For SaaS without numbered versions, name the release or the date of the build you evaluated. Use the Notes section to say what the report does not cover: third-party components, legacy modules, generated documents.

Date it, and keep it current

The report date is required, at minimum the month and year. ITI recommends that when you revise a report you change the date and explain the revision in Notes, or issue a new report that says which earlier one it supersedes.

A reviewer will compare the date to your release history. A report from three years ago on a product that ships monthly reads as stale, regardless of what it says.

Describe the evaluation methods properly

"Evaluation Methods Used" is a required section, and it is the one most often left vague. ITI's best practices suggest it describe some combination of:

• whether testers knew how to use the product's common workflows,
• testing with assistive technologies (naming them is optional, and helpful),
• manual and automated testing tools,
• any published test method followed, by name and publisher.

A paragraph like the following is what a reviewer is hoping to see:

Evaluated in June 2026 against WCAG 2.1 Level A and AA. Manual testing of all primary workflows (account creation, application submission, payment, status lookup) using keyboard only, NVDA with Chrome and Firefox on Windows 11, and VoiceOver with Safari on macOS. Automated checks using axe-core. Color contrast measured with a contrast analyzer. Testing performed by staff trained in the product and in WCAG evaluation.

That tells the reader who looked, with what, and at which parts of the product. "Tested with industry-standard tools" tells them nothing.

Answer every criterion at the level you report

ITI's instructions are clear: when reporting on a level, all criteria for that level must be answered for the WCAG version the report covers. You may remove the 2.2-only rows from a 2.1 report, or the AAA table if you are not reporting AAA. You may not remove individual criteria you would rather not discuss.

Use only the permitted terms, defined in the report:

• Supports — the functionality has at least one method that meets the criterion without known defects, or meets it with equivalent facilitation.
• 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 is not relevant to the product.
• Not Evaluated — permitted only for WCAG Level AAA criteria.

Write remarks that explain how you know

The template asks for detailed remarks to justify each conformance level. For Partially Supports or Does Not Support, the remarks should identify which functions or features have issues and how they fall short. For Not Applicable, explain why. If an accessible alternative exists, describe it.

Two practical rules help:

1. Name the feature. "Date picker on the scheduling screen" is useful. "Some components" is not.
2. Say what fails, not just that something does. "Focus indicator is not visible on the custom dropdown in the report builder" lets a reviewer judge the impact.

Our list of VPAT red flags shows the same issues from the reviewer's side.

Use Partially Supports honestly

Vendors are sometimes reluctant to mark anything less than Supports. In our experience reviewing reports, the opposite instinct serves you better.

A report in which every criterion is Supports, with blank remarks, invites the most scrutiny, because a reviewer cannot distinguish thorough testing from no testing. A report with a few well-explained Partially Supports rows, each naming the affected feature and a target release for the fix, reads as a vendor that tested carefully and knows its product.

Reviewers do weigh severity. A Partially Supports on 1.4.3 Contrast (Minimum) limited to placeholder text in one form is a different finding from a Partially Supports on 2.1.1 Keyboard affecting the checkout flow. Say which one it is. Our note on Supports vs Partially Supports explains how reviewers read that value.

Finish the document properly

Before publishing, ITI's checklist requires: the title "[Company Name] Accessibility Conformance Report", the template version, product and version, date, description, contact information, notes, evaluation methods, applicable standards, terms, and the tables. Each criterion needs both a conformance level and remarks. Remove the template's instruction pages. Make sure the final document is itself accessible. A tagged PDF or an HTML page is fine. A scanned image is not.

Also note what the VPAT is not. It is your own disclosure about your product. It is not a certificate, and no body certifies WCAG or Section 508 conformance. Avoid language that implies otherwise.

---

Sources: ITI VPAT 2.5Rev template, Essential Requirements and Best Practices for Authors (WCAG and Revised 508 editions); W3C WCAG 2.1; 28 CFR part 35, subpart H (the DOJ's Title II web rule).

GOVvpat does not write VPATs, but vendors can have their own report reviewed the way a government buyer will read it before submitting it. See how it works for vendors.