For mobile apps, the clause of EN 301 549 you work from is Chapter 11, Software. Clause 11.0 lists what the chapter covers, and mobile applications are the last of five bullets, alongside platform software, authoring tools and assistive technology (ETSI EN 301 549 V3.2.1). Chapter 11 restates the WCAG 2.1 Level A and AA success criteria in software language, marks a handful of them Void because they only make sense for sets of web pages, and then adds requirements WCAG has no equivalent for: use of the platform accessibility services, no disruption of platform accessibility features, and respect for the user's system-level preferences. The scoping line at the top of the chapter is the one that decides most arguments. Clauses 11.1 to 11.5 apply to software that is not a web page and is not embedded in one; anything in your app that is a web page falls under Chapter 9 instead. So a native screen and the WebView next to it are governed by different chapters of the same standard. Below: which clauses apply to EN 301 549 mobile apps, which WCAG criteria drop out, what Chapter 11 adds, and what changes in V4.
What does Chapter 11 of EN 301 549 cover?
Chapter 11 is the software chapter, not the mobile chapter. There is no clause called "mobile apps". A phone app is covered because it is software that provides a user interface, and the requirements are written in that general form.
The chapter has eight parts. Clauses 11.1 to 11.4 mirror the WCAG structure of perceivable, operable, understandable and robust, renumbered with an 11. prefix, so WCAG 2.1 Success Criterion 2.4.7 Focus Visible becomes clause 11.2.4.7. After that come interoperability with assistive technology (11.5), platform accessibility features (11.6) and user preferences (11.7). Clause 11.8 applies only if your app is an authoring tool.
The standard says clauses 11.1 to 11.5 are intended to harmonize with the W3C WCAG2ICT Working Group Note, which works out what a WCAG criterion written for "web pages" means when there is no page. WCAG2ICT was updated on 11 December 2025 and covers WCAG 2.0, 2.1 and 2.2 at Level A and AA (W3C). If a Chapter 11 clause reads oddly, that Note usually explains the substitution behind it.
Which EN 301 549 clauses apply to a mobile app?
Annex A Table A.2 is the list. It is titled "Mobile Applications" and covers apps that provide a user interface, including content such as documents and forms the app carries or serves (ETSI EN 301 549 V3.2.1). It runs to 162 numbered rows, and they are not all Chapter 11:
| Rows | Chapter | What it covers |
|---|---|---|
| 1–10 | 5 | Generic ICT: activation of accessibility features, biometrics, operable parts |
| 11–28 | 6 | Two-way voice and real-time text |
| 29–38 | 7 | Captions and audio description in video |
| 39–83 | 10 | Non-web documents the app carries or generates |
| 84–157 | 11 | The software requirements |
| 158–162 | 12 | Product documentation and support services |
Almost every row is marked "C" for conditional, with the trigger spelled out next to it. Row 8 applies only where the ICT has a key repeat function that cannot be turned off; rows 153 to 157 only where the app is an authoring tool. So you do not answer 162 requirements. You answer the ones whose pre-condition is true of your app, and you should be able to say why each of the others is not.
The absence worth noticing is Chapter 9. Table A.2 has no Chapter 9 rows at all, which is the scoping rule from 11.0 showing up in the Annex.
When does Chapter 9 apply to an app instead of Chapter 11?
When the thing on screen is a web page. Clause 9 covers software that is a web page and software embedded in a web page that is used in rendering it; clauses 11.1 to 11.5 cover software that is neither (ETSI EN 301 549 V3.2.1).
In a hybrid app this cuts straight through the product. The native tab bar, the login screen built in SwiftUI or Jetpack Compose, the settings list: Chapter 11. The help centre and the checkout you render in a WKWebView or a Custom Tab: Chapter 9, which is WCAG 2.1 AA renumbered with a 9. prefix and reported against Table A.1.
Which means a conformance claim has to say which surfaces it covers. "The app meets EN 301 549" is ambiguous the moment there is a WebView in it, and the testing splits along the same line: web surfaces can be scanned with ordinary web tooling, native ones cannot.
Which WCAG criteria are Void for software?
Eleven clause numbers in Chapter 11 are marked Void. Five, 11.1.4.6 to 11.1.4.9 and 11.2.1.3, are placeholders keeping the numbering aligned across chapters 9, 10 and 11; the same numbers are Void in the web chapter, because those WCAG criteria are Level AAA. The other six carry a note explaining why the requirement makes no sense for software. These are not exemptions you argue for. The requirement does not exist.
The ones people notice first:
- 11.2.4.1, Bypass blocks. The note says the web requirement applies to repeated blocks across a set of web pages, not to one software program. Skip links have no home here, though 11.2.4.6 Headings and labels still applies.
- 11.2.4.2, Page titled, and 11.2.4.5, Multiple ways. Void for the same reason: both are written about sets of pages.
- 11.3.2.3 and 11.3.2.4, Consistent navigation and Consistent identification. Void, because a "set of software programs" in the sense of a set of web pages is, in the standard's words, extremely rare.
- 11.3.1.2, Language of parts. The note is blunt: applying it to software would mean marking up all text in all locations within the software, which would be impossible.
Language of software survives as 11.3.1.1, and on a phone that usually resolves to using the platform locale setting rather than hard-coding a language.
What does Chapter 11 require that WCAG does not?
This is the part that catches teams who tested with a WCAG checklist and assumed they were done. Three areas have no WCAG counterpart.
Clause 11.5.2, accessibility services. Seventeen numbered requirements, of which Table A.2 lists fourteen as rows 137 to 150; the rest are duties on the platform or on assistive technology itself. Clause 11.5.2.3 says software that provides a user interface shall use the applicable documented platform accessibility services. The rest name what must be exposed through them: role, state, boundary, name and description (11.5.2.5); label relationships (11.5.2.8); parent-child relationships (11.5.2.9); the list of available actions on an element (11.5.2.11); and change notification (11.5.2.15).
If I had to pick one clause to read before shipping a release, it would be 11.5.2.3. Most serious native accessibility bugs I see come from the same place: a custom control drawn onto a canvas or a bare View, styled to look like a button, that never registered anything with UIAccessibility or the Android accessibility node API. On screen it is a button. To VoiceOver it is nothing, and no amount of colour contrast work fixes that.
Clause 11.6.2, no disruption of accessibility features. Software shall not disrupt documented platform accessibility features unless the user asks it to. Overriding the system font scale, suppressing reduce-motion, or capturing gestures that belong to the screen reader all sit here.
Clause 11.7, user preferences. Where software is not isolated from its platform, its interface shall follow the platform settings for units of measurement, colour, contrast, font type, font size and focus cursor, unless the user overrides them. That is row 152, and it fails whenever an app hard-codes 14pt and ignores Dynamic Type or the Android font-size setting.
What changes for mobile apps in EN 301 549 V4?
The web baseline moves to WCAG 2.2, and Chapter 11 moves with it. The final draft of V4.1.0, dated June 2026, adds software versions of the new WCAG 2.2 criteria: 11.2.4.11 Focus not obscured (minimum), 11.2.5.7 Dragging movements, 11.2.5.8 Target size (minimum), 11.3.3.7 Redundant entry and 11.3.3.8 Accessible authentication (minimum). Consistent help arrives as 11.3.2.6 and is marked Void for software.
Two land hardest on phones. Target size gives a floor for tap targets, and dragging movements requires a single-pointer alternative to any drag interaction, which is real work for reorderable lists and swipe-to-action rows.
Version matters for what you can claim. V3.2.1 is cited in the Official Journal today through Commission Implementing Decision (EU) 2021/1339, so it carries the presumption of conformity for the Web Accessibility Directive. V4.1.0 is a final draft, not yet cited. Building against it early is sensible engineering; claiming its conformance as a legal presumption is not something the Official Journal supports yet.
Does the EAA require this for consumer apps?
The European Accessibility Act names mobile apps directly. Annex I, Section III, point (c) requires "making websites, including the related online applications, and mobile device-based services, including mobile applications, accessible in a consistent and adequate way by making them perceivable, operable, understandable and robust" (Directive (EU) 2019/882). Article 2(2) repeats "mobile device-based services including mobile applications" across the services in scope.
The directive states outcomes and names no clause numbers. EN 301 549 is the technical answer regulators and buyers recognise, which is why an app in EAA scope gets tested against Chapter 11 though the law never mentions it. One difference from the public sector case: Annex A's presumption of conformity is written for Directive (EU) 2016/2102, not for the EAA, where no harmonised standard has been cited in the Official Journal yet.
How do you test an app against Chapter 11?
Start on the platform, not with a scanner. Both platforms ship an inspector that reads the same accessibility tree the screen reader reads: Accessibility Inspector in Xcode, Accessibility Scanner on Android. Walk a real task with VoiceOver or TalkBack and listen for controls that announce as nothing, or as "button" with no name. That single pass finds most 11.5.2.5 and 11.4.1.2 failures faster than any document review.
Then check the clauses that need a settings change rather than a screen read. Turn the system font up to its largest setting for 11.7. Rotate the device for 11.1.3.4 Orientation, which requires that content not be locked to one display orientation unless that is essential. Turn on reduce motion and confirm nothing is disrupted, for 11.6.2.
Our scanner will not do this part for you. It crawls web pages, including the web surfaces inside a hybrid app, and returns each violation with the CSS selector that caused it. It cannot open your iOS binary. Automated testing identifies roughly 30% to 57% of accessibility issues by Deque's measurement across more than 2,000 audits (Deque), so the rest is a person with a screen reader either way. Split the work honestly: automation on the web surfaces, platform tooling and manual testing on the native ones.
Frequently asked questions
Does EN 301 549 apply to mobile apps?
Yes. Clause 11.0 names mobile applications as one of the categories Chapter 11 covers, and Annex A Table A.2 is the requirement list for mobile applications, mapping 162 rows to the essential requirements of the Web Accessibility Directive.
Is Chapter 11 of EN 301 549 the same as WCAG?
No. Clauses 11.1 to 11.4 restate the WCAG 2.1 Level A and AA criteria in software terms, but six are Void because the web requirement has no software equivalent, and clauses 11.5 to 11.7 add requirements WCAG has none for: use of platform accessibility services, no disruption of platform accessibility features, and following the user's platform preferences.
Which chapter applies to a WebView inside my app?
Chapter 9. Clauses 11.1 to 11.5 apply to software that is not a web page, so web content rendered inside an app is assessed under Chapter 9 and reported against Annex A Table A.1. A hybrid app is usually assessed under both chapters.
Which version of EN 301 549 should a mobile app be tested against?
V3.2.1 today. It is cited in the Official Journal through Commission Implementing Decision (EU) 2021/1339, so it carries the presumption of conformity. The V4.1.0 final draft of June 2026 aligns Chapter 11 with WCAG 2.2 and is worth building against, but it is not yet cited.
Can an automated tool prove a mobile app conforms to Chapter 11?
No. Automated tools identify between about 30% and 57% of issues, and clauses like 11.5.2.11 List of available actions or 11.6.2 No disruption of accessibility features need a person testing with the platform's screen reader and settings.
Start with the surfaces you can measure
If your app has web content in it, that part is testable today, and it is where machine-detectable failures cluster. Run a free scan on the pages your WebViews load, fix what comes back with a selector attached, then spend your manual time on the native screens where a platform inspector and a screen reader are the only tools that work. Our EN 301 549 checklist has the clause list if you want it in front of you while you scope the audit.
Pavel Charkasau, founder, wcagc.com. Last updated 28 August 2026.
Sources
- EN 301 549 V3.2.1 (2021-03), ETSI — clause 11.0 scope and the five categories covered; the 11.1–11.5 scoping rule against clause 9; the Void clauses at 11.2.4.1, 11.2.4.2, 11.2.4.5, 11.3.1.2, 11.3.2.3 and 11.3.2.4; clauses 11.5.2.3 to 11.5.2.17, 11.6.2 and 11.7; Annex A Table A.2 for mobile applications. Accessed 28 August 2026.
- Final draft EN 301 549 V4.1.0 (2026-06), ETSI — the WCAG 2.2 additions to Chapter 11: 11.2.4.11, 11.2.5.7, 11.2.5.8, 11.3.3.7, 11.3.3.8, and 11.3.2.6 marked Void. Accessed 28 August 2026.
- WCAG2ICT, W3C Group Note, 11 December 2025 — guidance on applying WCAG 2.0, 2.1 and 2.2 Level A and AA to non-web software, and the substitutions behind the Chapter 11 wording. Accessed 28 August 2026.
- Directive (EU) 2019/882, EUR-Lex — the European Accessibility Act: Annex I Section III point (c) on websites and mobile applications; Article 2(2) on mobile device-based services. Accessed 28 August 2026.
- Commission Implementing Decision (EU) 2021/1339, EUR-Lex — cites EN 301 549 V3.2.1 in the Official Journal for Directive (EU) 2016/2102. Accessed 28 August 2026.
- Automated testing identifies 57% of accessibility issues, Deque — automated coverage measured across more than 2,000 audits. Accessed 28 August 2026.