Conformance Reports and VPATs: Reading the Document, Not the Badge

A VPAT — Voluntary Product Accessibility Template — is a template. It is a blank form with a row for each success criterion, published so that vendors describe their products in a consistent shape.

Filled in, it produces an Accessibility Conformance Report, or ACR. There are several editions of the template depending on which standards you are being measured against, typically WCAG, the US Section 508 standards, and the European EN 301 549.

Two things follow from this that most buyers do not realise.

It is usually a self-assessment. The document is filled in by the vendor, or by a firm the vendor hired. Nothing in the format requires independent testing, and nothing in it is verified by any authority. There is no body that issues VPATs, approves them or revokes them.

It is a description, not a certification. A conformance report saying a product supports a criterion is the vendor's account of their own product. It is genuinely useful — a vendor putting a claim in writing is meaningfully different from a vendor putting it on a marketing page — but it is a starting point for a conversation, not a conclusion.

Each row of an ACR names a success criterion and gives a conformance level, then a remarks column explaining it.

The conformance levels are a small controlled vocabulary:

• Supports — the product meets the criterion.
• Partially Supports — some functionality does not meet it.
• Does Not Support — the majority does not meet it.
• Not Applicable — the criterion does not apply to this product.
• Not Evaluated — nobody checked. Permitted only for Level AAA criteria.

Now the part that saves you: the remarks column is where the truth is.

"Partially Supports" is the most common entry in almost every ACR, and on its own it tells you nothing at all. Partially supports could mean one obscure admin screen has a minor focus bug. It could mean checkout is unusable with a screen reader. The difference is in the remarks, and a remarks column that says "some elements may not be fully supported" is a vendor declining to tell you which.

Read every "Partially Supports" remark. If the remarks are vague, that is your answer about the underlying testing.

Things that turn up in weak conformance reports:

"Supports with exceptions" where the exceptions are not enumerated. Which exceptions? Where?

Level A criteria marked Partially Supports. Level A is the base of the standard. Partial support at Level A on a core workflow is a serious finding, not a footnote.

No date, or an old one. A report on a product released three versions ago describes a product you cannot buy. Check the version it covers.

No statement of how it was tested. A serious report says what was used — which screen readers, which browsers, which operating systems, and whether any of it was manual. A report that does not say was probably produced by running an automated scan, and an automated scan cannot evaluate most of the criteria in the document.

Every row saying "Supports". For anything with the complexity of a website builder, a report with no partial entries anywhere is describing a testing process rather than a product.

An overlay widget named as the remediation. If a product's conformance claim rests on a third-party accessibility overlay, treat the whole document with scepticism. The record on overlays is not ambiguous, and in January 2025 the US Federal Trade Commission announced a one million dollar settlement with one such vendor over claims its product could make any website WCAG compliant.

Coverage varies enormously. Enterprise-focused platforms are more likely to maintain a current conformance report, because their buyers ask for one as a matter of routine procurement and will not proceed without it. Consumer-focused builders often have nothing, or have accessibility documentation aimed at helping you build accessible sites rather than describing their own editor's conformance.

That distinction is worth holding on to, because the two documents answer different questions:

Can I use this editor? A conformance report for the editing interface. This is the question if anyone on your team uses assistive technology, and it is asked far less often than it should be.

Can visitors use what it publishes? A conformance report for the output, or for the default themes. This is the question most buyers think they are asking.

A vendor may have one, both or neither, and a document covering the published output tells you nothing about whether your colleague can operate the editor. Ask which one you have been sent.

If you are buying on behalf of an organisation with a real obligation, a conformance report is one input among several. Four things are worth more.

Ask when it was last updated and against which product version. The answer to this one question sorts serious documents from decorative ones faster than reading the whole thing.

Ask how it was tested. Which assistive technologies, which browsers, how much of it manual, and whether disabled testers were involved.

Ask for the known issues list, not the report. Vendors who do this seriously maintain one. Asking for it is a reasonable request and the reaction to it is informative on its own.

Then test the thing yourself, on your actual workflow. A trial account and an afternoon with a keyboard will tell you more about whether your team can use a product than forty pages will. The keyboard test works on an editor exactly as it works on a website.

A conformance report is not a legal document, it is not a defence, and possessing one settles nothing. It is a vendor's written description of their product's accessibility, which is worth having and is not the same as the product being accessible.

Nothing on this site is legal advice. If your organisation has an obligation that turns on what you procured and what you knew, that is a question for a lawyer — and the assessment of ADA-compliant website builders makes the same point in more detail about the platforms themselves.