The European Accessibility Act (EAA) is the law. EN 301 549 is the technical standard that sits behind it. When a regulator checks whether your mobile app is compliant, they check it against EN 301 549, specifically Chapter 11, the section that governs software.
Most companies have heard of the Web Content Accessibility Guidelines (WCAG). Far fewer have heard of EN 301 549. And almost nobody is talking about Chapter 11, which contains the requirements that actually apply to mobile apps.
This matters because a WCAG audit does not cover what EN 301 549 Chapter 11 requires. If your compliance programme is based on WCAG alone, you have a gap.
This post explains what EN 301 549 Chapter 11 requires for mobile apps, in plain English, for anyone responsible for compliance. No code. No jargon without explanation. If you have been handed responsibility for EAA compliance and need to understand what your mobile app is actually measured against, this is the reference.
What is EN 301 549?
EN 301 549 is the harmonised European standard for accessibility requirements for information and communication technology (ICT) 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.
The standard covers the full ICT ecosystem. Hardware, software, documentation, support services. If a company makes or sells technology in the EU, EN 301 549 defines what "accessible" means for their product.
The relationship to the EAA is direct. The EAA references EN 301 549 as the "presumed means of conformance." Meet EN 301 549, and you have a legal presumption of compliance with the EAA. Miss it, and you carry the burden of proving your product is accessible some other way. In practice, this means EN 301 549 is the standard your product will be measured against.
For mobile apps, the relevant section is Chapter 11, titled "Software." Chapter 11 applies to all "non-web software that provides a user interface." This explicitly includes native iOS apps, native Android apps, and cross-platform apps built with frameworks like React Native or Flutter.
There is a definitive list of which requirements apply to mobile apps. It lives in Annex A, Table A.2. This table maps every requirement in the standard to the product types it covers. If you need to know exactly what your mobile app must meet, Table A.2 is where you start.
Why WCAG Is Not Enough for Mobile Apps
This is the most important section in this post. Most companies approach mobile accessibility by running a WCAG audit. For mobile apps, that is insufficient. Here is why.
WCAG was written for the web browser. In a browser, the "user agent" (the browser itself) handles most of the work of making content accessible to assistive technologies like screen readers. The web developer writes HTML with the right semantics, and the browser translates that into something a screen reader can use.
In a native mobile app, there is no browser. The app itself is the software. It takes on responsibilities that web developers never have to consider. It must communicate directly with the platform's accessibility services, VoiceOver on iOS, TalkBack on Android, using the platform's own APIs.
The European Commission's own position makes this explicit: "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."
EN 301 549 Chapter 11 incorporates 44 WCAG 2.1 Level AA success criteria, adapted for the software context. But it adds approximately 64 additional requirements that WCAG does not cover.
Here is what WCAG covers compared to what EN 301 549 Chapter 11 requires:
Screen reader integration. WCAG handles this implicitly through HTML and ARIA. EN 301 549 requires explicit integration with platform accessibility APIs (Clause 11.5). Your app must use UIAccessibility on iOS and AccessibilityNodeInfo on Android. Custom rendering that bypasses these APIs fails the standard.
System font size support. WCAG does not require it. EN 301 549 makes it mandatory (Clause 11.7). Your app must honour the user's platform-level font size setting. This is unconditional.
Biometric alternatives. WCAG does not cover biometrics. EN 301 549 requires a non-biometric alternative for any biometric authentication (Clause 5.3). Face ID and fingerprint cannot be the only way to log in.
Platform preferences. WCAG does not require apps to honour operating system settings. EN 301 549 requires your app to respect the user's font size, colour, contrast, and focus cursor preferences (Clause 11.7).
Documentation accessibility. WCAG does not cover it. EN 301 549 requires that product documentation describes accessibility features and is itself accessible (Chapter 12).
Support service accessibility. WCAG does not cover it. EN 301 549 requires that support channels are accessible to users with disabilities (Chapter 12).
The bottom line: "WCAG compliant" does not mean "EN 301 549 compliant." A WCAG-only audit misses the interoperability suite, platform preferences, biometrics, documentation, and support requirements.
The Five Requirements Most Mobile Apps Fail
These are the five EN 301 549 Chapter 11 requirements that are most commonly missed. They are the ones a compliance officer needs to know about because they represent the most frequent gaps between what companies think they have covered and what the standard actually requires.
1. Platform accessibility API usage (Clause 11.5.2)
This is the single most consequential mobile-specific requirement. Your app must use the platform's documented accessibility APIs: UIAccessibility on iOS, AccessibilityNodeInfo on Android. Custom rendering engines that bypass these APIs fail the standard, even if the content looks accessible on screen.
What this means in practice: if your development team has built custom UI components using a graphics engine or canvas-based rendering, those components are invisible to screen readers unless they have been explicitly wired up to the platform's accessibility layer. This is not about visual design. It is about whether the app communicates its structure to assistive technology at all.
The standard also requires that every UI element exposes its role, state, name, description, and boundary (position and size) programmatically (Clause 11.5.2.5). A custom slider that looks like a slider but does not announce its current value to a screen reader fails this requirement.
How this fails. A Flutter app renders its interface through a custom graphics engine. Unless every element has been annotated with the Semantics widget, a screen reader user sees nothing. The app could look beautiful and be completely inaccessible. Similarly, a React Native app with a custom toggle that is announced as "button" rather than "switch, on" provides no usable information to a blind user.
2. Respecting user preferences (Clause 11.7)
Apps must honour platform-level settings for font size, colour, and contrast. This requirement is unconditional. Every app, regardless of what it does, must respect these settings.
This is not a niche concern. More than a third of mobile users adjust their font size. If your app ignores this setting, it is failing a requirement that affects a significant portion of your user base.
How this fails. An app uses hard-coded 14-point text throughout its interface. A user who has set their phone to large text for readability opens the app and sees no change. The text stays small because the app ignores the operating system's Dynamic Type setting on iOS or font scale on Android.
3. Biometric alternatives (Clause 5.3)
Biometric authentication, Face ID, fingerprint scanning, iris recognition, cannot be the sole means of identification or control. A non-biometric alternative must always be available.
This requirement exists because biometrics are not universally usable. A user with a facial difference may not be able to use Face ID. A user with a limb difference may not be able to use a fingerprint scanner. The standard requires that these users have another way in.
How this fails. A banking app requires Face ID to log in. There is no PIN fallback, no password option. A user with a facial difference cannot access their own bank account.
4. Focus order and management (Clause 11.2.4.3)
Navigation order must be logical and predictable. When a dialog or modal appears, focus must move into it. When it closes, focus must return to where it was. This is how screen reader users understand what is happening on screen. Without correct focus management, the user's mental model of the interface breaks down.
This also applies to status messages (Clause 11.4.1.3). When something changes on screen, like a success notification or an error toast, it must be announced to screen readers without moving focus away from what the user was doing. A toast that appears visually but is not exposed to the accessibility tree is invisible to a screen reader user.
How this fails. A confirmation dialog appears after a user taps a button. But focus stays on the button behind the dialog. A screen reader user does not know the dialog is there. They tap the button again, potentially triggering a duplicate action. Or: a "payment successful" toast appears for three seconds and vanishes. A sighted user sees it. A screen reader user hears nothing.
5. Error identification (Clause 11.3.3.1)
When a user makes an error in a form, the error must be identified in text and announced by the screen reader. A red border or colour change alone is not sufficient. The error message must be in text, and it must be programmatically associated with the field that has the error.
How this fails. A registration form turns field borders red when the user submits invalid data. There is no text message explaining what went wrong. A blind user using a screen reader hears nothing. A colour-blind user cannot distinguish the red border from the normal state. Both users are stuck.
These five requirements are not obscure edge cases. They represent the core of what makes a mobile app usable with assistive technology. And they are the requirements that a WCAG-only audit consistently misses, because WCAG was never designed to cover them.
What Is Changing in EN 301 549
EN 301 549 v4.1.1 is currently under development and is expected to be published in 2026. This update will incorporate WCAG 2.2 Level AA, which adds several new requirements relevant to mobile apps.
The most significant additions for mobile:
- Dragging movements (Clause 11.2.5.7). Any interaction that requires a dragging motion must have a single-pointer alternative. If your app uses drag-to-reorder lists or swipe-to-dismiss cards, there must be another way to achieve the same result.
- Minimum target size (Clause 11.2.5.8). Interactive elements must be at least 24 by 24 CSS pixels. Small tap targets are a common accessibility barrier on mobile, particularly for users with motor impairments.
- Accessible authentication (Clause 11.3.3.8). Cognitive function tests, such as remembering a password or solving a CAPTCHA, cannot be the sole login method. An alternative like passkeys, email links, or biometrics (with its own non-biometric fallback) must exist.
- Redundant entry (Clause 11.3.3.7). Do not ask users to re-enter information they have already provided in the same session.
The update will also reinstate two requirements that were voided for mobile apps in v3.2.1. Screen titles (Clause 11.2.4.2) and consistent identification (Clause 11.3.2.4) will apply to mobile apps under v4.1.1. This means every screen in your app will need a descriptive, programmatically accessible title.
The practical implication: v4.1.1 adds requirements. It does not remove any. Companies that meet v3.2.1 now will need to address the new criteria when v4.1.1 is adopted, but they will not need to redo existing work. Starting with v3.2.1 is the right move.
What to Do About It
If you are responsible for compliance at a company with a mobile app sold to EU consumers, here is what this means for you.
First, understand the gap. A WCAG audit is not an EN 301 549 audit. If your last accessibility assessment only covered WCAG success criteria, you have not assessed the interoperability requirements (Clause 11.5), user preferences (Clause 11.7), biometric alternatives (Clause 5.3), or documentation and support requirements (Chapter 12). These are not optional. They are part of the standard your app will be measured against.
Second, check the five requirements above against your app. These are the ones most commonly failed. Ask your development team: does the app use the platform's accessibility APIs? Does it honour the system font size setting? Is there a non-biometric login option? Does focus move correctly when dialogs appear? Are error messages in text? If the answer to any of these is "I don't know," that is the gap.
Third, confirm you are in scope. If your company has a mobile app available to EU consumers, you are almost certainly in scope for the EAA. The microenterprise exemption applies only to services provided by businesses with fewer than 10 employees and less than EUR 2 million in annual turnover. If your organisation is above either threshold, the exemption does not apply.
Fourth, start with EN 301 549. EN 301 549 conformance is the presumed path to EAA compliance. Meeting it gives you legal standing. Not meeting it means you carry the burden of proving your product is accessible through other means. For most companies, the standard is the path of least resistance and greatest legal certainty.
Fifth, produce an accessibility statement. The EAA requires a public accessibility statement for every digital product in scope. This statement must describe your conformance status against EN 301 549, list any non-accessible content, explain what alternatives you provide, and include contact details for accessibility feedback. It is not optional. It is a mandatory part of compliance, and it must reflect your actual audit results.
Learn how Auditsu generates your accessibility statement from real audit data.EAA enforcement began 28 June 2025. No company has been fined under the EAA yet, but enforcement activity is underway in multiple member states. In France, disability organisations have filed injunctions against major retailers. In Germany, private actors have sent warning letters under competition law. The time to act is before a regulator asks the question, not after.
Auditsu audits mobile apps against EN 301 549. Start your first audit.