Mobile app accessibility under EN 301 549 v4.1.0

EN 301 549 v3.2.1 is the primary harmonised European standard in the European Union for accessibility of ICT products and services. It is aligned with WCAG 2.1 Level AA and applies to websites, mobile applications, non-web software, hardware, and electronic documents.

The standard has been referenced in the Official Journal of the European Union since 2021 and can be used to demonstrate compliance with the European Accessibility Act (EAA) through the presumption of conformity mechanism for harmonised standards. This means that organisations applying the standard are considered to meet the legal accessibility requirements.

A new version of the standard, EN 301 549 v4.1.0, is currently in the approval process at European Telecommunications Standards Institute (ETSI). This version updates Clauses 9, 10 and 11 to align with the WCAG 2.2 and incorporates concepts and interpretations from the WCAG2ICT W3C Group Note dated 11 December 2025. Once this version is referenced in the Official Journal of the European Union, it will replace the current version v3.2.1, likely with an overlap period, as was the case when EN 301 549 v3.2.1 replaced v2.1.2.

What does it mean for the mobile apps?

EN 301 549 v4.1.0 introduces a combination of conceptual clarifications and changes in both the definitions and Clause 11 that directly affect how mobile apps are assessed for accessibility. Some success criteria that were previously out of scope for non-web software now apply, and a number of WCAG 2.2 success criteria have been added. This version of EN standard is much more closely aligned with the WCAG2ICT Group Note, with many clarifying notes harmonised between the two documents. This article focuses on these changes and explains what needs to be revised in a mobile accessibility testing approach to align with the updated EN standard.

Conceptual changes and clarifications

Probably the most significant conceptual change at a general level concerns web views. EN 301 549 v4.1.0 explicitly states:

When parts of non-web software, such as mobile apps, are implemented with web views, such a view is embedded in the app and thus does not meet the definition of web page. The clause 11 ‘Non-web software’ requirements are the appropriate requirements to be applied to these web views. There are no circumstances in which clause 9 requirements and the corresponding clause 11 requirements are both applicable. Where there is any doubt, clause 11 requirements have precedence.

This clarification removes long-standing ambiguity for mobile apps that embed web views. Embedded web views are treated as part of the non-web software and must be assessed against Clause 11. Clause 9 requirements for web content do not apply in parallel, and Clause 11 takes precedence whenever there is doubt.

EN 301 549 v4.1.0 also makes the applicability logic for success criteria explicit. For mobile accessibility testing, this means that a success criterion only applies when the condition described by the criterion actually occurs in the app. If a feature or interaction is not present, the criterion is satisfied by definition.

Another important conceptual change is the introduction of a clearer layer responsibility model. EN 301 549 v4.1.0 repeatedly emphasises that accessibility requirements apply across multiple layers, including the underlying layer (hardware and low-level software), platform software (for example operating systems and native default components), application software (for example mobile apps), and assistive technologies or accessibility services. Each layer is responsible only for the behaviour it controls.

Closely related to this is a terminology change throughout Clause 11, where references to “user agent” are systematically replaced with “user agent or other platform software”. This reflects the reality of non-web software environments, where the web-centric concept of a user agent is often not sufficient.

From a mobile perspective, these layers are not fixed roles. The same UI element can belong to different layers depending on how it is implemented. For example, a native iOS toggle that is used without modification is part of the platform software. The same toggle, when custom-styled or recreated in a framework such as React Native, becomes part of the application software. Responsibility for accessibility requirements follows the layer that controls the behaviour.

Success criteria that are no longer Void for mobile apps

11.2.4.2 Non-web software titled

(aligned with WCAG 2.2, 2.4.2 Page Titled, Level A)

Where ICT is, or includes, non-web software that provides a user interface, implemented on a platform that supports ‘Title’ attributes for windows or screens, the non-web software shall provide titles that describe the name, topic or purpose of each window or screen.

In a mobile context, a title may take multiple forms, such as a visible screen title, indicator text and/or an icon in a navigation bar, or other cues that help users identify their current location within the application. The goal of the title is to provide clear context about where the user is and what the current screen represents.

11.3.2.4 Consistent identification

(aligned with WCAG 2.2, 3.2.4 Consistent Identification, Level AA)

Where ICT is, or includes, non-web software, components that have the same functionality within the non-web software shall be identified consistently.

Within a mobile app, components that perform the same function should be recognisable as such across different screens and flows. Users should not need to relearn how to identify the same action when it appears in another context. In a mobile context, this is often visible in navigation elements, repeated actions, and common controls such as search, settings, close, back, or submit actions.

