What Is EN 301 549 and How Does It Relate to WCAG?
Published
Introduction
If you're already familiar with WCAG, you'd be impressed to know that it's being integrated into laws in the EU. WCAG on its own is a set of guidelines, you're generally not legally required to follow them. But the EU took it a step further by releasing EN 301 549, which is an accessibility standard.
So, what is this standard?
EN 301 549 is the European standard for accessibility of ICT (Information and Communication Technology). Unlike WCAG, it doesn't just apply to websites, it covers everything from mobile apps to hardware, software, documentation, and even customer support. It includes WCAG, yes, but it also goes beyond it.
This post will walk you through:
- What EN 301 549 is and why it exists
- What kinds of technologies it applies to
- How it incorporates WCAG 2.1 (and where WCAG fits inside it)
- What it covers that WCAG doesn't, like authoring tools, documentation, and hardware
- Why accessibility practitioners should care
Prerequisite
Before diving into EN 301 549, it's helpful to have a basic understanding of WCAG (Web Content Accessibility Guidelines). If you're not familiar with WCAG, I recommend checking out my previous post on Understanding WCAG.
So, let's get into it.
Who Is EN 301 549 For?
EN 301 549 is primarily aimed at public and private sector organizations in the European Union, but its relevance extends way beyond Europe.
Here's who should care:
- Accessibility practitioners and auditors, especially if you're working with clients in Europe or even prepping for the WAS exam
- Developers and designers building ICT products that may be sold, used, or regulated in the EU
- Policy and compliance teams who need to ensure their org meets legal accessibility obligations under the EU Web Accessibility Directive or the European Accessibility Act
- Procurement teams evaluating tech tools or services based on accessibility standards
- Educators and trainers teaching accessibility best practices or creating courseware/tools
And if you're a solo dev, freelancer, or startup building products that might one day scale globally, understanding EN 301 549 helps you bake in accessibility from the start, not scramble to fix it under legal pressure.
What Technologies Does EN 301 549 Apply To?
Unlike WCAG, which is focused strictly on web content, EN 301 549 has a much wider scope. It applies to pretty much any ICT product or service used in the EU, whether it's for the public or private sector.
So what falls under that umbrella?
Here are some examples of technologies EN 301 549 covers:
- Websites and web apps
- Mobile apps (iOS, Android, etc.)
- Desktop software (productivity tools, design software, anything you install)
- Operating systems
- Hardware devices, including ATMs, POS (point-of-sale) terminals, ticket machines, and self-service kiosks
- Digital documents such as PDFs, Word docs, and EPUBs
- Telecommunication services like video relay or text-based emergency services
- Multimedia audio/video content, live streaming, captions, audio descriptions
- Documentation and support services, including help centers, customer service chat, or phone support
EN 301 549 Approach
One of the most important things to know about EN 301 549 is that it doesn't assume every product or service needs to meet every requirement. It uses what's called a feature-based or self-scoping approach.
Each requirement usually starts with a condition like:
“Where ICT displays video with synchronized audio…”
“Where the software includes user authentication…”
So if your product doesn't have that feature (for example, it doesn't play video at all), then that particular requirement doesn't apply. But if the condition is met, then you're expected to meet the requirement, and it will be tested during an audit.
This makes EN 301 549 flexible and adaptable to different types of technologies, while still ensuring that accessibility is built in where it matters.
Understanding the Normative Sections in EN 301 549
EN 301 549 is divided into multiple clauses and annexes, but not all of them are required for conformance. normative (must be followed) and others are informative (nice to know, but not binding).
If you're reading the spec for the first time, you might get overwhelmed if you don't know the difference, so let's break it down.
Key Normative Clauses You Should Know
These are the core sections you must follow if they apply to your ICT:
- Clause 4: Functional Performance Statements
This clause doesn't include testable requirements, but it's the heart of the standard. It outlines the user needs that Clauses 5-13 aim to meet, focusing on how people with disabilities access and operate ICT. Understanding it helps explain the why behind the technical requirements. (Bonus: Annex B maps those requirements back to these user needs.)
- Clause 5: Generic Requirements
This clause covers requirements broadly applicable to all ICT products and services, regardless of the specific technology. Key areas include:
- Closed Functionality
- Activation of Accessibility Features
- Biometrics
- Preservation of Accessibility Information during Conversions
- Operable Parts
- Locking or Toggle Controls
- Key Repeat
- Double-Strike Key Acceptance
- Simultaneous User Actions
- Clause 6: ICT with Two-Way Voice Communication
This clause outlines requirements for ICT that enables two or more persons to communicate using their voices. Key requirements include:
- Audio Bandwidth for Speech
- Real-Time Text (RTT) Functionality
- Caller Identification
- Alternatives to Voice-Based Services
- Video Communication
- Speaker identification with video (sign language) communication
- Alternatives to Video-Based Services
- Clause 7: ICT with Video Capabilities
This clause focuses on accessibility aspects of video content within ICT solutions. It covers:
- Caption Processing Technology
- Audio Description Technology
- User Controls for Captions and Audio Description
- Clause 8: Hardware
This clause addresses both the physical components of ICT and how users physically access and interact with them. Key areas include:
- General Requirements
- Hardware Products with Speech Output
- Stationary ICT
- Mechanically Operable Parts
- Tactile Indication of Speech Mode
- Clause 9: Web
This chapter primarily refers to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. It covers the four principles of accessibility:
- Perceivable
- Operable
- Understandable
- Robust
- WCAG 2.1 AAA Success Criteria
- WCAG Conformance Requirements
- Clause 10: Non-Web Documents
This clause applies to digital documents that are not web pages, not embedded in web pages, or documents provided via web pages but not rendered with them (e.g., downloadable documents, user manuals, newsletters) It largely uses WCAG 2.1 success criteria, with specific adaptations for non-web documents. Some WCAG criteria are not applicable, resulting in "empty clauses". It also includes unique requirements for:
- Caption Positioning
- Audio Description Timing
- Clause 11: Software
This clause addresses requirements for platform software, software with a user interface (including its content), authoring tools, and mobile applications. It also bases many requirements on WCAG 2.1, with tables explaining their application in a non-web context. It also include:
- Interoperability with Assistive Technology
- Documented Accessibility Usage
- User Preferences
- Authoring Tools
- Clause 12: Documentation and Support Services
This clause ensures that information and assistance provided with ICT are accessible. It covers:
- Product Documentation
- Support Services
- Clause 13: ICT Providing Relay or Emergency Service Access
This clause addresses services that facilitate communication for individuals with varying abilities. It includes:
- Relay Services Requirements
- Access to Relay Services
- Access to Emergency Services
- Annex C: Determination of Conformance
Annex C is a normative annex that outlines the means necessary to determine conformance with individual requirements through specific procedures for testing or inspection
How EN 301 549 Relates to WCAG
One of the most important things to know about EN 301 549 is that it includes WCAG 2.1 Level AA as a normative requirement, but only as part of the bigger picture.
As listed already, WCAG shows up in:
- Clause 9: Web Content - conformance to WCAG 2.1 Level AA for all web content.
- Clause 10: Non-Web Documents - if your digital document is meant to be consumed electronically, it should follow WCAG.
- Clause 11: Software - if your software has a user interface, it should follow WCAG.
So… If I Follow WCAG, Am I Covered?
Not completely.
Conforming to WCAG 2.1 AA means you've met a subset of EN 301 549, but not the whole standard. WCAG only covers content, not:
- Hardware
- Support services
- Authoring tools
- Voice communication
- Functional performance
- Documentation
To fully conform to EN 301 549, you have to look beyond WCAG and cover all applicable clauses (depending on your ICT type).
Understanding EN 301 549 Annexes
The EN 301 549 standard includes several annexes that provide additional important information and guidance. Here's a brief overview of Annexes A through E:
Annex A: Relationship between the present document and the essential requirements of Directive 2016/2102
This annex describes how the EN 301 549 standard relates to the European Web Accessibility Directive (Directive 2016/2102). It provides tables that list the specific requirements from the standard that are relevant for fulfilling this Directive
It is an informative annex. Annex A.1 focuses on web content, including web pages, downloadable documents, and software embedded in web pages, while Annex A.2 covers mobile applications. It also notes that certain requirements, such as those for live time-based media (e.g., live captions), are not relevant for the Web Accessibility Directive
Annex B: Relationship between requirements and functional performance statements
This annex contains a table that maps the technical requirements (from clauses 5 to 13) to the functional performance statements defined in Chapter 4. It helps you understand the impact that a specific accessibility issue might have on different user groups.
The table uses abbreviations like "P" for a Primary relationship (the requirement directly supports the functional performance statement) and "S" for a Secondary relationship (partial support for some users in specific situations). This is a key instrument for making assessments, especially in procurement, by showing for whom each requirement is important.
Like Annex A, Annex B is informative
Annex C: Determination of conformance
This annex is normative. It describes a test procedure for each requirement, detailing preconditions, procedures, and expected results (Pass, Fail, Not Applicable, or Not Testable)
It's important to note that Annex C does not provide a detailed testing methodology itself; actual testing requires significant skills and experience, which necessites involvement of experts.
Annex D: Further resources for cognitive accessibility
This annex is informative and points to additional resources related to improving accessibility for users with limited cognitive, language, and learning abilities. It acknowledges that research in this area is ongoing and refers to the W3C Web Accessibility Initiative (WAI) for relevant standardization work
Annex E: Guidance for users of the present document
This annex is also informative and serves as an explanatory guide for users of the standard. It provides an overview and simple explanation of the structure of the EN 301 549 document, including how to effectively use it.
It highlights the importance of Chapter 4 (Functional Performance Statements) as the "heart of the standard" because it explains the user needs that the accessibility requirements aim to solve. It also discusses the concept of "self-scoping" requirements, where applicability depends on specific preconditions.
While these annexes may not get as much attention as the Clauses, they're critical for practitioners who want to:
- Scope accessibility work correctly
- Understand the user impact
- Perform or prepare for formal conformance testing
Why EN 301 549 Matters for Accessibility Practitioners
If you work in accessibility, especially in or around Europe, EN 301 549 isn't just “nice to know”, it's essential.
It's Part of the Legal Framework
EN 301 549 underpins major EU accessibility laws:
- The EU Web Accessibility Directive applies to public sector websites and mobile apps
- The European Accessibility Act (EAA) expands to the private sector, including e-commerce, banking, e-books, and more (enforceable from 2025)
Both laws reference EN 301 549 as the standard to meet. That means your designs, products, and audits need to align with it if you're serving European users or institutions.
It Supports Better Audits, Design, and Procurement
Understanding EN 301 549 helps you:
- Scope accessibility audits beyond just websites
- Create accessible products across platforms not just for the web
- Evaluate tools or vendors during procurement using standardized criteria
You'll be building systems that work for everyone, across the full range of tech experiences.
It's Useful Beyond Europe
Even outside the EU, EN 301 549 can give your work a major edge:
- It helps you future-proof your product for international markets
- It aligns closely with Section 508 (US) and WCAG
- It deepens your understanding of accessibility as a system-wide concern, not just a checklist for web content
Conclusion
EN 301 549 is more than just a European accessibility standard, it brings accessibility into every layer of the user experience.
It goes beyond websites, or checklists, and into system-wide accessibility that includes hardware, documents, support services, and even emergency service access.
If you're prepping for the WAS exam, building a global product, or shaping policy in your org, EN 301 549 helps you level up.
You can read the full spec at EN 301 549 v3.2.1 (ETSI Official Site)
If you're new to this standard, I hope this guide gave you a clearer picture of what it covers and how to use it.