Beyond Success Criteria: interoperability, accessibility features and user preferences in EN 301 549 v4.1.1

Most discussions about EN 301 549 focus on the Success Criteria. That's understandable, but there are other requirements that matter just as much for mobile applications.

Clauses 11.5, 11.6, and 11.7 are often overlooked. They define how apps must expose accessibility information, avoid disrupting platform accessibility features, and respect user preferences. These requirements significantly affect how apps should be assessed for compliance.

One of the updates in EN 301 549 v4.1.1 is a clearer approach to responsibility across layers. The standard refers to multiple layers involved in accessibility, including the underlying layer (hardware and low-level software), platform software (for example operating systems and native default components), application software (such as mobile apps), and assistive technologies or accessibility services. Each layer is considered responsible for the behaviour it controls.

In this article, we look more closely at what these updated definitions and additional clauses mean for building accessible apps.

PS: we also wrote a blog about the Success Criteria changes in EN 301 549 v4.1.1.

Relevant definitions

Documented accessibility feature

Feature of an ICT offered to end-users that can enhance accessibility and is documented.

In a mobile context, this refers to accessibility features provided to users in an app. For example, if an app describes a built-in text size control, colour scheme, or reading mode as an accessibility feature in its help pages or onboarding, that feature becomes a documented accessibility feature of the app.

Documented platform accessibility feature

Feature of a platform offered to end users that can enhance accessibility and is documented.

In a mobile context, this refers to accessibility features provided and documented by the operating system. For example, system text size settings, colour filters, contrast adjustments, pointer size, and cursor behaviour as documented by Android or iOS are documented platform accessibility features.

Documented platform accessibility service

Subset of the platform's Application Programming Interface (API) that supports interoperability between a user interface running on the platform software and assistive technology.

NOTE 1: They allow application developers to create software that is compatible with assistive technologies.

NOTE 2: These services are also often used by non-accessibility software and testing software.

In a mobile context, these are the operating system services that enable interoperability between an app and assistive technologies. The APIs provided by Android and iOS that allow screen readers, switch access, voice control, and other assistive technologies to obtain information about the user interface are documented platform accessibility services.

Documented platform service

Service provided by the platform that is documented by the platform author for public use by accessibility applications and utilities created by third parties.

NOTE: Platform services provide documented methods that allow software to add or integrate functionality provided by the platform rather than having to attach themselves in an ad-hoc fashion which is hard for both parties to support.

In a mobile context, this is a broader category covering any operating system service documented for use by apps. Services that allow apps to integrate with platform functionality, such as notifications, sharing, or clipboard, are documented platform services.

Not every documented platform service is an accessibility service, but some play a role in how accessibility features are implemented or supported.

Clause 11.5: Interoperability with keyboards and assistive technology

Interoperability means that an app must work together with the documented platform accessibility services provided by the operating system.

Clause 11.5 applies when app functionality is not closed to programmatic access. This is the case for most Android and iOS apps. It requires that accessibility-relevant information is exposed through the documented platform accessibility services, so that assistive technologies and keyboards can perceive and operate it.

The clause is structured horizontally, applying across many success criteria rather than being tied to a single requirement.

EN 301 549 v4.1.0 specifies the following categories that must be programmatically exposed when applicable:

1. Object information

   In apps, information such as role, state(s), boundaries, name, and description must be exposed for elements such as buttons, switches, text fields, tabs, and custom controls.

2. Row, column, and headers

   In apps, structural relationships must be exposed, such as row, column and header information in tables, grids, or list-based layouts.

3. Values

   In apps, the current value and any minimum or maximum values must be exposed for elements such as sliders, steppers, progress indicators, or input fields.

4. Label relationships

   In apps, elements that act as labels must expose their relationships, for example text that identifies the purpose of a control.

5. Parent-child relationships

   In apps, the hierarchical structure must be exposed, for example nested views, grouped controls, menus and expandable sections.

6. Text

   In apps, rendered text must be exposed, along with its attributes and boundary.

7. List of available actions

   In apps, available actions must be exposed, for example copy, cut and paste actions.

8. Execution of available actions

   In apps, available actions must executable, such as copying, cutting and pasting.

9. Tracking of focus and selection attributes

   In apps, information and mechanisms necessary to track focus, text insertion point, and selection attributes of elements must be exposed.

10. Modification of focus and selection attributes

    In apps, it should be possible to modify focus, text insertion point, and selection attributes of elements.

11. Change notification

    In apps, changes of information such as roles, states, boundaries, name, description, values, actions to states, properties and values must be exposed.

12. Modifications of states and properties

    In apps, states and properties which can be modified by users without the use of assistive technology, must also be modifiable using assistive technologies, enabling equal access.

13. Modifications of values and text

    In apps, values and text which can be modified by users without the use of assistive technology, must also be modifiable using assistive technologies, enabling equal access.

Clause 11.5 covers both exposing information and enabling modification. Users relying on assistive technologies must be able to interact with the app in an equivalent way to other users.

Clause 11.6: Documented accessibility features

