Skip to content
wcagc
←Back to blog
EN 301 549procurementVPATEAA

What EN 301 549 means for accessibility procurement

EN 301 549 was written for ICT procurement. What to name in a tender, and how to read the conformance report a supplier sends back.

P

Pavel Charkasau

EN 301 549 is the standard European buyers name when they buy software, websites, or hardware, and buying is the job it was built for. The European Commission asked CEN, CENELEC and ETSI to write it under Mandate M/376 so that public bodies across the EU would share one definition of "accessible" they could paste into a tender (European Commission, Rolling Plan for ICT Standardisation). Two pieces of law give that definition teeth. Article 42(1) of the public procurement directive says technical specifications for anything intended for use by people shall, "except in duly justified cases, be drawn up so as to take into account accessibility criteria for persons with disabilities or design for all users" (Directive 2014/24/EU). The European Accessibility Act then makes its own Annex I requirements mandatory accessibility requirements within the meaning of that same article (Directive (EU) 2019/882). A tender that works does four things: it names the standard and the version, names the clauses that apply, asks for conformance determined the way the standard says to determine it, and keeps the right to check. Here is each one, and how to read what comes back.

Why was EN 301 549 written for procurement?

Mandate M/376 went out in 2005 and asked the three European standards bodies for accessibility requirements suitable for the public procurement of ICT. The first published version carried that in its title. The current text of EN 301 549, V3.2.1, is titled "Accessibility requirements for ICT products and services" and has grown well past its procurement origin, but the structure still shows where it came from.

That structure matters more than the history. The standard is written as testable requirements attached to pre-conditions, not as advice. Nearly every clause opens with "Where ICT" followed by the condition that makes it apply, so a supplier can only claim a clause once you both agree the pre-condition is true of the thing being sold. A ticket machine has no web pages; a browser-based dashboard has no physical keys. Clause 14 of the standard covers conformance, and Annex C is normative, meaning it gives each requirement a pass or fail test rather than a discussion. For a buyer, that is the useful part. You can ask a question with a defined answer.

What does EU law require a public buyer to do?

Three obligations stack, and they cover different things.

Article 42(1) of Directive 2014/24/EU is the general one. If what you are buying will be used by natural persons, whether the public or your own staff, accessibility has to be taken into account in the technical specifications. The directive does not name a standard. Article 42(3) lets you write the specification either as performance requirements or by reference to standards, and that is where EN 301 549 gets named in practice.

Directive (EU) 2016/2102, the Web Accessibility Directive, is the specific one for public sector websites and mobile apps. Its Article 6 grants a presumption of conformity to content that meets the relevant harmonised standard, and Commission Implementing Decision (EU) 2021/1339 is what put EN 301 549 V3.2.1 into the Official Journal for that purpose. So for a public body buying a website, the standard is not just a good reference. It is the route to the legal presumption.

The European Accessibility Act adds the third. Article 24 makes the accessibility requirements in its Annex I mandatory accessibility requirements within the meaning of Article 42(1) of the procurement directive and Article 60(1) of the utilities directive (Directive (EU) 2019/882). For products and services in EAA scope, "take into account" hardens into a requirement you cannot negotiate away in evaluation.

What should the tender document actually say?

Start with the standard and the version, because "accessible" on its own is unenforceable and "EN 301 549 V3.2.1" is a document both sides can open. See the version question further down before you hard-code a number.

Then name the clauses. Buying a public sector website means Table A.1 of Annex A is your list, which is mostly Chapter 9, WCAG 2.1 AA renumbered with a 9. prefix. A mobile app pulls in Table A.2 and Chapter 11 instead. A payment terminal pulls in Chapters 5 and 8, which have nothing to do with WCAG at all. Listing the chapters stops a supplier from answering a hardware question with a web answer.

The line most tenders skip is the one asking for conformance determined per Annex C. That is what turns a marketing claim into a checkable statement, because Annex C is the normative test procedure and citing it gives the supplier's yes a defined meaning.

Last, reserve an acceptance test on the delivered system and say what happens if a clause fails. An accessibility requirement with no consequence attached is a paragraph, not a requirement.

If I could change one line in most public tenders, it would be the scoring. A yes/no box for "WCAG compliant" rewards the supplier who reads the question least carefully. Scoring the quality of the evidence rewards the one who actually tested.

What should a supplier send back?

The usual artifact is an Accessibility Conformance Report, produced by filling in the ITI VPAT template. VPAT 2.5 comes in four editions and the EU edition reports against EN 301 549 (ITI). A completed VPAT with real testing results in it is what the industry calls an ACR.

