Skip to content
wcagc
←Back to blog
EN 301 549conformance reportVPAT

How to write an EN 301 549 conformance report

An EN 301 549 conformance report records how your product meets each clause. What it contains, how to test, and how honest to keep it.

P

Pavel Charkasau

An EN 301 549 conformance report is a document that states, clause by clause, how well your product meets the European accessibility standard. To write one you do four things: pick a template, set the scope, test each applicable requirement, and record an honest result for every clause. Most teams use the VPAT, the Voluntary Product Accessibility Template that the Information Technology Industry Council publishes, in its EU edition, which is built around EN 301 549 (ITI). A filled-in VPAT is called an Accessibility Conformance Report, or ACR. The standard itself does not ship a single official report form. What it gives you is Annex C, a normative annex that tells you, for each requirement, the pre-conditions and the pass/fail test you apply to decide whether you meet it (ETSI EN 301 549 v3.2.1). So the report is the VPAT structure on the outside and Annex C tests on the inside. The one rule that matters more than format: every line has to be true. Overstating conformance is exactly what earned an overlay vendor a $1 million order from the US Federal Trade Commission (FTC). Here is how to build the report without landing there.

What is an EN 301 549 conformance report?

It is a written record of how a specific product measures against EN 301 549, the standard that defines accessibility requirements for ICT in Europe. Procurement teams ask for it, buyers read it during vendor evaluation, and it becomes the evidence behind an accessibility statement later.

The report and the standard are two different things. EN 301 549 is the requirement set: functional performance statements in Clause 4, then technical chapters for web (9), non-web documents (10), software (11), documentation and support (12), and hardware (8), among others. The conformance report is your product's answer to that set, one row per clause, with a result and a note.

People conflate the report with the VPAT. The VPAT is the empty form; the completed version is the ACR (ITI). I will use "conformance report" and "ACR" for the finished document.

Which template should you use?

Use the VPAT 2.5Rev EU edition. ITI publishes four editions of the same template: a 508 edition for the US federal standard, a WCAG edition for the W3C guidelines, an INT edition that folds in all three, and the EU edition that maps to EN 301 549 (ITI). The current release is VPAT 2.5Rev, dated April 2025.

Pick the edition by market. If you sell only into the EU or into an EU public-sector tender, the EU edition is the right one because its tables follow EN 301 549's chapter numbering. If you sell into the EU and the US, the INT edition covers Section 508, WCAG, and EN 301 549 in one file, which saves you maintaining three near-identical reports. The Section 508 and EN 301 549 requirements overlap heavily since both build on WCAG, so the INT edition is less duplication than it looks.

There is no requirement to use ITI's template at all. A plain table with clause, result, and notes columns is a valid report. The reason almost everyone uses the VPAT is that procurement officers already know how to read it, and a familiar format gets fewer follow-up questions.

What goes in the report?

A complete ACR has a header block and then the conformance tables.

The header carries the product name and version, the report date, your contact details, the evaluation methods you used, and the standards the report covers. "Evaluation methods" is not a formality. Write down what you actually did: which pages or screens you tested, which assistive technology and browser pairings, and how much was automated versus checked by a person. A reviewer weighs the whole report by how the testing was done.

Then come the tables, one per part of the standard that applies to your product:

  • Functional performance (Clause 4), the outcome-level statements such as usage without vision or without hearing.
  • Chapter 9 for web content, which is WCAG 2.1 Level AA renumbered with a "9." prefix.
  • Chapter 11 for software, which covers native apps and desktop software.
  • Chapter 12 for documentation and support services.
  • Chapters 5 to 8 for generic, voice, video, and hardware requirements, where they apply.

You only fill the tables for the ICT types you ship. A pure web app does not complete the hardware chapter; you mark that part not applicable and say why. Each row inside a table holds the clause, a conformance level, and a remarks column where the real information lives.

Our WCAG checklist tracks the Chapter 9 side of this, the WCAG 2.1 AA criteria, which is the largest table for any website.

How do you decide "Supports" or "Partially Supports"?

The VPAT gives you four conformance levels: Supports, Partially Supports, Does Not Support, and Not Applicable (ITI). Supports means the product meets the clause across the tested scope. Partially Supports means some of it does and some does not. Does Not Support means most of it fails. Not Applicable means the clause does not apply to what you built.

