How long does it take to fill out a VPAT?

For a small web product, two to five working days for one person who already knows WCAG: a day to scope and set up, two or three days of testing and evidence, half a day of writing and review. A large application with many screens, documents and roles takes weeks. Anything done in an afternoon has not been tested.

Which VPAT edition should I use?

The WCAG edition unless the buyer says otherwise. U.S. federal buyers, and the state agencies and universities that follow them, ask for the 508 edition; EU public bodies and companies within the European Accessibility Act ask for the EU edition (EN 301 549). The INT edition covers all three in one document for vendors who sell everywhere.

Can I mark a criterion Not Applicable if we did not test it?

No. Not Applicable means the criterion's subject does not exist in the product: no audio, so nothing to caption. A criterion you did not test is not Not Applicable, and the template's Not Evaluated label is permitted only for Level AAA rows. Test it or say in the evaluation-methods section that it was out of scope and why.

What should the remarks say for a Supports row?

Briefly, what was checked and how, where that helps a reviewer: "All images carry text alternatives; decorative images are marked as such; checked on the 24 pages in scope." A Supports row with an empty remarks column is accepted by most reviewers, but a short note of what was checked makes the report more credible and costs one sentence.

Do automated tools fill in the VPAT for me?

No. Automated rules find a minority of the defects that matter and cannot judge most criteria at all (whether link text makes sense, whether a page has a sensible heading structure, whether a custom control works with a screen reader). They are the right first pass; the levels and the remarks come from a person looking at the evidence.

The vendor. Even when a third party tested the product and wrote the report, the vendor adopts it and publishes it as its own declaration about its own product. The evaluation-methods section states who did the testing.

How to fill out a VPAT honestly: a working method for the WCAG edition

You have decided to produce the report yourself. Good: the template is free, the standard is public, and nobody knows your product better than you do. The risk is not that you lack the template. It is that the template makes it easy to write fifty-five rows of "Supports" without testing anything, and that a procurement reviewer can tell. This is the method we use, written for a vendor doing it in-house: scope, evidence, levels, remarks, product information, review. Follow it and the result is a report you can defend. Our explainer on what a VPAT is covers the vocabulary; this article assumes you have it.

Before you start: the edition and the standard

Download the current template from ITI (VPAT 2.5Rev, four editions). Use the WCAG edition unless the buyer named another. The WCAG edition's tables cover WCAG 2.0, 2.1 and 2.2 at Levels A, AA and AAA; most buyers want 2.2 or 2.1 at Level A and AA, which for 2.2 is 55 criteria. Decide now which version and levels you are reporting against and write it on the first page. Everything below assumes WCAG 2.2 A and AA.

Read the template's own instructions, which sit at the front of the document. They define the five conformance levels and they say, in plain words, that the remarks column is expected to explain any level other than Supports. Reviewers know those instructions. Follow them and half the usual rejections disappear.

Step 1: scope the product like a tester, not a marketer

The report is for one product at one version. Write down:

The product name and the exact version or release date you tested.
What is in scope: the web application, the marketing site, the mobile app, the PDF manual, the admin console. A report that says "Acme Platform" and tested the marketing site is a report about the wrong thing, and reviewers ask.
The pages or screens tested, by URL or by name, and why those: every template, every interactive flow, the login, the forms, the tables, the media, the documents.
The browsers, operating systems and assistive technologies used.
The date.

Keep this list; it becomes the evaluation-methods section, and it is the first thing a careful reviewer reads.

Step 2: gather evidence for every criterion

Automated rules first, because they are fast and they are consistent. Run axe-core and HTML_CodeSniffer, or a tool built on them, on every page in scope, in a real browser, at desktop and phone widths. Deque's own 2021 analysis of its data put the share of issues automated rules can find at 57 percent; our experience is in that range, and the remainder is the part that decides the report. Automated output tells you where contrast fails, where form fields lack names, where headings skip levels, where images lack alternatives, where landmarks are missing. It cannot tell you whether link text makes sense, whether a custom widget works, or whether the page is usable at 400 percent zoom.

Then the manual passes, in this order, because each one finds a different family of defects:

Keyboard only. Unplug the mouse. Tab through every page and every flow. Can you reach everything, operate everything, see where you are at all times, and get out of every component? This pass covers 2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11 and most of 4.1.2 for custom controls.
Zoom and reflow. 200 percent zoom and a 320-pixel-wide viewport (1.4.4, 1.4.10). Nothing clipped, nothing lost, no sideways scrolling except for data tables and images.
A screen reader. NVDA with Chrome or Firefox on Windows, VoiceOver on macOS and iOS. Read every page top to bottom. Listen for images announced as filenames, buttons announced as "button" with no name, tables without headers, status messages that never arrive (4.1.3), and the heading outline (1.3.1, 2.4.6).
Colour and content checks. Contrast of every text colour on every background it appears on (1.4.3, 1.4.11), information conveyed by colour alone (1.4.1), target sizes at phone width (2.5.8), and the text-spacing test (1.4.12).
Forms. Labels, instructions, error messages, autocomplete tokens, and what happens when you submit a form with every field wrong (3.3.1 to 3.3.3, 1.3.5, 3.3.7, 3.3.8).
Media and documents. Captions, transcripts, audio description (1.2.x); every linked PDF opened and checked for tags, reading order and a title.

For every defect you find, record the page, the element, the criterion and a one-line description. This evidence is what your remarks will be written from, and what you will show a buyer who asks.