A report you can use has a few things a report you cannot use is missing:

  • A scope. Which product, which version or build, which screens or URLs. "Our platform" is not a scope.
  • A date and a method. When it was tested, with what, and which assistive technology and browser pairs. A report with no method is an opinion in a table.
  • Clause-level results. The VPAT conformance levels are Supports, Partially Supports, Does Not Support and Not Applicable, one per requirement, each with a remark.
  • Honest partials. A 200-row report where every row says Supports is the least believable document in the pile. Real software has partials.

Read the remarks column before the verdict column. That is where a supplier tells you that support for a clause holds "on the primary navigation" and quietly says nothing about the checkout.

How do you check a supplier's claim without an audit team?

Sample it. You do not need to re-test 200 clauses to find out whether a report is honest.

Run an automated scan over the pages or screens the report claims to cover. Automation catches roughly 30% to 57% of accessibility issues depending on how you count, on Deque's analysis of over 2,000 audits (Deque), so a clean scan proves less than it looks like. A dirty one, on a page whose row says Supports, tells you plenty in about ninety seconds.

Then do one thing by hand. Pick the task the contract exists for, a booking or a form submission, and complete it with the keyboard only. Focus order and error messages that name the failing field are where real systems come apart, and no scanner settles either one for you. Ours does not. It gives you the machine-detectable violations with the CSS selector that caused each one, and then a person has to drive the flow.

Ask for the raw test log too, not only the summary. Suppliers who tested will have one.

Which version of EN 301 549 should the contract name?

Today, V3.2.1. That is the version cited in the Official Journal for the Web Accessibility Directive, via Commission Implementing Decision (EU) 2021/1339. Under the EAA, no harmonised standard has been cited in the Official Journal yet, so meeting EN 301 549 there is strong technical evidence rather than an automatic legal presumption (Rolling Plan for ICT Standardisation).

A newer version is close. ETSI issued a final draft, V4.1.0, in June 2026, moving the web baseline to WCAG 2.2 AA. On a multi-year contract, naming a fixed version leaves you asking for an outdated standard by year three, and naming "the latest version" lets the requirement move under a supplier who already priced the work. The usual compromise is to name V3.2.1 as the baseline, then add that where a newer version is cited in the Official Journal during the contract, the parties will agree a plan and a date to move to it. Our EN 301 549 checklist tracks the current clause set if you want the baseline in front of you while you draft.

Does any of this apply to private-sector buying?

The procurement directives bind public contracting authorities, not private companies. But a private buyer inherits the problem anyway, because your own obligations flow through what you buy. If your checkout runs on a third-party payment widget and that widget traps keyboard focus, the barrier is on your service. That is why B2B suppliers now get asked for an ACR by customers who have no procurement law obliging them to ask. Same questions, no directive behind them, and the answers are easier to get than most people expect.

Frequently asked questions

Is EN 301 549 mandatory in EU public procurement?

The standard itself is voluntary; naming it is how buyers meet a duty that is not. Article 42(1) of Directive 2014/24/EU requires technical specifications to take accessibility into account for anything used by people, and Article 42(3) permits specifying that by reference to a standard. For public sector websites and apps, meeting EN 301 549 also carries the presumption of conformity with the Web Accessibility Directive.

What is the difference between a VPAT and an ACR?

The VPAT is the blank template published by ITI; the ACR is the completed report with your testing results in it. The EU edition of VPAT 2.5 reports against EN 301 549, so that is the edition to request in a European tender.

Which EN 301 549 clauses apply to a website purchase?

Table A.1 of Annex A is the list, and it is mostly Chapter 9, which is WCAG 2.1 Level AA renumbered. Supporting clauses from Chapters 5, 6, 7 and 12 also appear. Mobile apps use Table A.2 and lean on the Chapter 11 software requirements instead.

Can a supplier prove conformance with an automated scan?

No. Automated testing identifies somewhere between about 30% and 57% of issues by Deque's measurement, and the remainder needs a person testing with a keyboard and a screen reader. A scan report is useful evidence for the machine-detectable clauses and is not a conformance determination on its own.

Should the contract name EN 301 549 V3.2.1 or V4.1.0?

V3.2.1 is the version cited in the Official Journal today, so it is the safe baseline. ETSI published a final draft of V4.1.0 in June 2026. On a long contract, name V3.2.1 and add a clause committing both sides to agree a migration plan when a newer version is cited.

Check the evidence before you sign

If you are evaluating a supplier's accessibility claim right now, the fastest useful move is to test the claim rather than the document. Run a free scan on the pages or screens their report says it covers, compare the violations against the rows marked Supports, then walk the main task with the keyboard. Twenty minutes of that tells you more about a vendor than twenty pages of their ACR, and it gives you specific clauses to raise in clarification questions instead of a general worry.

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

Sources