New success criteria introduced with WCAG 2.2

11.2.4.11 Focus Not Obscured (Minimum)

(aligned with WCAG 2.2, 2.4.11 Focus Not Obscured (Minimum), Level AA)

When a user interface component receives keyboard focus, the component is not entirely hidden by author-created content.

This applies when a component receives keyboard focus and becomes fully hidden by other content such as headers, overlays, or bottom sheets. Partial obstruction is acceptable, as long as users can still perceive where focus has moved. Content opened by the user may obscure the focused component if it can be revealed again without advancing keyboard focus.

11.2.5.7 Dragging movements

(aligned with WCAG 2.2, 2.5.7 Dragging movements, Level AA)

Where ICT is, or includes, non-web software, all functionality that uses a dragging movement for operation shall be operable by a single pointer without dragging, unless the dragging movement is essential or the functionality is determined by the user agent and not modified by the author.

In mobile apps, this applies to interactions that require users to press and hold, move, and then release to perform an action (for example, reordering items in a list). The same functionality must also be operable without dragging, using a single pointer action, unless dragging is essential. This criterion applies to functionality implemented in the app itself and does not apply to operating system interactions (for example, scrolling the screen) or assistive technologies (for example, navigation by touch).

11.2.5.8 Target Size (Minimum)

(aligned with WCAG 2.2, 2.5.8 Target Size (Minimum), Level AA)

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when…”
(spacing, equivalent controls, inline targets, user agent or other platform software control, or essential presentation apply).

This success criterion addresses the minimum size of interactive targets in mobile apps. Targets should be at least 24 by 24 platform-defined density-independent pixel measurements, such as points (pt) on iOS and macOS and density-independent pixels (dp) on Android, unless one of the defined exceptions applies. In practice, a target size of 24 by 24 may still be too small for touch-based mobile use. For improved usability, it is beneficial to follow Success Criterion 2.5.5 Target Size (Enhanced), which recommends target sizes of at least 44 by 44 points.

11.3.3.7 Redundant entry

(aligned with WCAG 2.2, 3.3.7 Redundant entry, Level A)

Information previously entered by or provided to the user that is required to be entered again in the same process shall be either auto-populated or available for the user to select, unless re-entering the information is essential.

This success criterion addresses situations where users are asked to provide the same information multiple times within a single flow in a mobile app. This commonly occurs in multi-step processes such as registration, onboarding, checkout, or account setup. Information that the app already has should not need to be re-entered manually unless re-entry is essential. This reduces unnecessary effort and cognitive load.

11.3.3.8 Accessible authentication (Minimum)

(aligned with WCAG 2.2, 3.3.8 Accessible authentication (Minimum), Level AA)

A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
Alternative: Another authentication method that does not rely on a cognitive function test.
Mechanism: A mechanism is available to assist the user in completing the cognitive function test.
Object Recognition: The cognitive function test is to recognize objects.
Personal Content: The cognitive function test is to identify non-text content the user provided to a website, non-web document, or software.

This success criterion addresses authentication flows in mobile apps that rely on cognitive effort. Authentication must not depend solely on remembering information or solving challenges unless an alternative method or assistance mechanism is available. This commonly affects login and verification flows and supports approaches such as password managers, copy and paste, biometrics, or other methods that reduce cognitive load while maintaining equivalent privacy for users of assistive technologies.

Success criteria that were edited or clarified

11.1.2.3 and 11.1.2.5 Audio description (pre-recorded)

New notes clarify that meeting the Level AA requirement (11.1.2.5) automatically satisfies the Level A requirement (11.1.2.3). Audio descriptions are only required when important visual information is not already conveyed through the existing audio track.

11.1.3.4 Orientation

In a mobile context, a new note means that this requirement does not apply to apps that are only used on hardware supporting a single display orientation or that are physically fixed in one orientation (for example, apps that are used on tablets mounted on a wall, all in the same orientation). Typical mobile apps running on phones and tablets are still expected to support both portrait and landscape orientations unless locking the orientation is essential.

11.1.3.5 Identify input purpose

New notes clarify that this requirement applies only when the technology supports attributes for identifying input purpose. In a mobile context, this means that apps should set correct input types and purposes where the platform supports them, enabling features such as auto-completion and reducing input effort and errors.

11.1.4.4 Resize text

New notes clarify how text resizing should be interpreted in relation to platform capabilities. In a mobile context, apps are expected to support text scaling up to 200 percent. This can be achieved either through in-app mechanisms or by working correctly with platform features (for example, system text size settings). Text resizing must not result in loss of content or functionality.

