A comprehensive guide to understanding and implementing the European ICT Accessibility Standard - the harmonized technical specification for accessibility requirements across the EU
EN 301 549, formally titled "Accessibility requirements for ICT products and services," is a European standard published by the European Telecommunications Standards Institute (ETSI). First published in 2014 and regularly updated since then (current version 3.2.1 was harmonized in August 2021), this standard provides comprehensive technical specifications for making information and communication technology accessible to persons with disabilities.
The standard is unique in its scope and ambition. Unlike many accessibility standards that focus narrowly on specific technologies (like websites or mobile apps), EN 301 549 covers the entire spectrum of ICT products and services, including:
By providing a single, unified set of requirements applicable across all these domains, EN 301 549 eliminates the need for organizations to navigate multiple, potentially conflicting standards. This harmonization is particularly valuable for businesses and public sector bodies operating across EU member states.
EN 301 549 has special legal status as a harmonized European standard. This designation, formalized when the European Commission published a reference to the standard in the Official Journal of the European Union on August 18, 2021, carries significant legal implications:
When you comply with a harmonized standard, you benefit from a "presumption of conformity" with the legal requirements of EU directives and regulations that reference that standard. In practical terms, this means:
EN 301 549 is explicitly referenced by major EU accessibility legislation:
This means that whether you're a private business complying with the EAA or a public sector body complying with the Web Accessibility Directive, EN 301 549 provides the technical specification you need to follow.
For web content specifically, EN 301 549 incorporates the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA verbatim. This is not a loose alignment or interpretation—it's a direct copy-paste of the WCAG success criteria into the standard.
Specifically, Chapter 9 of EN 301 549 ("Web content") and Chapter 10 ("Non-web documents") reproduce WCAG 2.1 Level A and Level AA success criteria exactly. This means that if you already know WCAG 2.1, you already understand the web content requirements of EN 301 549.
However, EN 301 549 goes beyond WCAG by also covering aspects that WCAG doesn't address: hardware ergonomics, two-way voice communication, relay services, video players, and more. It's WCAG plus extensive additional requirements for non-web ICT.
EN 301 549 has evolved significantly since its inception:
The standard is maintained by ETSI's Technical Committee Human Factors (TC HF) and is regularly reviewed to ensure it remains aligned with technological developments and international best practices. Future versions will likely incorporate WCAG 2.2 and eventually WCAG 3.0 (currently in development) when those standards mature.
EN 301 549 is organized into 14 main chapters, each addressing different aspects of ICT accessibility. Understanding this structure helps you navigate the standard and identify which requirements apply to your specific products or services:
This crucial chapter describes what users with disabilities need to be able to do with ICT, independent of any specific technology. These are high-level, outcome-focused requirements covering:
These functional performance statements serve as a backstop—if specific technical requirements don't exist for a novel technology, you can evaluate compliance against these functional outcomes.
Requirements applicable to all ICT, regardless of specific technology type:
Requirements for telecommunication services, VoIP, video conferencing, and similar technologies. Covers audio quality, real-time text, video communication for sign language users, and more.
Requirements for media players, video conferencing systems, and video content. Includes caption display, audio description playback, sign language presentation, and user controls.
Physical accessibility requirements for devices, covering connection ports, mechanical controls, keys and controls, tactile indication, visual contrast, visual indication of audio, connection of assistive technologies, and more.
Requirements ensuring that product documentation and customer support are accessible. Documentation must be available in accessible formats, and support services must accommodate different communication needs.
Requirements for relay services (allowing people who are deaf or hard of hearing to communicate via telephone) and access to emergency services.
The standard includes informative annexes providing additional guidance, including tables mapping requirements to functional performance statements and guidance on determining applicability.
As mentioned, Chapter 9 of EN 301 549 incorporates WCAG 2.1 Level A and Level AA success criteria verbatim. This chapter applies to web pages, including:
The requirements are organized according to WCAG's four principles—Perceivable, Operable, Understandable, and Robust (POUR). Since these are identical to WCAG 2.1 Level AA, any resource explaining WCAG 2.1 compliance applies equally to EN 301 549 Chapter 9 compliance.
While we won't reproduce all 50 Level A and AA success criteria here (they're documented extensively in WCAG resources), these are among the most commonly violated and impactful requirements:
Every non-text element—images, icons, charts, graphs, buttons without text—must have a text alternative that conveys equivalent information. This allows screen reader users to understand visual content.
All functionality must be operable through a keyboard interface without requiring specific timings for individual keystrokes. There must be no keyboard traps where users get stuck and can't navigate away.
Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text). User interface components and graphical objects must have at least 3:1 contrast.
Use proper heading markup (H1-H6) to structure content logically. Headings should be descriptive and in logical order. Form labels must be properly associated with their controls.
Any keyboard-operable interface must have a mode of operation where the keyboard focus indicator is visible. Never remove focus outlines without providing an equally visible alternative.
For all user interface components, the name and role can be programmatically determined. States, properties, and values can be programmatically set and communicated to assistive technologies (typically using ARIA).
Chapter 11 applies to software that is not web content, including:
One of the most important aspects of Chapter 11 is the requirement for software to properly utilize platform accessibility services. This means:
Software must use documented platform accessibility services rather than implementing custom, incompatible solutions. For example:
By using these platform services, your software automatically becomes compatible with assistive technologies like screen readers, screen magnifiers, voice control, and switch access that users already have installed and know how to use.
Every user interface element must expose programmatically determinable information about its:
Assistive technologies must be able to programmatically move focus and modify text selection. This allows screen reader users to navigate and edit content efficiently.
Just like web content, all software functionality must be available via keyboard. This includes custom controls, dialogs, menus, and any interactive elements. Keyboard shortcuts should be discoverable and customizable where feasible.
Keyboard focus must be clearly visible. Many native UI frameworks provide default focus indicators, but if you customize UI appearance, ensure focus remains obvious.
Software should respect user preferences for:
Don't override system-level accessibility settings unless the user explicitly chooses application-specific settings.
If your software is an authoring tool—something users use to create content (content management systems, document editors, website builders, etc.)—additional requirements apply:
Chapter 8 requirements apply to physical ICT devices with user-facing hardware controls and features, including:
For fixed installations like ATMs and kiosks:
Where speech output is available, there must be a tactile indicator (like a raised dot or symbol) on at least one mode of operation that provides speech output, allowing blind users to find audio output modes by touch.
For devices with audio output:
Hardware must allow connection of assistive technologies (alternative keyboards, pointing devices, switches, etc.) either directly or through the platform. Standard connection points should not be blocked by the device's design.
Chapter 10 applies to documents that are not web pages but are provided through software or websites. This includes:
Chapter 10 adapts WCAG 2.1 Level A and AA success criteria for the document context. While web pages are inherently dynamic and interactive, documents are often more static, so some requirements are adapted accordingly.
Documents must use proper structural markup:
All images, charts, diagrams, and non-text elements must have text alternatives describing their content and purpose. Decorative images should be marked as such.
Text must meet minimum contrast ratios (4.5:1 for normal text). Information should not be conveyed by color alone—use text labels, patterns, or other indicators in addition to color.
Fillable forms (like PDF forms) must have:
PDFs are the most common non-web document format. To make PDFs accessible:
EN 301 549 is comprehensive, but not every requirement applies to every product. Here's how to determine applicability:
Look at what your ICT actually does. Requirements only apply if the feature exists:
Some requirements have specific exceptions or alternate conformance paths. Read the "where ICT..." clauses carefully—they define exactly when requirements apply.
If you have a novel technology not clearly covered by specific technical requirements, evaluate against the functional performance statements in Chapter 4. Can users with various disabilities achieve the outcomes described?
Use automated tools to catch common issues:
Remember: automated tools catch only 25-30% of accessibility issues. They're a starting point, not the complete answer.
Essential manual tests include:
The gold standard is testing with real users who have disabilities:
When claiming conformance to EN 301 549, document:
Many organizations use VPAT (Voluntary Product Accessibility Template) or ACR (Accessibility Conformance Report) formats to document EN 301 549 conformance in a standardized way.
Is EN 301 549 legally required?
EN 301 549 itself is a voluntary standard. However, EU legislation (the Web Accessibility Directive and the European Accessibility Act) reference it as the technical specification for compliance. If you must comply with those laws, you effectively must comply with EN 301 549.
Can I claim conformance to EN 301 549 if I only meet WCAG 2.1 AA?
If your ICT is purely web content with no other features, and you meet WCAG 2.1 Level AA, you essentially meet the Chapter 9 requirements of EN 301 549. However, full EN 301 549 conformance requires meeting all applicable requirements from all chapters, not just Chapter 9.
Do I need to buy the standard to comply?
The full EN 301 549 document is freely available for download from the ETSI website. Unlike some standards, you don't need to purchase it. For web content specifically, you can also reference the free WCAG 2.1 documentation from W3C.
What's the difference between EN 301 549 and WCAG?
WCAG focuses solely on web content. EN 301 549 incorporates WCAG 2.1 for web content (Chapter 9) but also covers non-web software, hardware, documents, telecommunications, video, and more. Think of EN 301 549 as "WCAG plus everything else."
Which version should I use?
Use the most recent harmonized version, currently V3.2.1 (2021). This is the version referenced by EU legislation. Older versions are superseded, though products developed under older versions may have some transitional recognition.
Our product is a mobile app. Which chapters apply?
Mobile apps are covered by Chapter 11 (Software). If the app has specific features like video playback or voice communication, relevant portions of Chapters 6-7 may also apply. If the app includes in-app documentation, Chapter 12 applies. Basically, identify what your app does and apply the relevant chapters.
We make a hardware device with embedded software. How do we comply?
You need to address both hardware requirements (Chapter 8) and software requirements (Chapter 11). Additionally, Chapter 5 (generic requirements) applies. If there are physical controls, ensure they meet tactile, visual, and operational requirements. If there's a screen and software UI, ensure it's accessible per Chapter 11.
Can we claim "partial conformance"?
Yes, you can claim partial conformance and document known issues. This is better than claiming full conformance falsely or claiming non-conformance when you've made significant progress. Be transparent about what works and what doesn't.
Do we need to make legacy products compliant?
It depends on the applicable legislation. Under the EAA, existing products have until June 28, 2030 to comply. Under the Web Accessibility Directive, public sector websites and apps should already be compliant. Check the specific legal requirements that apply to your situation.
We use third-party components. Are we responsible for their accessibility?
Generally, yes. If you integrate third-party code or components into your product, you're responsible for the overall accessibility of your product. Choose accessible third-party components, and if they're not accessible, either remediate them or find alternatives. Document any third-party limitations in your accessibility statement.
How do we test software accessibility (Chapter 11)?
Use platform-specific accessibility testing tools: Accessibility Insights for Windows, Accessibility Inspector for macOS/iOS, Accessibility Scanner for Android. Test with actual assistive technologies on each target platform. Verify that your UI properly exposes information through platform accessibility APIs.
What if our custom UI framework doesn't support accessibility?
You'll need to add accessibility support. This typically means implementing platform accessibility API support in your framework. Consider whether you really need a custom framework—native or established frameworks (React, Flutter, Qt, etc.) have better accessibility support. If you must use custom UI, budget time for accessibility implementation; it's not trivial.
Are game UIs covered by EN 301 549?
If a game is subject to the EAA or Web Accessibility Directive (e.g., a publicly funded educational game), yes. At minimum, menus, settings, and non-gameplay UI should be accessible. Gameplay itself is more complex—apply functional performance criteria and ensure players with disabilities can meaningfully participate to the extent feasible.
How do we make a PDF accessible if we only have a scanned image?
Run OCR (Optical Character Recognition) to convert the image to text, then properly tag the resulting PDF. For complex layouts or poor scan quality, you may need to manually correct OCR errors and tag structure. Alternatively, consider whether the content could be provided as HTML instead of PDF.
