EN 301 549: the European standard behind the accessibility rules
EN 301 549 is the harmonised European standard for ICT accessibility. What it contains beyond WCAG, why the version number matters, and how presumption of conformity works.
Web accessibilityPublished
Most people meet EN 301 549 as a line in a tender document and assume it is a European rebranding of WCAG. It is not. WCAG is one chapter of it.
The standard is titled “Accessibility requirements for ICT products and services”. It is produced jointly by the three European standardisation organisations, CEN, CENELEC and ETSI, and it covers far more than web pages: hardware, non-web documents, non-web software, support services and documentation all have their own clauses.
What is in it
The structure is worth knowing because it tells you which clauses a given procurement actually touches.
| Clause | Subject |
|---|---|
| 4 | Functional performance statements: usable without vision, without hearing, without fine motor control, and so on |
| 5 | Generic requirements that apply to all ICT: closed functionality, biometrics, preservation of accessibility information |
| 6 | ICT with two-way voice communication |
| 7 | ICT with video capabilities: captions, audio description |
| 8 | Hardware: physical controls, tactile markings, connection points |
| 9 | Web – this clause adopts the WCAG success criteria |
| 10 | Non-web documents: PDFs, Office files, e-books |
| 11 | Software, including mobile apps and platform accessibility services |
| 12 | Documentation and support services |
| 13 | Relay services, emergency access, access to captioning and audio description |
Clause 9 is the famous one, but clause 10 is where most public sector organisations actually fail. A perfectly accessible website that publishes untagged PDFs does not conform, because the PDFs are non-web documents in scope.
The version question
The version referenced in the Official Journal is what creates legal effect, and it lags behind the WCAG release cycle. The version cited in connection with the Web Accessibility Directive, V3.2.1 from March 2021, incorporates WCAG 2.1 level AA, not 2.2. Work on a newer version aligning with WCAG 2.2 has been under way.
Two practical consequences follow.
First, check which version a contract names before you promise anything, because “EN 301 549” without a version number is ambiguous and the difference is nine success criteria.
Second, building to WCAG 2.2 now is the safe direction regardless. The newer version is backwards compatible, so a 2.2-conformant site already satisfies a 2.1 reference, and it will not need reworking when the citation is updated.
Presumption of conformity
This is the mechanism that makes the standard worth following rather than arguing about.
A harmonised standard is one that the European Commission has asked the standardisation organisations to produce and whose reference has been published in the Official Journal. When you conform to it, you are presumed to conform to the corresponding legal requirements. The burden of proof moves: instead of you having to demonstrate that your interpretation of a functional requirement was reasonable, an authority has to demonstrate that conformity with the standard was not enough.
You are always free to meet the legal requirement some other way. You then carry the argument yourself. For most organisations that is a bad trade.
How it connects to the law
Two directives point at this standard from different directions.
The Web Accessibility Directive, (EU) 2016/2102, covers public sector bodies. Websites have been in scope since September 2020 and mobile applications since June 2021. It also requires each body to publish an accessibility statement with a feedback mechanism.
The European Accessibility Act, (EU) 2019/882, covers the private sector products and services on its two lists and has applied since June 2025.
Different scope, different enforcement, same technical yardstick.