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

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.0 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.0.

Relevant definitions

Documented accessibility feature

Feature offered to end-users that can enhance accessibility and is documented as an accessibility feature in instructional material made available by ICT authors.

NOTE: Such features are often presented to users as accessibility user preference settings.

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 offered to end-users that can enhance accessibility, provided by the platform, and documented as an accessibility feature by platform authors.

NOTE: Such features are often presented to users as accessibility user preference settings.

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 those platform accessibility features documented as intended for users.

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 software shall not disrupt those documented platform accessibility features that are defined in platform documentation except when requested to do so by the user during the operation of the software.

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 preferences that users have set for the documented platform accessibility features.

NOTE 1: 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 2: 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 3: 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 4: Features that might be documented as accessibility features for a platform include colour filters, contrast, text size, pointer size, and text cursor. The website or other information sources provided for the platform can be consulted to see which features are documented as accessibility features for that platform.

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.0, these settings are now listed in NOTE 4, which also mentions that: "The website or other information sources provided for the platform can be consulted to see which features are documented as accessibility features for that platform."

This last point can create confusion.

A feature may be documented as an accessibility feature on one platform but not on another. For example, Dark Mode could be listed as an accessibility feature on Android but not on iOS.

Under Clause 11.7, an app could be required to respect the Dark Mode setting on Android, but not on iOS, even though the feature exists on both platforms.

This raises a further question: which "website and other information sources" should be consulted?

On Android, this could mean Google's documentation for stock Android. But what about manufacturer-specific variants? If Samsung documents Dark Mode as an accessibility feature in One UI, but Huawei does not in EMUI, does compliance differ between devices running the same app? And what if the marketing website categorizes features as accessibility features but the developer documentation does not?

In a mobile context, this change reflects the reality that accessibility features vary between platforms and evolve over time. It places ongoing responsibility on app developers to consult platform documentation and ensure their apps respect available accessibility settings.

However, the lack of clarity around what constitutes authoritative platform documentation may lead to inconsistent expectations across devices, manufacturers, and regions. (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.0 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.0.