EN 301 549 and WCAG: Understanding the EU Technical Standard

EN 301 549 is the EU's harmonized technical standard for ICT accessibility — and if your website serves European users, it directly affects you. This guide breaks down how EN 301 549 relates to WCAG, what its chapter structure means in practice, and what the EAA enforcement landscape looks like right now.

In the weeks after June 28, 2025 — the date the European Accessibility Act became enforceable — French disability advocacy organizations issued formal legal notices to four major grocery retailers, demanding their e-commerce platforms meet accessibility standards within months. Emergency injunctions followed by November. This is not a hypothetical future risk. EN 301 549 compliance is now an active enforcement reality, and understanding the technical standard that underpins it is no longer optional for any organization serving European users. <h2>What Is EN 301 549?</h2> <cite index="7-5,7-6">EN 301 549 is a European standard that specifies accessibility requirements for information and communications technology (ICT) products and services, setting guidelines for digital accessibility including for people with disabilities.</cite> It is not a law in itself, but it is the critical technical bridge between the guidelines developers already know and the legislation that carries real legal teeth. <cite index="25-6,25-7,25-8">This standard was jointly produced by the three European standardisation organizations — CEN (European Committee for Standardisation), CENELEC (European Committee for Electrotechnical Standardisation), and ETSI (European Telecommunications Standards Institute). EN 301 549 was originally published in 2014 to support public procurement of accessible ICT, and has been updated several times since then.</cite> <cite index="12-3,12-4">EN 301 549 harmonizes digital accessibility standards across EU Member States, creating a unified framework for assessing and improving the accessibility of ICT products and services. Conformance to EN 301 549 is required for technology products and services within the scope of the EU Web Accessibility Directive (WAD) and is a best practice for compliance with the European Accessibility Act (EAA).</cite> <cite index="1-16,1-17">EN 301 549 is a European accessibility standard that outlines technical accessibility criteria for ICT products and services. Developed by a consortium of European agencies, this standard provides detailed guidance for ensuring that various technologies — including hardware, software, websites, mobile apps, and telecommunications equipment — are accessible to people with disabilities.</cite> In other words, if your organization touches any of those categories and operates in the EU market, this standard is for you. <h2>The Relationship Between EN 301 549 and WCAG</h2> The most common question from developers and compliance managers is: If we already conform to WCAG, are we done? The honest answer is: mostly, but not entirely. Understanding the precise relationship between these two frameworks is essential before you can answer that question for your own situation. <cite index="1-5,1-6">EN 301 549 incorporates the Web Content Accessibility Guidelines (WCAG) as its foundation for digital accessibility requirements. The latest version of EN 301 549, version 3.2.1, integrates WCAG 2.1 in its entirety.</cite> This isn't just a reference by citation — <cite index="7-7">the latest version of the standard, EN 301 549 V3.2.1, includes the text of WCAG 2.1 in full.</cite> The two standards share the same underlying architecture: <cite index="3-6">EN 301 549 follows the same underlying WCAG principles: Perceivable, Operable, Understandable, Robust (POUR).</cite> The key distinction lies in scope. <cite index="1-8,1-9">While WCAG primarily focuses on web and mobile content, EN 301 549 expands its scope to include hardware, telecommunications, and other ICT components, making it a more comprehensive framework for digital accessibility.</cite> So for web content specifically, <cite index="22-1,22-2">Chapter 9 of EN 301 549 directly references WCAG 2.1 Level A and AA success criteria. If your web content conforms to WCAG 2.1 AA, it meets the Chapter 9 requirements of EN 301 549.</cite> However, there is an important legal nuance that many practitioners miss. <cite index="19-8">Since EN 301 549 goes further than the requirements of the WCAG, meeting all the success criteria of WCAG 2.1 will not ensure a presumption of conformity with the Web Accessibility Directive.</cite> The standard contains additional clauses — for things like real-time text communications, video player controls, and biometric accessibility — that have no WCAG equivalent. <cite index="3-34,3-35">EN 301 549 is unique in that it goes beyond WCAG, extending to cover biometrics — requiring that people with disabilities have access to technology that scans biological data, including facial recognition and fingerprints.</cite> <blockquote>WCAG tells you how to make your content accessible. EN 301 549 tells you which types of ICT must be accessible and to what degree — then borrows WCAG's criteria to define the technical bar for web content specifically.</blockquote> <h2>The Chapter Structure You Actually Need to Know</h2> EN 301 549 is organized into 14 clauses (chapters), each covering a different category of ICT. <cite index="23-8,23-9">The standard is organized into chapters covering different types of ICT, and not all chapters apply to every product — the key is identifying which chapters are relevant to your specific technology.</cite> For most website owners and developers, three chapters are most immediately relevant. Chapter 9 — Web Content: <cite index="23-19,23-20">This chapter covers web accessibility requirements, directly referencing WCAG 2.1 Level AA, and is the most relevant chapter for websites and web applications.</cite> The numbering system makes cross-referencing straightforward: <cite index="24-5,24-6">the clause numbers directly correspond to WCAG — EN 301 549 clause 9.X.Y.Z maps to WCAG X.Y.Z. For example, EN 301 549 clause 9.1.4.3 corresponds to WCAG 1.4.3 (Contrast).</cite> Chapter 10 — Non-Web Documents: <cite index="22-3,22-4">For non-web documents and software, EN 301 549 adapts the WCAG criteria to these contexts. The intent is the same — content must be perceivable, operable, understandable, and robust — but the specific techniques differ for native applications and document formats.</cite> This matters enormously for organizations that publish PDFs, Word documents, or downloadable spreadsheets. One important correction that arrived in v3.2.1: <cite index="31-16">due to an editorial oversight in v2.1.2, WCAG 2.1 now applies to documents downloaded from the web.</cite> Chapter 11 — Non-Web Software and Mobile Apps: <cite index="23-25,23-26">This chapter covers requirements for native applications (desktop and mobile) and software platforms, including requirements for interoperability with assistive technologies.</cite> Worth noting: <cite index="31-22,31-23">mobile applications are not covered by WCAG at all, even though Chapter 11 makes use of requirements from WCAG. This is because WCAG does not actually apply to mobile applications.</cite> If your organization ships a native iOS or Android app, Chapter 11 is where you live, not Chapter 9. Beyond these three, relevant additional chapters include Chapter 6 (two-way voice communication and real-time text), Chapter 7 (video and audio capabilities including captions and audio description), and Chapter 12 (documentation and support services — the one chapter that is not self-scoping and always applies). <h2>How EN 301 549 Fits Into the EU Legal Landscape</h2> There are two distinct EU laws that reference EN 301 549, and confusing them leads to compliance gaps. Understanding the difference is especially important for private-sector organizations that assumed accessibility law only applied to governments. The first is the Web Accessibility Directive (WAD), Directive (EU) 2016/2102. <cite index="2-15">The Web Accessibility Directive focuses primarily on public sector websites and mobile applications.</cite> <cite index="3-22,3-23">All semi-public sector websites in the European Union had to meet the standard as of September 23, 2020, and all mobile apps in the semi-public sector had to meet the standard by June 23, 2021.</cite> Public bodies must also publish an accessibility statement and provide a feedback mechanism. The second, and now more consequential for the private sector, is the European Accessibility Act (EAA), Directive (EU) 2019/882. <cite index="13-7,13-8">For the private sector, Europe developed the EU Directive 2019/882, also known as the European Accessibility Act, which is applicable to specific sectors including e-commerce, banking, e-books, and electronics.</cite> <cite index="11-6,11-7,11-8">The European Accessibility Act has been enforceable since June 28, 2025, and all websites, mobile apps, and digital services covered must comply with accessibility standards. This requirement applies to businesses offering digital services such as e-commerce, financial services, and telecommunications.</cite> Critically, the EAA has extraterritorial reach. <cite index="11-9">Notably, the EAA impacts both EU-based companies and businesses outside of Europe selling to EU consumers.</cite> A US-based SaaS company with European customers, or a UK retailer with an EU storefront, is in scope. The only significant carve-out: <cite index="17-7">microenterprises with under 10 employees and under €2 million turnover have limited exemptions, but most businesses operating in the EU are covered.</cite> <blockquote>EN 301 549 is the technical standard that provides a presumption of conformity under both the WAD and the EAA. Conforming to it is the clearest, most legally defensible route to demonstrating compliance with both directives.</blockquote> <h2>What EN 301 549 Requires Beyond WCAG</h2> If your team is already maintaining WCAG 2.1 AA conformance, you have a strong foundation. But several EN 301 549 requirements sit outside WCAG entirely, and they are worth examining in detail. Functional performance statements: Clause 4 of EN 301 549 introduces a set of high-level functional goals — usage without vision, without hearing, without speech, with limited cognition, and so on. These statements act as a safety net: if no specific technical requirement applies to a particular situation, products should still meet the underlying functional goal. This encourages designers to think in terms of user outcomes, not just checkbox compliance. Real-time text (RTT) and telecommunications: <cite index="23-16,23-17">Chapter 6 covers requirements for voice calls, video calls, and real-time text. These are important for VoIP, video conferencing, and telecommunications services.</cite> This is increasingly relevant as more organizations incorporate chat, audio, and video functionality directly into their web applications or customer portals. Accessible documentation and support: <cite index="10-16">EN 301 549 includes criteria requiring that user guides, help content, and customer support for ICT must be accessible.</cite> Chapter 12 applies to all products without exception — meaning your help documentation, support ticketing interfaces, and chatbots must all meet the standard alongside the main product. Hardware accessibility: <cite index="10-14">EN 301 549 includes criteria supporting hardware accessibility — devices must be physically accessible to users with disabilities, such as offering tactile feedback or adjustable height for kiosks.</cite> For most pure web teams, hardware chapters are not directly in scope. But if your product ecosystem includes point-of-sale devices, self-service kiosks, or ATM integrations, these clauses become very relevant. There are also country-specific standards within Europe that can go further than EN 301 549. <cite index="3-32,3-33">There are situations within Europe where a more specific local law or standard transcends EN 301 549 — examples include BITV in Germany and RGAA in France.</cite> Organizations operating in specific member states should investigate whether national transpositions have introduced additional requirements beyond the harmonized baseline. <h2>Conformance Levels and What Level AA Actually Means</h2> <cite index="3-28,3-29,3-30">Like WCAG, EN 301 549 has three levels of conformance: A, AA, and AAA. Level A refers to the lowest level of conformance (minimum) and Level AAA is the highest (maximum). Level AA is the mandatory level.</cite> For practical purposes, this means your web content needs to satisfy every Level A and Level AA success criterion, with no failures permitted for a full conformance claim. Level AAA is not required — and for good reason. <cite index="3-31">It is not recommended that Level AAA conformance be required as a general policy for entire sites, because it is not possible to satisfy all Level AAA Success Criteria for some content.</cite> That said, many Level AAA criteria — such as providing sign language interpretation for audio content or offering extended audio descriptions — are genuinely useful for a meaningful portion of your user base, and implementing them where feasible demonstrates good faith. One important nuance about the legal weight of conformance levels: <cite index="4-1,4-2">new versions of WCAG or of EN 301 549 do not automatically change the legal obligations of Member States with respect to the WAD. For changes to have an effect, the standard first has to be updated and then needs to be referenced in the Official Journal.</cite> This means that while WCAG 2.2 was published in October 2023, it only becomes legally binding under the WAD once the updated EN 301 549 version references it and that version is harmonized. For practical compliance planning, however, building to WCAG 2.2 is strongly advisable since it is the direction of travel. <h2>The Road Ahead: EN 301 549 Version 4.1.1 and WCAG 2.2</h2> The current harmonized version of EN 301 549, v3.2.1, is built on WCAG 2.1. But the standard is actively being updated. <cite index="16-3">EN 301 549 will be revised with the aim to publish V4.1.1 in 2026 in support of the European Directive (EU) 2019/882 on the accessibility requirements for products and services, as a response to the European Commission Mandate 587.</cite> <cite index="7-16,7-17">The next version of EN 301 549, v4.1.1, is planned to support the European Accessibility Act and to include WCAG 2.2 AA, as well as significant updates to requirements related to Real-Time Text.</cite> WCAG 2.2 introduced nine new success criteria, targeting users with low vision, users with cognitive and learning disabilities, and mobile users with motor impairments — areas where WCAG 2.1 had known gaps. It also removed criterion 4.1.1 (Parsing), which modern browsers had rendered obsolete. The practical implication for teams doing accessibility work today: build to WCAG 2.2 AA now, not WCAG 2.1. <cite index="14-3,14-4">EN 301 549 defines technical requirements and currently includes WCAG 2.1. However, the standard is slated to be updated as part of supporting the implementation of the EAA and is in the process of being updated to include WCAG 2.2.</cite> Organizations that wait for the official harmonization before upgrading their conformance target will find themselves scrambling to catch up. The delta between WCAG 2.1 and 2.2 at Level AA is nine criteria — not a wholesale rewrite, but meaningful work nonetheless. It is also worth noting the global reach of EN 301 549. <cite index="5-36">EN 301 549 has been adopted by other countries as a voluntary standard, including Australia and Canada, and closely aligns with Section 508 of the Rehabilitation Act in the U.S.</cite> If your organization has global compliance obligations, aligning with EN 301 549 is not just an EU strategy — it positions you well for multiple regulatory frameworks simultaneously. <h2>Practical Steps for Website Owners and Compliance Teams</h2> Given everything above, where should you actually start? The following approach works for most web-focused organizations, though teams with mobile apps, hardware, or telecommunications components will need to layer in the relevant EN 301 549 chapters on top. First, establish your WCAG 2.1 AA baseline. <cite index="1-18">Since EN 301 549 incorporates WCAG 2.1 Level AA, organizations that are already compliant with laws that refer to the global standard are well-positioned to achieve conformance with EN 301 549.</cite> Run a combination of automated scanning and manual testing with assistive technologies — screen readers, keyboard-only navigation, voice control — across your most critical user journeys. Automated tools are valuable but limited: <cite index="17-20,17-21">automated tools catch roughly 30–40% of accessibility barriers, and EN 301 549 conformance requires manual testing with assistive technologies across real user workflows.</cite> Second, identify which EN 301 549 chapters apply to your product. If your site offers downloadable PDFs, Chapter 10 applies. If you have an embedded video player, Chapter 7 matters. If you offer live chat or VoIP, review Chapter 6. If your product has a companion mobile app, Chapter 11 is in scope. Third, publish an accessibility statement. <cite index="18-7">The EU Web Accessibility Directive demands that websites and mobile applications have an accessibility statement on their level of compliance, indicating any content that is not accessible and, where appropriate, the accessible alternatives provided for.</cite> This isn't just a bureaucratic requirement — it demonstrates good faith, informs users what to expect, and provides a framework for ongoing remediation tracking. Fourth, upgrade your target to WCAG 2.2 AA. Given that EN 301 549 v4.1.1 will incorporate WCAG 2.2, beginning to address the nine new success criteria now — particularly those around focus appearance, dragging movements, and accessible authentication — means you won't face a compliance crunch when the new version is harmonized. Fifth, build accessibility into your development process, not on top of it. <cite index="11-17,11-18">Accessibility under the EAA is not a one-time milestone. It requires ongoing monitoring, remediation, and documented compliance efforts across digital properties.</cite> An accessibility statement filed once and forgotten is a liability, not an asset. Schedule regular audits, integrate automated checks into your CI/CD pipeline, and assign clear ownership for accessibility across product, design, and engineering. <h2>Key Takeaways</h2> <ul> <li>EN 301 549 is the EU's harmonized technical standard for ICT accessibility, incorporating WCAG 2.1 AA in full for web content while extending far beyond WCAG in scope to cover hardware, mobile apps, documents, telecommunications, and support services. Passing WCAG gets you most of the way there for your website, but not all of the way.</li> <li>The European Accessibility Act (EAA) became enforceable on June 28, 2025 and applies to private-sector businesses — including non-EU companies — that offer digital products or services to EU consumers. Conforming to EN 301 549 is the primary mechanism for demonstrating EAA compliance.</li> <li>Chapter 9 of EN 301 549 maps directly to WCAG 2.1 AA for web content, but Chapters 10, 11, 6, 7, and 12 introduce additional requirements for documents, mobile apps, communications, video, and support services respectively — all of which need to be assessed for your specific product scope.</li> <li>EN 301 549 v4.1.1, targeted for publication in 2026, will incorporate WCAG 2.2 AA. Building to WCAG 2.2 now avoids future remediation debt and positions your organization ahead of the next harmonization cycle.</li> <li>Ongoing compliance matters as much as initial conformance. Published accessibility statements, manual testing with real assistive technologies, and documented governance processes are what regulators and courts look for when evaluating whether an organization is taking accessibility seriously.</li> </ul>

En 301 549EuropeWcagStandardsEaaWeb accessibility directive