EN 301 549: The ICT Accessibility Standard You Actually Test Against
Most teams working on EAA compliance know they need to meet WCAG 2.1 AA. Fewer understand that WCAG is only one part of the standard they are actually being measured against. That standard is EN 301 549 - and if you are auditing, writing conformance reports, or scoping remediation work for the EU market, it is the document that matters.
This post explains what EN 301 549 is, how it relates to the EAA, what it covers beyond WCAG, and what the expected 2026 revision means for your planning. It assumes you already know the EAA basics - if you need a primer, start with our EAA overview.
The EAA sets the law. EN 301 549 operationalises it.
The European Accessibility Act - Directive (EU) 2019/882 - sets legal obligations for accessible products and services. It has applied to the market since 28 June 2025. But the directive itself does not specify pixel dimensions, contrast ratios, or RTT latency thresholds. It sets functional requirements in Annex I and then points to harmonised technical standards to fill in the detail.
That is where EN 301 549 comes in. EN 301 549 is a European standard that specifies accessibility requirements for information and communications technology (ICT) products and services. It was produced by CEN, CENELEC and ETSI to set requirements for products and services in the European Union.
The legal mechanism is called presumption of conformity. The EAA presumes that if a product or service conforms to harmonised standards published in the Official Journal of the European Union, it conforms to the EAA. In practice: following EN 301 549 creates a "presumption of conformity" with the EAA - meaning regulators will presume your products meet legal requirements if you comply with the standard.
This is not a technicality. It shifts the burden of proof. Without it, you would need to demonstrate compliance against the directive's functional requirements directly, clause by clause. With it, conformance to the standard is sufficient evidence.
Presumption of conformity requires OJEU citation. A standard only carries this legal weight once it is cited in the Official Journal of the European Union (OJEU). Publishing a new version of EN 301 549 is not enough on its own — it must go through the harmonisation process and receive an OJEU reference. Until that happens, the new version is a technical document, not a legally harmonised standard.
The current version: EN 301 549 v3.2.1
EN 301 549 v3.2.1 was published in March 2021. It was cited in the Official Journal of the EU via Implementing Decision (EU) 2021/1339 on 18 August 2021, and is the current latest version in legal effect.
The latest version of the standard, EN 301 549 V3.2.1, includes the text of WCAG 2.1 in full. That means for web content, meeting WCAG 2.1 Level A and AA satisfies the web clauses of the standard. But - and this is the point most teams miss - since EN 301 549 goes further than the requirements of WCAG, meeting all the success criteria of WCAG 2.1 will not ensure a presumption of conformity.
WCAG compliance is necessary but not sufficient.
What EN 301 549 covers that WCAG does not
WCAG is a web content standard. EN 301 549 is an ICT standard. The scope difference is significant.
EN 301 549 provides technical accessibility criteria for a wide range of products and services, including websites, mobile applications, non-web software, operating systems, electronic documents, mobile devices, and telecommunications services.
The standard is structured around 14 clauses. Here is how the key ones map to product types:
| Clause | Scope | WCAG overlap? | Key requirements |
|---|---|---|---|
| 4 | Functional performance statements | Partial | 11 user-need statements (usage without vision, without hearing, with limited cognition, etc.). Not directly testable — met when clauses 5–13 are satisfied. |
| 5 | Generic requirements | No | Closed functionality, biometrics, privacy, preservation of accessibility info during conversion. |
| 6 | ICT with two-way voice communication | No | Real-Time Text (RTT), video quality for sign language, audio clarity, caller ID accessibility. |
| 7 | ICT with video capabilities | Partial | Captions, audio description, user controls for captions/audio description. |
| 8 | Hardware | No | Physical controls, operable parts, tactile indicators, access space, self-service terminals. |
| 9 | Web content | Full | Incorporates WCAG 2.1 Level A and AA in their entirety. |
| 10 | Non-web documents | Partial | PDFs, Word files, ePub — applies WCAG2ICT guidance. Includes document accessibility requirements not in WCAG. |
| 11 | Non-web software | Partial | Desktop apps, mobile apps, operating systems. References WCAG2ICT. Adds platform-specific requirements. |
| 12 | Documentation and support services | No | Accessible product documentation, support services. Only clause that is NOT self-scoping. |
| 13 | ICT providing relay or emergency services | No | Relay services, emergency call access, interoperability requirements. |
A few clauses deserve particular attention for product teams:
Clause 5 - Generic requirements. EN 301 549 requires that if a device uses biological data for identification - such as facial recognition or fingerprints - it must provide at least one alternative authentication method that does not rely on those specific biological features, ensuring users with disabilities affecting biometric recognition can still access secured systems. This has direct implications for identity verification flows, banking apps, and any product using biometric login.
Clause 6 - Two-way voice communication. Clause 6.2 of EN 301 549 has been substantially revised in more recent versions to require synchronisation of audio, high-quality video, and Real-Time Text for "total conversation" accessibility. If your product includes voice or video calling - VoIP, video conferencing, customer support tools - this clause applies to you.
Clause 8 - Hardware. The standard's scope includes self-service terminals. If you manufacture or deploy ATMs, ticketing kiosks, check-in machines, or any physical ICT with a user interface, hardware clauses apply alongside the software ones.
Clause 12 - Documentation. Unlike every other clause, documentation requirements are not self-scoping. All clauses except those in clause 12, related to documentation and support services, are self-scoping - meaning they are introduced with the phrase "Where ICT [pre-condition]". Clause 12 applies regardless of product type. Your user manuals, help content, and support services must be accessible.
The self-scoping mechanism
One of EN 301 549's most important design features is that most requirements are conditional. A distinctive feature of EN 301 549 is its "self-scoping" approach: many requirements begin with preconditions like "Where ICT provides..." This means requirements only apply when the ICT product or service provides that specific capability, making the standard applicable across diverse ICT contexts while remaining practical to implement.
In plain terms: if your product has no video functionality, video caption requirements do not apply. If it has no two-way voice, clause 6 does not apply. Your first task in any audit is scoping - determining which clauses are triggered by your product's actual capabilities.
EN 301 549 vs WCAG: the key differences
| Dimension | WCAG 2.1 AA | EN 301 549 v3.2.1 |
|---|---|---|
| What it covers | Web content only | Web, mobile apps, non-web software, documents, hardware, telecoms |
| Who produces it | W3C (international) | ETSI / CEN / CENELEC (European Standards Organisations) |
| Legal status in EU | No direct legal status — referenced via EN 301 549 | Harmonised standard; OJEU citation gives presumption of conformity |
| Functional performance statements | No equivalent | Clause 4: 11 user-need statements covering vision, hearing, cognition, mobility |
| Biometric requirements | Not covered | Clause 5.3: alternative to biometric identification required |
| Real-Time Text (RTT) | Not covered | Clause 6.2: RTT required for two-way voice communication products |
| Hardware | Not covered | Clause 8: physical controls, self-service terminals, tactile indicators |
| Documentation | Not covered | Clause 12: accessible product docs and support services required |
| Relay / emergency services | Not covered | Clause 13: interoperability with relay and emergency services |
| Audit documentation | WCAG conformance report | Accessibility Conformance Report (ACR) mapped to EN 301 549 clause numbers |
The practical implication: if your product is a pure web application with no downloads, no hardware, and no voice/video features, WCAG 2.1 AA and EN 301 549 clause 9 are effectively the same thing. But most real products are not that simple. A SaaS platform typically has a web interface (clause 9), downloadable reports (clause 10), a mobile app (clause 11), and product documentation (clause 12). Each requires separate scoping and testing.
The 2026 revision: EN 301 549 v4.1.1
A new version of the standard is expected to be published in 2026. Here is what is known, and what is not yet settled.
What the draft contains
ETSI published a draft of EN 301 549 V4.1.0 in November 2025. The significant changes from v3.2.1, as documented in the draft itself, are:
- The requirements of clauses 9, 10 and 11 have all been updated to align with the WCAG 2.2 recommendation, and the requirements related to Real-Time Text (RTT) in clause 6.2 have been significantly revised and extended.
- Draft V4.1.0 introduces critical new annexes - Annex ZA and ZB - which for the first time explicitly map the standard's technical requirements to the legal articles of the European Accessibility Act (Directive 2019/882). This is the structural change that will enable the new version to provide presumption of conformity specifically under the EAA, not just the Web Accessibility Directive.
- Clause 6 has been broadened from "two-way voice communication" to "real-time bidirectional communication," and now formally includes requirements for "Total Conversation" - the integration of voice, Real-Time Text (RTT), and video.
On the WCAG 2.2 update: the most significant change is the complete alignment of core technical requirements with WCAG 2.2, meaning that the accessibility criteria for web content (Clause 9), non-web documents (Clause 10), and software (Clause 11) now incorporate several new success criteria designed to address modern digital interactions. These include new criteria such as "Target Size (Minimum)" and "Dragging Movements" to improve usability on touch-screen devices, and "Accessible Authentication (Minimum)" and "Redundant Entry" to simplify complex login and form-filling processes.
What is not yet settled
Publication of the standard and its legal effect are two different things. A reference to the specific version of the standard must be published in the Official Journal of the EU before it carries presumption of conformity. Only once a modified standard is harmonised through a reference in the Official Journal does it have legal significance. New versions of WCAG or of EN 301 549 do not automatically change legal obligations.
V4.1.1 is expected to be referenced in the Official Journal of the European Union in October 2026. Until that OJEU citation happens, v3.2.1 remains the operative harmonised standard for presumption of conformity purposes.
Plan for WCAG 2.2 now, even though v3.2.1 still references 2.1. WCAG 2.2 is backwards-compatible with 2.1 — meeting 2.2 AA also satisfies 2.1 AA. Building to 2.2 today means you will not need to re-audit when v4.1.1 is harmonised. If your product includes voice or video communication, start reviewing the expanded RTT requirements in clause 6 now.
How to use EN 301 549 in practice
1. Scope your product against the standard, not just WCAG
Before testing, map your product's capabilities to the relevant clauses. Does it have a web interface? Clause 9. A mobile app? Clause 11. Downloadable documents? Clause 10. Voice or video calling? Clause 6. Physical hardware? Clause 8. Product documentation? Clause 12 always applies.
The standard has a "self-scoping" nature, meaning organisations must determine which requirements apply to their specific products or services. Do this scoping exercise before you commission an audit, not after.
2. Reference clause numbers in your conformance documentation
An Accessibility Conformance Report (ACR) for the EU market should map findings to EN 301 549 clause numbers, not just WCAG success criteria. Regulators and procurement teams expect to see clause-level evidence. A report that only references WCAG 2.1 SC 1.4.3 is incomplete - it should also reference EN 301 549 clause 9.1.4.3.
3. Watch the OJEU for the v4.1.1 citation
The work schedule for the standard shows it is not expected to reach its final stage until May 2026. The final version will be published in the Official Journal of the European Union. At that point, the standard will be legally considered to meet the requirements of the European Accessibility Act. Monitor the OJEU and ETSI's publication pages. The citation date - not the publication date - is when the new version becomes the operative harmonised standard.
4. Do not confuse WCAG compliance with EN 301 549 compliance
Complying with the full EN 301 549 standard is broader than just WCAG compliance. WCAG covers web content only. EN 301 549 also covers PDFs and documents (Chapter 10), native apps (Chapter 11), and video/audio capabilities (Chapter 7). If your product includes downloadable PDFs or a mobile app, you need to address those chapters too.
A practical pre-audit checklist
Use this to scope your work before engaging an auditor or writing your conformance report.
The bottom line
EN 301 549 is not a proxy for WCAG. It is the standard your products are measured against when EU regulators or procurement teams assess EAA conformity. WCAG 2.1 AA covers the web content clauses. The rest of the standard - hardware, telecoms, documents, software, documentation - requires separate scoping and testing.
The current operative version is v3.2.1, harmonised in August 2021. A new version incorporating WCAG 2.2 and explicit EAA mapping is expected in 2026, but it will only carry presumption of conformity once cited in the Official Journal. Until then, v3.2.1 is what counts - and building to WCAG 2.2 now is the sensible way to prepare for the transition.
For related reading, see our guides on WCAG 2.2 vs 2.1 and writing an EAA accessibility statement.
Is EN 301 549 the same as WCAG?
No. EN 301 549 incorporates WCAG 2.1 Level A and AA in full for web content (Clause 9), but it covers much more: non-web software, mobile apps, documents, hardware, telecommunications, and documentation. WCAG compliance alone does not give you presumption of conformity under the EAA.
Which version of EN 301 549 is currently in force?
EN 301 549 v3.2.1, published March 2021 and cited in the Official Journal on 18 August 2021, is the current harmonised version. It references WCAG 2.1 Level AA. A new version (v4.1.1) incorporating WCAG 2.2 is expected in 2026 but has not yet been harmonised.
Does EN 301 549 v4.1.1 already apply?
No. As of June 2026, v4.1.1 has not been published as a final standard and has not been cited in the Official Journal. A draft (v4.1.0) was released by ETSI in November 2025. The OJEU citation — expected around October 2026 — is what gives a version legal presumption of conformity.
My product is a pure web app. Do I need to worry about anything beyond WCAG?
Mostly no, for the web interface itself. But check: do you provide downloadable documents (Clause 10)? Do you have a help centre or product documentation (Clause 12)? If so, those clauses apply too. Clause 12 is not self-scoping — it applies to all products.
What is the difference between EN 301 549 being 'published' and being 'harmonised'?
Publication means ETSI/CEN/CENELEC have released the standard document. Harmonisation means the European Commission has cited it in the Official Journal of the EU. Only a harmonised standard confers presumption of conformity. A published-but-not-harmonised version is a useful technical reference but has no direct legal weight under EU directives.
Do I need to reference EN 301 549 clause numbers in my accessibility statement?
Yes, if you are writing a conformance report (ACR) for procurement or regulatory purposes. Your accessibility statement should state the standard you are measuring against — EN 301 549 v3.2.1 incorporating WCAG 2.1 AA — and your conformance status. Detailed ACRs should map findings to specific clause numbers.
Related reading
Cognitive Accessibility and the EAA: Why WCAG Compliance Isn't Enough
WCAG 2.1 AA is the EAA's legal floor - but it only partially covers people with cognitive and learning disabilities. Here's what teams must do beyond the standard.
Accessible Forms: The Developer's Fix-First Guide to WCAG 2.2 Compliance
Forms are where accessibility fails most and where the EAA bites hardest. A technique-level guide to labels, errors, grouping, autocomplete, redundant entry, focus, and keyboard - with code examples.
EAA Disproportionate Burden: Why Article 14 Is Not the Easy Exit You Think It Is
Article 14 of the EAA is not a blanket opt-out. Learn exactly how the disproportionate burden and fundamental alteration exemptions work, what Annex VI demands, and why weak claims invite enforcement.