Clarification regarding success criterion 2.2.2 Pause, Stop, Hide concerning prefers-reduced-motion

[giacomo-petri]

Is the media query "prefers-reduced-motion: reduce," assuming proper implementation, a valid means to satisfy the success criterion 2.2.2 Pause, Stop, Hide?

From a normative perspective, when properly implemented, this query serves as a mechanism for author to allow users to control animated content. It's triggered by the user's OS settings rather than a control provided by the author, yet it remains an effective method for managing animations.

While it serves as a sufficient technique for SC 2.3.3 Animation from Interactions, it is not mentioned in SC 2.2.2 Pause, Stop, Hide. Is there any reason for that?

If we agree that "prefers-reduced-motion: reduce" can be a mechanism to pass 2.2.2, should we develop a slightly different sufficient technique with examples? Through the media query, not only can animations be halted via CSS, but preferences can also be detected via JavaScript, allowing for actions such as replacing GIFs or decorative background videos with static images.
I'm willing to undertake this task if there is consensus.

---

Additionally, authors have the capability to tailor the user experience by hiding and revealing content based on user preferences. For instance, with reduced motion enabled, authors can choose to entirely conceal important informative animated portions of the page, thereby fulfilling SC 2.2.2, although this may limit access to equivalent information for some users. However, no specific criterion fails at this point.

Can media queries be regarded as an "alternate version" that either conforms or doesn't conform with WCAG? Through this lens, it can be concluded that, despite meeting all SC, the alternate version is not equivalent to the "default" one in the previous example.

[kimviens]

Check out #3478. Having a sufficient technique around prefers-reduced-motion might also help fix a dilemna with 2.2.2 Pause, Stop, Hide. At least in my opinion.

[mbgower]

Draft Proposed Response

Using newer features of a specific technology to fully address existing success criteria can sometimes be problematic. Use of this CSS query may be a case in point.

At first glance, prefers-reduced-motion seems like it could be used as part of a technique that could eliminate moving, blinking or scrolling content. However, such a technique would only be as effective as the actions taken by the author based on detection of the user setting (as well as the existence of an operating system user preference that is picked up by the user agent).

For example, if all an author did was to reduce but not eliminate motion in response to a prefers-reduced-motion query, the technique would not be sufficient (to meet 2.2.2).

In addition, the existing technique, Using the CSS reduce-motion query to prevent motion, which does have a check for the quality of the response by the author (i.e., prevent motion) does not seem to entirely address a need of 2.2.2, which is to do with discovery of information.

Since the SC lists a prerequisite where the information "starts automatically", one can infer that the user is aware of information before they elect to pause, stop or hide it. If such information was completely hidden from the user on page load via a CSS query, the solution does not seem to arrive at an equivalent outcome:

1. without the CSS query, the information first updates, then the user is aware of it, and acts;
2. with the CSS query, the user is unaware of the potential to receive additional information.

Given these considerations, a technique that used prefers-reduced-motion to address 2.2.2 would seem to need to address a number of points before it could be considered sufficient.

[mraccess77]

There are situations like decorative animations that fall under 2.2.2 that could be met simply by turning them off. But agree that any technique would need to be scoped appropriately.

[nattarnoff]

Hey, as someone who helped drive initial discussions around prefers-reduced-motion and 2.3.3 I am happy to go on record that the media query alone is not a sufficient technique for 2.2.2.
First, the media query is for reducing motion, not to specifically eliminate it. Part of me wishes it did, but then a lot of content would be lost to those of us who rely on it. Which brings me to my second point, there should not be any grey in if a technique is successful or a failure. Prefers-reduced-motion is there specifically FOR the grey areas. We know motion & animation can improve usability, but too much makes some people ill. The media query lets us have the best of both.

[patrickhlauke]

such a technique would only be as effective as the actions taken by the author based on detection of the user setting

as is the case with most "a mechanism is available" type techniques.

(as well as the existence of an operating system user preference that is picked up by the user agent)

comes down to the usual "accessibility supported" conundrum.

[giacomo-petri]

Let me clarify my stance. I'm not suggesting that simply using prefers-reduced-motion ensures compliance with success criterion 2.2.2. To reiterate my initial point:

Is the media query prefers-reduced-motion: reduce, assuming proper implementation, a valid means to satisfy the success criterion 2.2.2 Pause, Stop, Hide?

I'm exploring whether the prefers-reduced-motion: reduce media query (if properly handled) serves "as a mechanism for author to allow users to control animated content".

I concur that if we decide to proceed with a technique, it's imperative that it doesn't solely depend on the media query but requires proper implementation as well.

Nonetheless, my primary concern lies in establishing whether utilizing the media query correctly is adequate for compliance.

[nattarnoff]

@giacomo-petri what is "proper implementation" for the media query? Considering that we are talking about "Pause, stop, hide" we need to acknowledge that the media query doesn't pause things, you still need a control for that. We can use the media query to stop and hide the animation, but what are the consequences? In any meaningful animation, hiding it hides the content and message and an equivalent needs to replace it. If we stop it, we may get the message, but then why animate it? More likely we are missing part of the message. Well because we used the media query, we can't just start it, we need to go into the OS turn off the no animation settings, watch the animation, then turn the setting back on. From a UX perspective, you lost the user.

At this time, given how it is currently spec'd I do not think it is a valid solution for 2.2.2.

[patrickhlauke]

probably worth distinguishing here what the animated thing is...

for purely decorative/eye-candy things, just suppressing those based on the media query seems a good approach to me, without the need to now have an explicit play/pause control again.

but yes, if the animated thing is actual content, then the best you can do is using the media query (in combination with JS) to set the initial state (i.e. prevent things from randomly autoplaying, and set them to paused), but still provide a control to explicitly play them.

[giacomo-petri]

@nattarnoff,

As @patrickhlauke pointed out, authors can detect the media query through JavaScript and implement necessary adjustments to ensure compliance with the 2.2.2 success criteria. For instance, they can automatically pause the video and introduce a play/pause button, allowing users to control playback.

for purely decorative/eye-candy things, just suppressing those based on the media query seems a good approach to me, without the need to now have an explicit play/pause control again.

Many websites encounter this situation, and it would be a significant advancement if they could support it by utilizing the prefers-reduced-motion: reduce media query. This is particularly important because it's odd for a screen reader user to encounter a pause button for a decorative animation that shouldn't be presented. By employing this technique, you can simply add aria-hidden="true" to the animation, rather than conveying something decorative just to provide context to the "Play/Pause decorative animation" button.

[nattarnoff]

I'm all for @patrickhlauke approach of pausing to initial state and adding a button. I don't know why I didn't think of that approach. I think this is a very clear example of how it can be used. I'm always down for stopping frivolous/decorative animations, but I'm heckin' biased.

I'm more concerned about people just seeing, prefers-reduced-motion in the text of success techniques and not reading the details. If we prescribed specific clear approaches as success techniques, I think it's usable.

[patrickhlauke]

but yes, if the animated thing is actual content, then the best you can do is using the media query (in combination with JS) to set the initial state (i.e. prevent things from randomly autoplaying, and set them to paused), but still provide a control to explicitly play them.

noting here that in those cases, the mechanism that actually makes this pass 2.2.2 is the play/pause button. using the media query to determine the initial play/pause state is a nice-to-have only.

[fstrr]

I'm working on a replacement for F47 so it covers blinking content rather than the code used to create it.

It would be useful to have this, and #3478, agreed upon so I can include some content on whether prefers-reduced-motion is sufficient. It looks like people agree that it isn't, but these threads feel like they've petered out without a definite conclusion.

[patrickhlauke]

@fstrr blinking isn't motion though...