Step 3: pick the conformance level by rule, not by feel

The template gives five labels. Use them by these rules and the report will be consistent, which is what reviewers test for:

Situation	Level
Every instance in scope meets the criterion, or meets it another way that is as good	Supports
Any instance in scope fails, but the product's functionality mostly meets it	Partially Supports
Most of the product's functionality fails, or the functionality cannot be used at all by the people the criterion protects	Does Not Support
The criterion's subject does not exist in the product (no audio, so nothing to caption)	Not Applicable
The criterion is Level AAA and you did not evaluate it	Not Evaluated

Three rules that follow from the table and that vendor-written reports break most often:

One failure makes it Partially Supports. Not "mostly fine, so Supports". The remarks say how big the failure is.
Not Applicable is about the product, not about your effort. If the product has video, captions are applicable, whether or not you tested them.
Not Evaluated is for Level AAA only. The template says so. A Level A or AA row marked Not Evaluated is a defect in the report, and reviewers treat it as a Does Not Support.

Common honest Not Applicable rows for a text-and-forms web product: 1.2.1 to 1.2.5 (no audio or video), 1.4.2 (no audio plays automatically), 2.2.2 (nothing moves, blinks or auto-updates), 2.5.1 (no multipoint or path gestures), 2.5.4 (no motion actuation), 2.5.7 (nothing is dragged). Say in each remark what the product does not have.

Step 4: write remarks a reviewer can check

A remark is a sentence a stranger could verify. The formula: what fails, where, how, and what it means for the user. Add a planned fix date if you have one, never a promise you do not.

Weak remark	Remark that passes
Minor contrast issues on some pages	Partially Supports. Category labels in the article lists (coral, 3.3:1 on the page background) and the footer copyright line (2.4:1) fail the 4.5:1 minimum on 16 of the 26 pages tested. Body text, headings and buttons pass.
Mostly keyboard accessible	Partially Supports. The date picker in the booking flow cannot be opened or operated by keyboard; every other control on the 24 pages tested can.
We use ARIA	Supports. Custom menus, tabs and dialogs expose name, role and state; checked with NVDA and VoiceOver on every interactive page in scope.
N/A	Not Applicable. The product contains no audio or video content.

Write a remark for every row, including Supports rows: one sentence on what was checked. It costs an hour across the whole report and it is the difference between a document that reads as tested and one that reads as filled in.

Step 5: fill in the product information

The first section of the template is where reviewers decide how much to trust the tables. Complete every field:

Name of product and version. Exactly as the buyer will see it.
Report date. The date the testing finished.
Product description. Two sentences, plain.
Contact information. A monitored address.
Notes. Scope boundaries: what was excluded and why.
Evaluation methods used. Your Step 1 list, in prose. For example: "Tested October 6 to 10, 2026 on version 4.2 against WCAG 2.2 Levels A and AA. 26 pages covering every template and flow were tested in Chrome 130 and Safari 18 at desktop and 390-pixel widths with axe-core 4.10 and HTML_CodeSniffer 2.5, then by keyboard, at 200 percent zoom, and with NVDA 2025.1 and VoiceOver. Linked PDFs were inspected for tags and reading order. Testing was done by the vendor's engineering team." If a third party did it, name them.
Applicable standards and guidelines. Tick the ones your tables report against and the level.

If manual assistive-technology testing was not done, say so here. A report that states its limits is credible; a report that implies testing it did not do is not.

Step 6: review, then sign

Have someone who did not do the testing read the report against the evidence. They are checking for three things: levels that contradict the evidence, remarks that do not match their level, and inconsistency between related criteria (a product that fails 1.4.3 on its hero image usually fails 1.4.11 on the same element; a product that fails 2.1.1 on a widget usually fails 4.1.2 on it too). Fix the report, not the finding.

Then date it, state the version, put the company's name on it, and publish it where the buyer will look: your accessibility statement page, with the date and version beside the link. Keep the evidence. Set a reminder for the next major release or twelve months, whichever is sooner, because the report is only true for the version it names.

The mistakes that get reports sent back

From the reviews we have done and the rejections we have seen, in order of frequency:

Every row Supports, remarks empty. The report is unreadable as evidence and is treated as untested.
Not Applicable used to mean "not checked". Captions on a product with video is the classic.
Not Evaluated on Level A or AA rows. Not permitted by the template.
The marketing site was tested instead of the product. The reviewer notices on the first login screen.
No version, no date, or a date older than the current release. The report describes a product the buyer cannot buy.
No evaluation-methods section. Nobody can tell how the levels were reached.
An old template. Tables from VPAT 2.3 or 2.4 lack the WCAG 2.2 criteria; the buyer's checklist has them.
Claims of certification or guarantees in the remarks. No such thing exists, and a reviewer who sees the word stops trusting the rest.

When to stop and get help

If you reach Step 2 and find that nobody on the team can run a screen reader, or the product has hundreds of screens, or the deadline is next week, the honest options are to narrow the scope and say so in the report, or to have the testing done for you. We do the second at a fixed price: every page in scope tested in a real browser, every WCAG criterion assessed with remarks from the evidence, reviewed by an accessibility analyst before release, in three business days, with the method and its limits stated on the report. Many vendors order a WCAG findings report first, fix what it finds, then order the conformance report in the VPAT 2.5 format on the fixed product. Either way, the report you publish is yours, and the method above is how to tell whether it is true.