VPAT example: what a completed ACR row looks like

What does a completed VPAT look like?

A table, and a long one. The WCAG edition runs to roughly fifty rows at Level A and AA, each with three columns: the success criterion, the conformance level, and the remarks and explanations.

Everything else in the document is scaffolding. There is a cover page with the product name, the version, the date and the evaluation methods used, and there are short sections describing the standards being reported against. Then the table starts, and the table is the report.

Two rows are enough to show what good and bad look like, because the difference is never in the rating. It is in whether the remark tells a reviewer something they could verify.

What goes in a single criterion row?

Criterion, rating, and the sentence that justifies the rating. Here is one for contrast, which is the most commonly failed criterion on the web and one an automated scan can genuinely evidence.

Criterion	Conformance level	Remarks and explanations
1.4.3 Contrast (Minimum) (Level AA)	Partially Supports	Body text and primary controls meet 4.5:1. Helper text in the account settings and billing forms is set in a grey that measures 3.1:1 against white, affecting 6 of the 24 pages tested. Fix is a single design token change, scheduled for the October release.

Read what that remark does. It states what passes, not just what fails. It names the specific component and the actual measured ratio rather than saying “some contrast issues”. It quantifies the scope as pages affected out of pages tested, so the reviewer knows whether this is systemic or a corner. And it commits to a timeframe.

Now the same criterion written the way most reports write it:

Criterion	Conformance level	Remarks and explanations
1.4.3 Contrast (Minimum) (Level AA)	Supports	The product meets this criterion.

That row is not necessarily false. It is unverifiable, which for a procurement reviewer is nearly the same thing. There is no scope, no method and nothing to check.

What does each conformance level mean?

Four values, and the boundary that causes the most argument is between the middle two.

• Supports. The product meets the criterion across the scope you tested.
• Partially Supports. Some functionality meets it and some does not.
• Does Not Support. The majority of relevant functionality fails.
• Not Applicable. The criterion cannot apply, for example a video captions criterion on a product with no audio or video.

Partially Supports is not a soft failure and it is not an admission of weakness. It is the honest answer for most criteria on most real products, and a report where nearly everything is Partially Supports with specific remarks is more credible than one where everything Supports.

The one to be careful with is Not Applicable. It is the only rating that removes a criterion from consideration entirely, so reviewers look at it harder than the others. Use it when the functionality genuinely does not exist, and say why in the remark.

How do you rate a criterion automation cannot judge?

Carefully, and never by letting a clean scan speak for a criterion it never really tested. This is where most reports quietly break.

Here is the second row, for a criterion no scanner can decide:

Criterion	Conformance level	Remarks and explanations
2.4.3 Focus Order (Level A)	Partially Supports	Manual keyboard review of the six primary flows, 4 August 2026. Focus order follows the visual sequence throughout except in the checkout dialog, where focus moves to the page behind the modal after the payment step. Automated testing does not evaluate this criterion; the rating is based on the manual review described in the evaluation methods.

The last sentence is doing the important work. It tells the reviewer which evidence produced the rating, and it does not let a reader assume a tool determined something a tool cannot determine.

Building the export made this concrete. Of RedFlag’s 122 documented rules, 96 run automatically and 26 are manual checks or guidance, because the criteria behind them need a person operating the interface. A scanner can list the DOM order of your focusable elements. It cannot tell you whether that order makes sense for the task the user is trying to complete. So the rule for the report is simple: if the evidence is a manual check, say so in the remark, and if there is no evidence at all, do not rate the criterion as passing.

That last point is a decision worth stating plainly, because the tempting default is the opposite. A criterion with no findings against it is not a criterion that passed. It is a criterion nobody looked at, and reports that conflate the two are the reason procurement teams have learned to distrust the format.

What do buyers actually check first?

Not the ratings. Three other things, in roughly this order.

1. The date and the version. An ACR describes one build at one moment. Anything much past twelve months gets treated as stale, and a report that does not name the product version it covers is hard to take seriously at all.
2. The evaluation methods section. This is where you state what was tested, on how many pages, with what tools and what manual review. A reviewer reading a Supports rating wants to know what backs it.
3. The distribution of ratings. Not the individual values, the shape. All Supports gets read as untested. A realistic mix with specific remarks gets read as a vendor who has actually looked.

Only then do they read individual rows, and usually only the ones relevant to how their own users work.

How do you fill one out without guessing?

Test first, rate second, and let the order stop you writing anything you cannot support.

1. Scan the product and collect the findings. This clears the mechanical criteria: contrast, alt text, form labels, accessible names, document language, heading order. These are also the highest-frequency failures, so automation carries most of the volume even though it reaches under half the criteria.
2. Do a keyboard and screen reader pass on your primary flows and record what you find. This is what produces defensible ratings for focus order, meaningful alt text and the rest of the judgement criteria.
3. Rate each criterion from the evidence you now have, and mark anything untested as unevaluated rather than passing.
4. Write the remark before you finalise the rating. If you cannot write a specific sentence, you do not yet know enough to rate it.
5. Date it, version it and plan to regenerate it. The report ages the moment the product changes.

RedFlag generates the report from your scan data, which removes step one as a manual exercise and keeps the ratings traceable to findings on your real pages. It does not remove steps two and four, and it is not a certification. The rules library shows which criterion each rule maps to, which is the same mapping the report uses.

For the wider context on who asks for these documents and why, what is a VPAT and who needs one covers the editions, the buyers and the difference between the template and the completed report.

Frequently asked questions

Where can I find a real VPAT example to copy?

Most large vendors publish their own ACRs, and searching a product name alongside "accessibility conformance report" usually finds one. Read two or three before writing yours. The blank template comes from the Information Technology Industry Council, but a blank template does not show you what a credible remark reads like, which is the part people get wrong.

How long should a VPAT remark be?

One or two sentences per criterion, naming the component, the failure and where it stands. Reviewers are reading dozens of rows, so a paragraph of hedging is worse than a short specific sentence. The exception is Does Not Support on a significant criterion, where a sentence on what is planned is worth adding.

What if I have not tested a criterion at all?

Say so. An untested criterion is not a passing criterion, and marking it Supports because nothing turned up is the single most damaging thing you can do to a report's credibility. Leaving it clearly unevaluated is honest and costs you far less than being caught.

Can I write Supports for a criterion an automated scan passed?

It depends entirely on the criterion. For something mechanical like document language, a clean automated result is reasonable evidence. For focus order or meaningful alt text, a scan passing means only that nothing detectable was found, which is not the same as the criterion being met. Rate those from a manual check or leave them unevaluated.