Where the platform scales most but not all text (for example, text in the tab bar), apps are only required to support resizing to the extent provided by the platform. In these cases, text semantics, content, and functionality must still be preserved. The notes also emphasise best practices such as using scalable fonts, especially embedded fonts, to avoid quality loss when text size increases.

It is also important to consider Clause 11.7 User preferences. In a mobile context, it implies that when a documented platform accessibility feature, such as text resizing, is provided by the operating system and enabled by the user, apps are expected to respect that setting and scale text accordingly. Only apps that are deliberately designed to be isolated from the platform are exempt from this requirement.

11.1.4.10 Reflow

In a mobile context, a new note means that when users change text size or screen orientation, content should reflow without loss of information or functionality and without requiring two-dimensional scrolling, where the platform supports this. Another note explains that when a functionality provides multiple modes of operation (for example, a document editing tool with an edit mode and a view mode), it may not be possible to support reflow in all modes. In such cases, the success criterion is satisfied if at least one mode supports reflow without loss of content or functionality.

11.1.4.11 Non-text contrast

A clarification note adds examples of appearance modification by the author. In mobile apps, this applies when native components are visually customised, such as changing the colours of a native iOS toggle.

11.1.4.12 Text spacing

New notes clarify that this applies to apps that use markup languages to define their user interface. Apps do not need to provide their own text spacing controls, but when a mechanism to modify text spacing is available, the content must respond correctly to it.

11.1.4.13 Content on hover or focus

In a mobile context, a new clarification means that when apps show extra content such as custom tooltips, sub-menus, or popups on hover or focus, this content must be dismissible, remain visible while users interact with it, and persist until the trigger is removed or the content is dismissed. Content whose appearance is fully controlled by the platform (for example, system tooltips) is excluded. Elements that become visible on focus but do not introduce additional content are also not covered.

11.2.1.1 Keyboard

In a mobile context, new notes mean that for mobile apps, “keyboard support” is not about providing an on-screen keyboard. It means that the app must work with whatever keyboard input the operating system provides, such as a physical keyboard, switch device, or other keyboard alternative. If the operating system offers a keyboard interface, users must be able to use all app functionality through it. Even if an app shows its own custom keyboard, it still has to accept input from the system’s keyboard and keyboard alternatives.

11.2.1.2 No keyboard trap

In a mobile context, a new note means that this rule only applies when an app uses keyboard focus to move between elements. Some apps respond to key presses without moving focus, for example when a key directly triggers an action such as closing a screen. In these cases, there is no focus to get stuck on and therefore no keyboard trap, meaning that actions such as pressing Escape to close a screen without focus do not fail this success criterion.

11.2.1.4 Character key shortcuts

A new note clarifies that long key presses and platform accessibility features are not considered keyboard shortcuts under this criterion.

11.2.3.1 Three flashes or below threshold

New notes clarify that this requirement covers flashing created by the software itself, such as animations or visual effects. Flashing that comes from externally sourced content shown in the software (for example third-party or streamed video) is out of scope and remains the responsibility of the content provider.

11.2.4.4 Link purpose (in context)

In a mobile context, a new note means that in apps, a “link” refers to any user interface control that behaves like a hypertext link, including mobile controls that navigate users to other screens or content.

11.2.5.1 Pointer gestures and 11.2.5.2 Pointer cancellation

A clarification note explains that this requirement also applies to platform software (such as user agents, assistive technologies, and operating systems), with each layer responsible only for its own pointer actions and not for those of underlying layers. 11.2.5.2 also provides examples of essential functionality, such as system-related features including waking a device from sleep or power-saving states.

11.4.1.3 Status messages

This success criterion was updated to better align with WCAG2ICT. In a mobile context, this means that status messages must be programmatically available to assistive technologies so they can be announced without moving focus, even when the messages are not implemented using markup languages. The clarification highlights the role of platform accessibility services in exposing these status messages to users.

Success criteria that became Void for mobile apps

11.4.1.1 Parsing
11.3.2.6 Consistent Help (WCAG 3.2.6, Level A)

Struggling to keep mobile accessibility testing manageable?

Abra supports teams with tooling designed specifically for mobile accessibility. We combine automated and semi-automated manual tests, link every rule to the official standards, and connect findings to clear explanations and solutions in our documentation. Test results can be turned into accessible PDF reports in your own styling, ready for internal review or compliance documentation.

If you want to move beyond fragmented manual testing and make mobile accessibility part of a sustainable process, Abra can help.