Image description: Hands on a mechanical keyboard with a technical-standards document open on an external monitor — the accessibility-auditor’s workspace where EN 301 549 lives.
Reading Time: 11 minutes
EN 301 549 is the harmonised European standard for accessibility requirements applicable to ICT products and services. Published and maintained by ETSI — the European Telecommunications Standards Institute — in cooperation with CEN and CENELEC, it is the technical instrument that turns the more abstract obligations of the European Accessibility Act (EAA), the Web Accessibility Directive (Directive (EU) 2016/2102), and most national public-procurement rules into a clause-by-clause checklist that a vendor can be measured against. Where WCAG is a content-and-interface standard for the web, EN 301 549 is the broader frame that wraps WCAG inside the requirements that EU law actually procures against.
In 2026 the in-force version is V3.2.1, published in March 2021 and incorporating WCAG 2.1 Level AA by reference. A new revision incorporating WCAG 2.2 AA — provisionally numbered V4.0.0 — is in late-stage drafting inside the joint ETSI/CEN/CENELEC technical body and is expected to publish during 2026, with citation in the Official Journal of the European Union following. This piece is a primer: what the standard is, how its twelve chapters are organised, where Chapter 9 (web) and Chapter 11 (software) sit alongside Chapter 10 (documents) and Chapter 12 (documentation and support), how the standard bridges WCAG to EU procurement law, and where you will see it cited in the legislation graph you already know.
What EN 301 549 actually is — and what it is not
EN 301 549 is a harmonised European standard. That phrase has a precise meaning in EU law: it is a standard developed by one of the three recognised European Standards Organisations (ETSI, CEN, CENELEC) at the request of the European Commission via a formal “standardisation request” (also called a “mandate”) and then cited in the Official Journal of the European Union as giving “presumption of conformity” with the corresponding piece of EU legislation. A product or service that meets the harmonised standard is presumed to meet the legal requirements it harmonises. The presumption can be rebutted, but in practice public buyers, accessibility auditors and conformance bodies treat the standard as the operative checklist.
EN 301 549 originated from Mandate M/376, issued by the Commission in 2005 to make Europe’s procurement rules procurement-ready for accessibility — a single, technology-neutral, harmonised reference for what “accessible ICT” means across the public-sector tendering process. The first published version, V1.1.2, appeared in 2014. The standard has since gone through three substantive revisions: V2 (2018) aligning with WCAG 2.1, V3.1.1 and V3.2.1 (2019–2021) tightening definitions and adding mobile-app and authoring-tool clauses, and the forthcoming V4 incorporating WCAG 2.2.
What EN 301 549 is not: it is not the EAA, and it is not the Web Accessibility Directive. Those are the laws that procure against the standard. EN 301 549 is the test-criterion document — the part of the system a developer or a procurement officer actually reads to know whether a deliverable passes.
The twelve-chapter structure
EN 301 549 is organised around twelve substantive clauses (numbered from Clause 4 in the document, because Clauses 1–3 are scope and definitions). The architecture is deliberately modular: a vendor scoping a tender response works out which clauses apply to the product, applies only those, and declares conformance against the named clauses. The headline modules sit in Chapters 9 through 12.
Chapter 9 — Web content
Chapter 9 is the chapter that most accessibility practitioners arrive at first, because it is the one that incorporates WCAG by reference. In V3.2.1, Chapter 9 imports the WCAG 2.1 Level A and Level AA success criteria verbatim: clause 9.1 covers the perceivable success criteria, 9.2 the operable, 9.3 the understandable, 9.4 the robust. A web product that conforms to WCAG 2.1 AA conforms to Chapter 9. The standard does not paraphrase the WCAG text; it cites it. In V4 the same chapter will reference WCAG 2.2 AA, picking up the nine new and revised success criteria — including 2.4.11 Focus Not Obscured (Minimum), 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 3.3.8 Accessible Authentication (Minimum), and 3.3.9 Accessible Authentication (Enhanced).
Chapter 10 — Non-web documents
Chapter 10 applies WCAG-equivalent requirements to non-web documents — PDFs, Word files, slide decks, ePub, and any other document delivered alongside or outside the web. It does this by taking each WCAG 2.1 success criterion that makes sense for a non-web document and restating it in the document context. A tagged, navigable, properly-described PDF conforms to Chapter 10; an untagged scan of a printed report does not. Public buyers procuring policy publications, contract terms, training materials and accessibility statements rely on Chapter 10 to set the bar for what they accept as a deliverable.
Chapter 11 — Non-web software
Chapter 11 is the broadest module and the most consequential for the modern application stack. It applies WCAG-equivalent requirements to non-web software — desktop applications, native mobile apps, embedded interfaces, kiosks running custom software — and adds requirements that are software-specific and have no WCAG analogue: clauses on platform accessibility services (11.5), on assistive-technology compatibility (11.6), and on authoring tools (11.8, derived from the W3C’s Authoring Tool Accessibility Guidelines). The mobile-app coverage in Chapter 11 is the reason the Web Accessibility Directive can extend to public-sector mobile applications, and the reason the EAA can apply to e-readers, ticketing machines and self-service terminals without needing a separate standard for each.
Chapter 12 — Documentation and support services
Chapter 12 covers documentation and customer-support services: user manuals, help systems, support call centres, online chat, accessible formats on request. The clauses require that product documentation describe the accessibility features of the product, that documentation itself be accessible, and that support services be available through accessible channels. This is the chapter that ties accessibility to the post-purchase experience — the part of the buying journey where users actually encounter the product and need help with it.
Chapters 5–8 — the cross-cutting generic requirements
Chapters 5 through 8 sit upstream of the format-specific modules. Chapter 5 covers generic requirements that apply to any ICT product or service — closed functionality, biometrics, preservation of accessibility information through conversion. Chapter 6 covers ICT with two-way voice communication: real-time text, video relay, and the interoperability requirements that make accessible communication possible across service providers. Chapter 7 covers ICT with video capabilities — audio description, captioning, signed presentation. Chapter 8 covers hardware: keyboards, controls, connectors, physical access. A product is rarely scoped against only one chapter; a video-streaming app on a smart TV will touch Chapters 5, 7, 9 (if it has a web interface), 11 (the app itself) and 12 (its documentation) at once.
Chapter 13 and the annexes
Chapter 13 deals with ICT providing relay services and emergency-services access — the public-interest communications layer. The annexes are where the standard does its procurement-binding work: Annex A contains the conformance methodology, including the mandatory “accessibility statement” template; Annex B maps EN 301 549 clauses to the corresponding requirements in U.S. Section 508 — useful for vendors selling on both sides of the Atlantic; Annex C provides guidance on functional performance statements; and the bibliography lists every standard, including WCAG, that the document incorporates by reference.
How WCAG 2.1 AA actually sits inside EN 301 549
The relationship between WCAG and EN 301 549 is the single most asked question in conformance work, and the answer is more specific than “EN 301 549 includes WCAG.” WCAG 2.1 Level AA is incorporated into Chapter 9 (web content) and parts of Chapter 11 (software, where the success criteria are applicable to non-web software). The incorporation is by reference, not by paraphrase: Chapter 9’s clauses are numbered to mirror WCAG’s structure, and each clause points to the corresponding success criterion in the W3C recommendation. A WCAG 2.1 AA conformance claim translates directly into a Chapter 9 conformance claim.
Where EN 301 549 goes beyond WCAG is in the software-specific, hardware-specific and documentation-specific clauses that WCAG was never designed to cover. WCAG addresses content perceivable, operable, understandable and robust within a web user agent. EN 301 549 adds the requirements that handle, for example, a desktop app’s interaction with a screen-reader API on Windows, a hardware keyboard’s tactile discriminability, or a contact-centre’s TTY interoperability. A product can be WCAG 2.1 AA conformant and still fail EN 301 549 — typically because Chapters 11 or 12 cover requirements WCAG does not address.
Where EN 301 549 is cited in EU law
The standard’s load-bearing role is in the citation graph. Three primary legal instruments name EN 301 549 as the technical reference; several dozen national procurement laws and accessibility statutes do the same.
The European Accessibility Act (Directive (EU) 2019/882)
The European Accessibility Act sets functional accessibility requirements for a defined list of products and services — computers, smartphones, e-readers, ATMs, ticketing machines, e-commerce, e-books, telephony, audiovisual media services, banking services, passenger transport information. The Act’s functional requirements (Annex I) are abstract; they require, for example, that information be provided in accessible formats, that user interfaces support assistive technology, that emergency communications work with deaf users. To make those abstract requirements operational, the EAA relies on harmonised standards cited under Article 15 of Regulation (EU) 1025/2012 — and EN 301 549 is the harmonised standard the European Commission is using to operationalise the EAA’s web, software and documentation requirements. A product that conforms to the relevant clauses of EN 301 549 carries presumption of conformity with the EAA. The first Official Journal citation of EN 301 549 specifically for EAA purposes published in 2024; revisions follow each new version.
The Web Accessibility Directive (Directive (EU) 2016/2102)
The Web Accessibility Directive, in force since December 2016, requires public-sector bodies in EU Member States to make their websites and mobile applications accessible. Article 6 of the Directive states that content meeting the harmonised standard cited in the Official Journal is presumed to conform with the corresponding accessibility requirements set out in Article 4. EN 301 549 is the standard so cited — V2 from 2018 was the first version named for WAD purposes, with each subsequent revision triggering a new OJ citation. Public-sector websites and mobile apps that meet Chapter 9 and the applicable parts of Chapter 11 are deemed compliant with the Directive.
National procurement laws and Article 42 of the Public Sector Procurement Directive
Article 42 of Directive 2014/24/EU (the Public Sector Procurement Directive) requires that technical specifications in public tenders for products and services that will be used by natural persons “take into account accessibility criteria for persons with disabilities or design for all users.” Member States have implemented that obligation in their national procurement codes, and the implementing texts typically name EN 301 549 as the reference standard — from Germany’s BITV 2.0 and the EU-Verordnung referenced in federal procurement, to Spain’s Real Decreto 1112/2018, to France’s RGAA (which aligns its criteria with EN 301 549 Chapter 9), to Italy’s Linee Guida AgID, to the Netherlands’ Tijdelijk besluit digitale toegankelijkheid overheid. The national-procurement layer is where EN 301 549 has the most day-to-day commercial impact, because it determines which vendors can bid for which public contracts.
What V4 changes — and what it does not
The forthcoming V4 of EN 301 549 is the working title for the revision that will incorporate WCAG 2.2 AA in place of WCAG 2.1 AA, picking up the nine success criteria the W3C added or revised in the 2023 update. The working revision has been visible in ETSI’s Technical Committee Human Factors public archive since 2024, and the joint ETSI/CEN/CENELEC working group convened during 2025 to finalise it. Publication during 2026 is the working assumption inside the standards community; OJ citation under the EAA and WAD then follows on the Commission’s usual timeline (typically several months after ETSI publication).
The substantive deltas in V4 cluster around two areas. First, the WCAG 2.2 success criteria themselves — Chapter 9 picks up the nine new criteria, the most operationally significant being Focus Not Obscured, Target Size (Minimum), Dragging Movements, and the two Accessible Authentication criteria, which together will force a re-audit of any product that uses overlay banners, cookie modals, password fields, or small tap targets. Second, the standard’s software clauses (Chapter 11) are being tightened to align more closely with WCAG 2.2 for software where the success criteria apply, and to update the platform-accessibility-services language to reflect the assistive-technology APIs that have shipped since 2021.
What V4 does not change: the twelve-chapter architecture, the conformance-statement template in Annex A, the relationship to the EAA and WAD, or the Section 508 mapping in Annex B. A vendor that has a current conformance statement against V3.2.1 will, in most cases, need to re-test for the new WCAG 2.2 criteria but not re-architect their conformance approach.
Using EN 301 549 in practice: the conformance statement
The operational artefact that EN 301 549 produces is a conformance statement — sometimes called an “accessibility statement” in WAD usage, or a Voluntary Product Accessibility Template (VPAT) when expressed in the Section 508 lineage. Annex A of the standard contains the template. For each applicable clause, the vendor states whether the product “Supports,” “Partially Supports,” “Does Not Support,” or “Not Applicable.” Each “Partially Supports” or “Does Not Support” must be accompanied by a remarks-and-explanations field describing the gap.
In a tender response, the procurement officer scopes the relevant chapters to the product, requires a clause-by-clause conformance statement, and evaluates the gaps. The statement is contractually binding in most EU public-procurement frameworks — if the vendor declares “Supports” against a clause and the product subsequently fails on that clause during user acceptance, the contract typically gives the buyer grounds for remediation, penalties, or rescission. This is why EN 301 549 has more commercial bite than the underlying WCAG document on its own: WCAG is a W3C recommendation with no procurement standing; EN 301 549 is the document a contract names.
EN 301 549 in the legislation graph you already know
If you have followed the EU disability-rights legislation arc — the EAA, the Web Accessibility Directive, the national procurement codes that implement Directive 2014/24/EU — EN 301 549 is the technical underlay that connects those laws to a vendor’s day-to-day testing process. WCAG sets the web-content rules. EN 301 549 wraps WCAG in the wider set of requirements (software, documents, documentation, hardware, two-way communications) that EU procurement law actually buys against. The EAA and WAD then cite EN 301 549 as the standard that triggers presumption of conformity. National procurement codes name the standard in their technical specifications, and accessibility auditors test against it clause by clause.
For practitioners scoping a 2026 audit: V3.2.1 is the version to test against today, V4 is the version to start preparing for, and the deltas worth getting ahead of are the nine WCAG 2.2 success criteria — particularly the focus-appearance and target-size criteria, which are the ones most products are quietly failing. The fastest way to spot which 2.2 criteria your site already trips on is a free WCAG 2.2 scan on a representative page. For the wider 2026 reporting record on how this standard interacts with national enforcement, see the Disability World article index; for the EAA’s first-year enforcement picture across Member States, see the EAA primer. For a hands-on translation of V3.2.1 + the 2.2 deltas into a working audit, see the step-by-step WCAG 2.2 compliance playbook; for the monitoring platforms that maintain conformance between audits, see the accessibility monitoring buyer’s guide.
Primary sources
- ETSI / CEN / CENELEC. EN 301 549 V3.2.1 (2021-03) — Accessibility requirements for ICT products and services. etsi.org
- European Commission. Standardisation request M/376 (2005) on ICT accessibility for public procurement.
- Directive (EU) 2019/882 of the European Parliament and of the Council on the accessibility requirements for products and services (European Accessibility Act).
- Directive (EU) 2016/2102 of the European Parliament and of the Council on the accessibility of the websites and mobile applications of public sector bodies.
- Directive 2014/24/EU of the European Parliament and of the Council on public procurement, Article 42.
- Regulation (EU) No 1025/2012 of the European Parliament and of the Council on European standardisation.
- W3C. Web Content Accessibility Guidelines (WCAG) 2.1 (W3C Recommendation, June 2018) and WCAG 2.2 (W3C Recommendation, October 2023).
- ETSI Technical Committee Human Factors. Public archive on EN 301 549 revision activity (2024–2025).