EN 301 549: The Accessibility Standard Behind the EAA
EN 301 549 is the technical standard that the European Accessibility Act enforces. It covers websites, mobile apps, hardware, and services. For mobile apps, Clause 11 sets requirements that go beyond WCAG and that most companies have not assessed.
What is EN 301 549?
EN 301 549 is the European standard for accessibility in technology products and services. It was developed by three European standards bodies (ETSI, CEN, and CENELEC). The current version is v3.2.1, published in March 2021.
It is the legal standard that the European Accessibility Act (EAA) enforces. When regulators check whether a product meets the law, they check it against EN 301 549. WCAG is a set of guidelines. EN 301 549 is the law.
Key facts:
- Covers the full technology ecosystem: software, hardware, biometrics, documentation, and support services.
- Uses WCAG 2.1 Level AA as its foundation but adds roughly 64 requirements beyond WCAG.
- For mobile apps, Clause 11 (Software) is the governing section.
- Self-scoping: each requirement has a condition, so it only applies when your product has the feature described. If your app does not use biometrics, the biometrics rules do not apply.
Software
Native mobile apps (iOS and Android), desktop applications, and system software.
Hardware
Self-service terminals, ATMs, ticketing machines, and consumer devices.
Biometrics
Face recognition, fingerprint, iris, and voice identification. Alternatives always required.
Customer Support
Documentation must describe accessibility features. Support channels must be accessible.
EN 301 549 vs WCAG
WCAG was written for the browser. In a browser, the browser itself handles most of the work needed to connect with screen readers and other assistive tools. In a native mobile app, the app is the software. It takes on responsibilities that web developers never have to think about.
EN 301 549 uses WCAG 2.1 AA as its starting point, but adds roughly 64 requirements on top. These cover areas WCAG was never designed to address: how apps work with screen readers, how they follow system settings, biometric alternatives, documentation, and support services.
The European Commission's position: "Table A.2 (covering mobile applications) is not covered by WCAG at all, even though it makes use of requirements from WCAG. This is because the WCAG does not actually apply to mobile applications."
Comparison:
| Area | WCAG 2.1 AA | EN 301 549 v3.2.1 |
|---|---|---|
| Primary scope | Web content and documents | All ICT: hardware, software, and apps |
| Biometrics | Not covered | Alternatives always required (Clause 5.3) |
| Mobile focus | Implicit (general rules) | Explicit (Clause 11 governs non-web software) |
| OS preferences | Not required | Apps must follow platform font size, colour, contrast, and focus settings (Clause 11.7) |
| AT interoperability | Generic ("programmatically determinable") | Must use the platform's own accessibility APIs (Clause 11.5) |
| Documentation | Not required | Must describe accessibility features (Clause 12) |
| Legal status | Guidelines (voluntary until adopted) | The law (required by the EAA) |
Many companies believe "We are WCAG compliant, so we are safe in Europe." This is not true. A WCAG-only audit misses the entire Clause 11.5 interoperability suite, Clause 11.7 platform preferences, biometric alternatives, documentation requirements, and all communication and media clauses.
Clause 11: Why Mobile Apps Need Their Own Rules
Clause 11 applies to all non-web software that has a user interface. This includes native iOS and Android apps, desktop apps, and system software.
How Clause 11 is structured:
- Clauses 11.1 to 11.4 adapt 44 WCAG criteria to work in native apps instead of browsers.
- Clause 11.5 adds 17 requirements for assistive technology interoperability. These have no WCAG equivalent at all.
- Clause 11.6 says apps must not disable or interfere with platform accessibility features like screen readers.
- Clause 11.7 requires apps to follow platform preferences (font size, colour, contrast). This applies to every app with no exceptions.
- Clause 11.8 covers authoring tools (apps that create content).
The five most critical mobile-specific requirements:
These are the requirements most commonly failed and most commonly missed by WCAG-only audits.
Clause 11.5.2.3
Use of platform accessibility services
This is the single most important mobile-specific requirement. Apps must use the platform's built-in accessibility tools (UIAccessibility on iOS, AccessibilityNodeInfo on Android). If your app draws its own interface and skips these tools, it fails, even if the content looks accessible on screen.
Example failure: A Flutter or game engine app draws its interface through a graphics layer without providing any accessibility information. A React Native app with a custom slider that shows up as a generic "view" to screen readers.
Clause 11.7
User preferences
Apps must follow the user's system-level settings for font size, font type, colour, contrast, and focus cursor. This is unconditional. It applies to every app. Research suggests 35 to 37% of mobile users change their default font size.
Example failure: An app that ignores iOS Dynamic Type and shows all text at a fixed 14pt size. An app that does not support dark mode.
Clause 5.3
Biometric alternatives
If your app uses biometrics (Face ID, fingerprint, iris, or voice), it cannot be the only way to identify or authenticate the user. A non-biometric option like a PIN or password must always be available.
Example failure: A banking app that requires Face ID with no PIN fallback. An app that uses fingerprint as the only way to authorise a payment.
Clause 11.6.2
No disruption of accessibility features
Apps must not disable, override, or get in the way of platform accessibility features like screen readers, magnifiers, high-contrast modes, or captioning.
Example failure: A game that captures all touch events, including VoiceOver gestures. An app that overrides the system back gesture, breaking TalkBack navigation.
Clause 11.5.2.5
Object information
Every interactive element must tell assistive tools its role, state, position, size, name, and description. The "position and size" part is an EN 301 549 addition not found in WCAG.
Example failure: A custom progress bar that does not report its name, role, or current value. Custom controls drawn with Canvas that have no accessibility properties.
Automated web scanning tools cannot test native apps. Most companies that believe they are compliant have only tested their website, not their mobile apps. This is where the biggest gaps are.
Enforcement is Active
The EAA deadline of June 28, 2025 has passed. Enforcement is live across all 27 EU member states. Products that do not meet EN 301 549 are now subject to action.
- Market Surveillance Authorities in each country are conducting checks.
- In France, disability organisations filed injunctions in November 2025, targeting Auchan, Carrefour, E.Leclerc, and Picard.
- In the Netherlands, the ACM (Authority for Consumers and Markets) began audits in October 2025.
- Fines vary by country. In Spain, they can reach up to EUR 1M. The most serious penalty is market exclusion, meaning an app is removed from the EU market entirely.
- A small number of businesses are exempt: those with fewer than 10 employees and turnover under EUR 2M. This exemption only applies to services, not products.
For a full breakdown of enforcement and penalties, see the EAA compliance page.
How AUDITSU Helps
AUDITSU is a platform where companies measure, manage, and declare their EN 301 549 conformity. All in one place.
The workflow:
- Register your app (iOS, Android, or both).
- Create surfaces and screens to define what needs auditing.
- Run a guided audit against EN 301 549. The Audit Toolkit creates structured test actions with built-in guidance for each requirement. No expertise needed.
- Failed items become tickets in the Ticket Manager. Assign them to team members with severity levels and due dates.
- When tickets are resolved, your audit results update automatically.
- Generate an accessibility statement from your audit data using the Statement Generator.
No code access or accessibility expertise required.
FAQ
Q: Is EN 301 549 the same as WCAG?
A: No. EN 301 549 uses WCAG 2.1 AA as its foundation but adds requirements for non-web software, hardware, biometrics, documentation, and support services. For mobile apps, roughly 64 requirements go beyond WCAG.
Q: Does EN 301 549 apply to mobile apps?
A: Yes. Clause 11 specifically covers non-web software, including native iOS and Android apps. Annex A Table A.2 is the definitive list of requirements for mobile applications.
Q: We passed a WCAG audit. Are we compliant?
A: Not necessarily. WCAG audits cover web content. EN 301 549 requires additional checks for mobile apps under Clause 11, including assistive technology interoperability (11.5), platform preferences (11.7), biometric alternatives (5.3), and documentation (Clause 12). A WCAG-only audit misses these entirely.
Q: Do we need accessibility expertise to audit against EN 301 549?
A: No. AUDITSU's Audit Toolkit gives you structured test actions with built-in guidance for each requirement. No code access needed.
Q: What version of EN 301 549 applies?
A: v3.2.1 is the current version. v4.1.1 is under development and will include WCAG 2.2 Level AA.
Q: We use React Native or Flutter. Does Clause 11 apply?
A: Yes. Cross-platform frameworks compile to or bridge to native components. They are non-web software and Clause 11 applies. The key requirement is 11.5.2.3: your framework must correctly pass accessibility information through the platform's native APIs.
Audit Your App Against EN 301 549
AUDITSU's Audit Toolkit walks you through EN 301 549 compliance for your iOS and Android apps. One surface, one requirement at a time. No expertise needed.