Platform mechanisms and exceptions (part 5)

Mechanism

In several Success Criteria, WCAG uses the phrase “a mechanism is available”. The wording expresses only that a mechanism must be available; it does not specify where users should find it: it could be on the view itself, in the settings of an app, or even in the platform settings (for web content, you would find these in the user agent settings – in other words, the browser settings).

For example, Success Criterion 2.2.2 Pause, Stop, Hide requires that users have a way of pausing, stopping, or hiding moving content like an auto-updating carousel or an auto-playing video:

“For any moving, blinking or scrolling information (…) there is a mechanism for the user to pause, stop or hide it.”

This wording leaves open whether the mechanism can be provided by the operating system.

The following examples illustrate how such a mechanism may be provided by the operating system rather than the application itself:

• Reduce motion: In the case of iOS, there is a Reduce Motion setting, and in the case of Android, the Remove animations setting – and, provided that content honors the setting, the view is shown with moving elements in paused state.
• Increase contrast: iOS has the setting Increase Contrast under Accessibility > Display and Text Size. Activate it, and native iOS switches, which do not meet 1.4.11 Non-Text Contrast requirements in their default state, will now meet them.

It can be argued that if the OS provides such a mechanism and the app honors the setting, the normative requirement is indeed satisfied. However, this is a grey area, and there is no clear consensus yet among accessibility experts whether such a platform mechanism is deemed sufficient to meet the requirement. After all, the mechanism is not immediately discoverable in or next to the content, like a pause button integrated into a video or a moving carousel.

Pros and cons of relying on mechanisms

One big advantage of relying on mechanisms provided by the platform is that for the user, once set, they improve accessibility overall, regardless of the specific app. If built properly, all apps should follow user settings such as Reduce Motion and not show moving content or auto-play videos. The argument goes that if users generally need adjustments such as reduced motion, larger text, or better contrast (Display Zoom or Bold Text are other such generic settings) it makes sense to set these adjustments on the platform level rather than forcing authors to adapt the interface in a way that may break or get out of line with system conventions with the next platform update.

The main argument of those who think a platform mechanism is not good enough is that many users who are affected by issues like distracting movement or low contrast are simply not aware that a platform setting exists to improve matters. Elderly users are disproportionately affected by these issues, and they are often not tech-savvy, not familiar with the ins and outs of the platform and its settings. Also, these settings are usually not active by default – so many users will be affected by default.

2.2.2 Pause, Stop, Hide is not the only WCAG Success Criterion with that mechanism phrase. For brevity, I list all criteria on WCAG level A and AA that apply to software where the term appears:

• 1.4.2 Audio Control
• 1.4.13 Content on Hover or Focus
• 2.1.4 Character Key Shortcuts
• 2.2.2 Pause, Stop, Hide
• 2.5.2 Pointer Cancellation
• 3.3.8 Accessible Authentication

Native exceptions

When there is no mention of a mechanism, there is one other way in which content may satisfy success criteria even where at first sight it appears to fail: the ‘not modified by the author’ exception, i.e., a native component is used without change by the author (such as different styling or different colour).

A number of WCAG Success Criteria explicitly mention “not modified by the author” to define exceptions. For brevity, I again list only Criteria on level A and AA where the term ‘not modified by the author’ appears:

• 1.4.11 Non-text Contrast exception: applies both to native components and to the default keyboard focus indication of the platform
• 1.4.13 Content on Hover or Focus: this has no applicability for mobile apps since title elements are not shown on hover (mouse attached) and focus (keyboard attached)
• 2.5.7 Dragging Movements: exception applies when behaviour is provided via a platform function
• 2.5.8 Target Size (Minimum): again, exceptions apply to native components

What this means from a user perspective is that there are cases where a native component has a clear deficiency such as insufficient contrast, but since the appearance of the component is not determined by the author, it passes.

A good example is the poor keyboard focus visibility in native mobile apps. In both iOS and Android, the default keyboard focus lacks contrast: It is just a light grey or light blue tint with a contrast of about 1.2:1 that can be hard or nearly invisible to spot on some elements. But here, platform settings can come to the rescue: The iOS Full Keyboard Access setting gives the keyboard focus a thick black outline (no such option exists for Android, currently).

With target size, we need to remember that the requirement is actually not that a target needs to have a certain minimum size; instead, there needs to be enough space (an area of 24 x 24 pix) around the target to separate it from adjacent targets. There may be cases where checkboxes lined up as a list of options could be too close together (but possibly pass via the exception, if they use the platform component).

In general, however, finding violations of 2.5.8 Target Size in mobile apps is quite rare. This is also because the recommended target size in mobile design is much larger than the minimum specified in WCAG 44 x 44 pt in iOS, 48 x 48 dp in Android. For a deep dive, you may read a GitHub-Issue 2.5.8 Target Size of the Mobile Accessibility Task Force.

Conclusion

Even where platform mechanisms or native exceptions might be deemed sufficient to meet requirements, authors should provide the best possible default experience to users. In some cases, the conclusion is simple: Don’t auto-play audio, video, or auto-updating carousels. Give control to the user and avoid the hunt for the pause button or the corresponding system setting.

In other cases, it is more nuanced. Many experts encourage the use of system components even where these have known issues, such as the low contrast of iOS switches or contrast issues in system-provided widgets such as date- or time pickers or slider controls. The big advantage of using these standard components rather than building something that is supposedly more accessible is that users often know these components from other contexts of use in other apps. Functionality and behaviour come as part and parcel of these native components and are usually a lot more robust than what authors tend to build when they create their own widgets. Finally, improvements of accessibility eventually made at the platform level will benefit all apps that use native components rather than “optimised” custom components.