Those labels are the report's vocabulary, but the standard is what decides which one is true. That is Annex C. Annex C is normative, and it works requirement by requirement: for each clause it states the pre-conditions that make the test apply and the pass or fail outcome (ETSI EN 301 549 v3.2.1). One nuance worth knowing before you lean on it: Annex C tells you how to judge a single requirement, but it is not a testing methodology. It does not tell you which pages to sample or how to walk a whole site. You bring that method yourself, and you describe it in the evaluation-methods block.

So the honest workflow is: run the Annex C test for a clause, get a pass or fail, then translate that into the VPAT label. If contrast passes everywhere you looked, that clause Supports. If most controls have a visible focus indicator but your custom date picker does not, that is Partially Supports, and the remarks column names the date picker. The remark is the part a serious buyer reads.

How is a conformance report different from an accessibility statement?

They serve different readers. A conformance report is a technical, clause-level document aimed at procurement and engineering. An accessibility statement is a public page written for the people using your site, and for public-sector bodies it is a legal duty under Article 7 of the Web Accessibility Directive (Directive (EU) 2016/2102).

The report feeds the statement. You test to EN 301 549, write the ACR, and then summarise its findings in plain language on your public accessibility statement: what conforms, what does not yet, and how someone can report a barrier or ask for an alternative. Under the EAA, private-sector services carry their own information duties too. A statement without a report behind it is a claim with nothing under it, and that is the gap an auditor probes first.

How honest should the report be?

Completely. A conformance report is a public-facing claim about your product, and the accessiBe case is the reason to treat it that way: the FTC's $1 million order was for representing that a product made websites WCAG compliant when it did not (FTC). A conformance report that overstates is the same kind of claim on paper.

There is also a limit built into how you test. Automated tools catch only part of what the standard requires. Deque's review of more than 2,000 audits found automation identified about 57% of issues by volume, and estimates based on how many success criteria a tool can even evaluate put the figure closer to 30% (Deque). A scanner cannot judge whether alt text is meaningful, whether focus order makes sense, or whether an error message actually helps. Those clauses need a person with a keyboard and a screen reader, which is why a report built from a scan alone is not a real conformance report. Say in your evaluation-methods block where a human reviewed and where a tool did; a reviewer trusts that more than a wall of green.

I would rather publish a report with three honest "Partially Supports" rows than a page of "Supports" an auditor can disprove in an afternoon. The honest report survives scrutiny. The other kind creates the exact liability the document was supposed to reduce.

Frequently asked questions

Is there an official EN 301 549 conformance report template?

No single official form ships with the standard. EN 301 549 gives you Annex C, which defines the pass/fail test for each requirement, but not a report layout. In practice the VPAT EU edition from ITI is the de-facto template, and a completed one is called an Accessibility Conformance Report.

What is the difference between a VPAT and an ACR?

The VPAT is the blank template; the ACR is the completed report. You download the VPAT, fill in your product's results clause by clause, and the finished document is the Accessibility Conformance Report that buyers and procurement teams read.

Which VPAT edition covers EN 301 549?

The VPAT 2.5Rev EU edition. ITI also publishes 508, WCAG, and INT editions; the INT edition covers Section 508, WCAG, and EN 301 549 together, which is useful if you sell into both the EU and the US.

Can I generate a conformance report from an automated scan?

Not a complete one. Automated tools identify roughly 30 to 57% of issues, so a scan can fill part of the report but cannot judge clauses like meaningful alt text or logical focus order. Those need manual testing before you can honestly mark a conformance level.

Do I need a conformance report and an accessibility statement?

They are different documents. The conformance report is a technical, clause-level record for procurement; the accessibility statement is a public page for users, and a legal duty for public-sector bodies under the Web Accessibility Directive. The report is the evidence behind the statement.

Start with the web clauses you can measure

The largest table in any website's report is Chapter 9, which is WCAG 2.1 AA. That is the practical place to begin. Run a free scan to clear the machine-detectable criteria on your key pages, then work through the manual clauses a scanner cannot judge and record each result against Annex C. You will end up with real, clause-level findings to drop into the report, instead of a guess dressed up as conformance.

Pavel Charkasau, founder, wcagc.com. Last updated 7 August 2026.

Sources