Success Criterion 2.2.2 - Pause, Stop, Hide - Level A

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#pause-stop-hide

Share your thoughts for applying to mobile apps as a comment below.

[qbalsdon]

Does the mechanism have to exist within app or can we just say that it should at least respect system settings?

[JJdeGroot]

MATF meeting on July 31, 2024

[Source](https://www.w3.org/2024/07/31-matf-minutes.html#t05) So many failures I have to drop for a work meeting. Thanks, y'all! adb control for ttr Joe_Humbert: settings put secure accessibility_interactive_ui_timeout_ms [MILLIS] % millis are additive - they add extra time thankx Quintin I think there should be guidance given the dominance of video on mobile - it should stay paused if the same element type is paused +1 quintinb Either every element should be pause-able or at least respect settings Joe_Humbert: Just to raise: Android and iOS treat it differently when they refer to the setting - I wonder if iOS (reduce animations) is actually satisfactory +1 Joe - is that actually stop animations? I hate that terminaology - so vague GleidsonRamos should we save the user preference in app? +1 GleidsonRamos yes I think there should be guidance on that great question GleidsonRamos should we sync app setting with OS setting? +1 yes I think that is the way JJ there is probably some guidance on this type of situation Jamie: Just to clarify: there is a feature for reduce motion and auto play animated images - seems like apple has 2 settings +1 jamie. maybe I was confused We should probably be clear about what we want and let the OS sort themselves out JJ any new agenda items? JJ how do we deal with OS vs / system settings quintinb: maybe we should just focus on the desired behaviour Joe_Humbert: We should honour users system settings +1 +1 Joe_Humbert

Summary:

quintinb suggests guidance for pausing video on mobile and respecting system settings for all elements. Mick agrees.

quintinb and Joe_Humbert discuss the differences between Android and iOS settings for reducing animations, expressing concerns over vague terminology. Jamie joins the discussion.

GleidsonRamos asks if user preferences should be saved in the app and synced with OS settings. quintinb agrees and thinks guidance is needed.

Jamie clarifies features for reducing motion and autoplay on Apple devices. quintinb agrees on the need for clear guidance and letting the OS handle specifics.

quintinb asks if there are new agenda items and how to handle OS vs. system settings.

Joe_Humbert emphasizes the importance of honoring user system settings. JJ and quintinb agree.

[julianmka]

Based on previous task force conversation, this SC can be applied to native mobile apps and mobile web with minimal or no deviation from WCAG2ICT.

Proposal In MATF's first draft of guidance, this SC's section will read as:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.2, replacing “page” and “Web page” with “screens or views” and removing “See Conformance Requirement 5: Non-Interference” in Note 2 of the success criterion.

With these substitutions, it would read:

2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true:

Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and

Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

NOTE 1 For requirements related to flickering or flashing content, refer to Guideline 2.3.

NOTE 2 Since any content that does not meet this success criterion can interfere with a user's ability to use the whole [screen or view], all content on the [screens or views] (whether it is used to meet other success criteria or not) must meet this success criterion.

NOTE 3 Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.

NOTE 4 An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.

NOTE 5 While the success criterion uses the term “information”, the WCAG 2 Intent section makes it clear that this is to be applied to all content. Any content, whether informative or decorative, that is updated automatically, blinks, or moves may create an accessibility barrier.

Please indicate your agreement with a thumbs up emoji 👍, or if you disagree, use the thumbs down emoji 👎 and elaborate in comments.

[JJdeGroot]

A few notes/comments below from e-mail conversation with @alastc (AC)

JJ: For 2.2.2 Pause, Stop, Hide, developers can also use system settings such as reduce motion to stop or hide motion.

• But... on iOS the setting is named "reduce motion", when motion is stopped or hidden, it's not "reduced" as the settings implies
• And users might not be aware of these settings, it's also not always possible to deeplink to the relevant settings screen.

AC: I think in general we have assumed that a widely-available user-setting can be the mechanism. If having that setting on then passed the criteria text the content (/app) would pass.

JJ: Okay, the question is when is a setting considered widely-available? Would auditors need to write this down in the "Accessibility support baseline" section? E.g. some settings are only available on newer Android version, and some settings be buried deep in the settings screens.

In WCAG 2.x we’ve taken that on a case by case basis but, for example, a system setting is sufficient to pass Animation from interactions in C39. This sounds similar.

AC: This topic is a constant discussion, there isn’t a clear and concrete answer for a world-wide standard. However, if the setting is free (once the base device and OS are paid for), and on more than 66% of used devices it should be a fairly safe option.

[detlevhfischer]

From the discussion of this in the web context it's worth noting that in some UA, "prefers-reduced-motion" is not even in the settings - it seems in Firefox you need to delve into about:config, pass some warnings and find the flag before it is set they way you want it. Granted, in recent versions of iOS and Android it is more straightforward. Would still be interesting to research empirically how many of the users negatively affected by motion will

• A. Know there is an accessibility setting for that
• B. Successfully locate that setting.

[julianmka]

After discussion and voting at the meeting today, the task force members present accepted the proposed language for the first draft of our guidance.

[JJdeGroot]

Closing this issue because the draft language has been accepted.

[jamieherrera]

Just in case we come back to this SC in an updated 2.0 version after 2025, we should add a best practice note for the dev to honor a user's OS Accessibility motion settings by including the appropriate Boolean-enabled setting for reduced motion in the app; it's not a WCAG requirement since the SC has this 5 second minimum, and the user has to toggle the setting in the OS, but at least the dev's code shouldn't be the barrier. The WCAG2ICT notes sort of soften the 5 second expectation, maybe our 2.0 version could have similar language as a note, knowing that the WCAG language is... what it is.