Clause 11.6 addresses how documented accessibility features are controlled and preserved.

11.6.1 User control of accessibility features

Where ICT is, or includes, platform software, the platform software shall provide sufficient modes of operation for user control over documented platform accessibility features.

NOTE: Clause 12.3 specifies that accessibility features of the ICT are to be documented either as part of the ICT or in a separate documentation.

In a mobile context, this implies that the operating system provides sufficient modes of operation for users to control documented accessibility features, for example through system accessibility settings.

11.6.2 No disruption of accessibility features

Where ICT is, or includes, non-web software, the non-web software shall not disrupt documented platform accessibility features except when requested to do so by the user during the operation of the software.

NOTE: Clause 12.3 specifies that accessibility features of the ICT are to be documented either as part of the ICT or in a separate documentation.

In a mobile context, this means that apps shall not disable, override, or interfere with documented platform accessibility features, except where explicitly requested by the user.

An app that relies on a platform feature for part of its functionality but prevents that feature from working elsewhere would not meet this requirement.

Clause 11.7: User preferences

Clause 11.7 explicitly addresses user preferences:

Where ICT is, or includes, non-web software that provides a user interface, and is not designed to be isolated from its platform, that user interface shall follow the values of the user preference settings for documented platform accessibility features unless it is essential to the function of the non-web software to not follow a user preference setting.

NOTE 1: Clause 12.3 specifies that accessibility features of the ICT are to be documented either as part of the ICT or in a separate documentation.

NOTE 2: Non-web software that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them.

NOTE 3: For non-web software, the underlying platform is usually the operating system.

NOTE 4: When ICT is a user agent (such as a web browser or non-web document viewing software), this clause implies that at least one mode of operation is offered that enforces a rendering of the content that follows the values of the user preferences.

NOTE 5: This does not preclude the non-web software from having additional values for a setting as long as there is one mode where the application will follow the system settings even if more restricted.

NOTE 6: Features that might be documented as accessibility features for a platform include, but are not limited to colour filters, contrast, text size, pointer size, and text cursor.

This clause now uses the documented platform accessibility features definition to reference the user preferences that should be followed. This is broader compared to EN 301 549 v3.2.1, where the clause listed specific platform settings:

Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.

In v4.1.1, these settings are no longer presented as a fixed list. NOTE 6 gives examples of features that might be documented as platform accessibility features, including colour filters, contrast, text size, pointer size, and text cursor.

Whether a particular setting falls under Clause 11.7 therefore depends on whether it qualifies as a documented platform accessibility feature. According to the definition, this is a feature provided by the platform that can enhance accessibility and is documented as an accessibility feature in instructional material made available to users by the platform author.

This can still create ambiguity in practice.

A feature may be documented as an accessibility feature on one platform but not on another. For example, Dark Mode could be documented as an accessibility feature on Android but not on iOS. Under Clause 11.7, an app could therefore be required to respect the Dark Mode preference on one platform but not on another, even though the setting exists on both.

There is also the question of what should be considered the platform and who should be considered the platform author. On Android, Google provides the operating system, while manufacturers such as Samsung add their own platform layers and accessibility features. If Samsung documents a feature as an accessibility feature in One UI, while another Android manufacturer does not, could the requirements for the same app differ between devices? The updated definition makes it clearer that simply having a system setting is not enough: the feature needs to be documented as an accessibility feature by the relevant platform author. However, this still leaves room for different interpretations in layered mobile ecosystems.

In a mobile context, this reflects the reality that accessibility features vary between platforms, operating system versions, and potentially device manufacturers, and that they evolve over time. Developers and auditors therefore need to understand which documented platform accessibility features apply in the environment in which the app is being assessed.

This may still lead to different expectations across platforms and devices, particularly where several parties contribute to the platform and its accessibility features (see issues #23, #555, #622).

Conclusion

Clauses 11.5, 11.6, and 11.7 are complementary. Together, they define how apps must integrate with the platform's accessibility infrastructure.

• Clause 11.5 ensures that accessibility-relevant information can be programmatically exposed through documented platform accessibility services.

• Clause 11.6 ensures that accessibility features relying on that information are not blocked, overridden, or disrupted by the app.

• Clause 11.7 ensures that apps respect user preferences for documented platform accessibility features.

EN 301 549 v4.1.1 does not introduce significant new requirements in these clauses compared to earlier versions. However, the updated definitions bring welcome clarity to the division of responsibilities between platforms and applications.

For mobile applications, this reinforces that accessibility is not something that can be selectively supported. If an app participates in the platform ecosystem, it must allow documented platform accessibility features to operate consistently across its interface, unless the user has explicitly requested otherwise.

This also means that compliance is not only about meeting individual success criteria. An app that meets every success criterion in isolation may still fall short if it blocks, overrides, or ignores the accessibility infrastructure it runs on.

Next steps

Need help testing your mobile app against EN 301 549? Abra provides tooling and services designed specifically for mobile accessibility. Contact us for more information.

For an overview of changes to individual success criteria, see Mobile app accessibility under EN 301 549 v4.1.1.