Csswg-drafts: [scroll-animations] TAG feedback: interaction with prefers reduced motion

[majido]

Here is a question/feedback from TAG. The original is here but I am creating this issue to track this in CSSWG as well.

Given that one of the use cases this API is explicitly designed to enable is parallax scroll effects, which is a known trigger for vestibular disorders, it might be worth considering how this feature integrates with prefers-reduced-motion.

For example, should animations expressed using this API be disabled by default if prefers-reduced-motion would match? And if so, could we design a way to allow animations to express that they are safe to be shown for users who prefer reduced motion?

I think it might even be worth opening a broader discussion on what the default behaviour for prefers-reduced-motion should be for all web APIs which allow animation, but I think the question is especially critical for this API given it's more likely than average to cause harm to users.

[majido]

Let's have a discussion on this in the next scroll-timeline sync to get to a consensus and get back to TAG on this.

Here are some earlier related discussions on this:

• 2018 csswg-archive email thread on the same topic
  
  
  
  • Comment from TAG review on Animation Worklet on similar topic
  
  

[flackr]

I expect that some of these animations will reveal parts of the site without which you may not be able to use it (e.g. some content slides in as the user scrolls that part of the page into view). I believe the stance we've taken on prefers-reduced-motion so far is that we don't know enough about the effects to know how to change them to honor the setting and would prefer that authors create different animations when prefers-reduced-motion is enabled.

[frivoal]

the prefers-* family of media queries only indicate user preferences, so that the author can react to them in useful ways. So having an author disable parallax effects when it's on would make sense, but having the UA do that for them wouldn't be a good fit for how it works.

However, there are parallels you can draw the the prefers-contrast / prefers-color-scheme vs forced-colors and https://drafts.csswg.org/css-color-adjust-1/#forced-colors-mode. In addition to a few media features that lets the author learn about user preferences, there is also a mode where the user gets the UA to enforce their choice. There's still an MQ to let the author know that that's happened, but it's a different situation.

Maybe the same approach might make sense in terms with regards to preferring no animation and forcibly turning them off.

[majido]

I agree that changing prefers-reduce motion to automatically apply is not backward compatible and also prefer a solution that can be used for all animations.

I like the idea of having forced-reduce-motion that would forcibly reduce the motion of author provided animations. This would be backward compatible and allow User Agent to interfere on behalf of the user even when authors have not done the right thing.

For example the User Agent could change the animations that modify certain properties (transform, top, left, height, width, etc.) to do a discrete interpolation between the initial and final value of the keyframe effect. Basically have them do a single jump from initial to final value in the middle. That would leave the animation final output intact while reducing the motion.

[atanassov]

Ideally we should include @alice for this discussion, thus, let's schedule it for the next APAC timed call.

[alice]

Some thoughts:

Rather than framing the argument around existing solutions (which was my mistake), let's bring it back to user needs and existing affordances.

My original comment linked to this WebKit blog post which lists out potential triggers for vestibular disorders (keeping in mind that it's not only users with vestibular disorders who benefit from reduced motion; this is still a useful set of motion categories to think about).

My concern with this API is that there is a very strong overlap between that list of triggers and the intended use cases of the API (thank you for listing use cases!)

In particular, the parallax and zoom use cases are explicitly called out in the explainer, and the plane-shifting example in the blog post is also a scroll-triggered animation.

@flackr mentioned

some of these animations [may] reveal parts of the site without which you may not be able to use it (e.g. some content slides in as the user scrolls that part of the page into view)

This is a very strong user need, and one we should keep in mind when designing mitigations; I don't think it rules out an automatic intervention, though.

@frivoal noted

... there are parallels you can draw the the prefers-contrast / prefers-color-scheme vs forced-colors and https://drafts.csswg.org/css-color-adjust-1/#forced-colors-mode. In addition to a few media features that lets the author learn about user preferences, there is also a mode where the user gets the UA to enforce their choice. There's still an MQ to let the author know that that's happened, but it's a different situation.

This is a great insight, but a little unsatisfying given that users likely only have access to a single affordance to control whether they will see potentially triggering animations or not. It's hard to imagine having separate user affordances for "reduce motion" and "really reduce motion" - the difference between the two would be both difficult to express and difficult to observe (unlike macOS "increase contrast" vs. Windows "high contrast").

So, there is still an open question about how we can honour the user's preference here. I would like to at least explore the possibility of this API working differently with this preference than other animation APIs, given the higher likelihood of user harm.

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations] TAG feedback: interaction with prefers reduced motion.

The full IRC log of that discussion

<dael> Topic: [scroll-animations] TAG feedback: interaction with prefers reduced motion

<dael> github: https://github.com/w3c/csswg-drafts/issues/5321

<dael> Rossen_: aboxhall_ was part of the larger TAG review and has captured thoughts. aboxhall_ if you want to summerize outstanding issues with this it would be great

<dael> aboxhall_: I don't have a solution. Problem is we're looking at the scroll animations proposal and it seemed to me that maybe we can do better in this case then requiring authors to take a specific action to support perfers-reduced-motion given that most of the use cases for scroll animations seem like they fall into bucket of things that will trigger vistibular disorders and potentially problematic

<dael> aboxhall_: IN the issue the last comment I left tried to get into that. I linked to blog post on WK which listed those potential triggers. paralax and zoom use cases are explicitly called out. Plane shifting in the blog post is implied as scroll triggered

<Rossen_> q?

<dael> aboxhall_: Seemed strong overlap between use cases and triggers. Seems unsatisfying to leave it to authors to not harm users in this case

<florian> q+

<dael> smfr: Are there other cases where UA overrides author spec animations when p-r-m is in effect

<dael> aboxhall_: Don't believe so, but doesn't mean we shouldn't

<dael> aboxhall_: In issue florian drew parallels with forced-colors where UA overrides author's colors. There are escape hatches to let author react.

<florian> [It's a different Florian (or I'm having gaps in my memory]

<dael> aboxhall_: In that case florian said we could use similar approach. My heistation with that is I don't think users will get an extra switch any time soon. If someone checks the p-r-m switch...it's not for us to say if it's just your opinion or because animations will trigger migraines.

<dael> aboxhall_: Given only one switch how can we react to that switch?

<fantasai> [Didn't you post https://github.com/w3c/csswg-drafts/issues/5321#issuecomment-659185761 ? ]

<Rossen_> q

<dael> aboxhall_: Potentially do we add...I don't know enough about technologies to speculate the way forward

<astearns> ack florian

<dael> florian: I'm hearing what you're saying

<dael> florian: Wondering if you turn them off entirely you'd have problem with state where animation in early and end are different. Instead of turning off it can be step wise with one step from start to end so initial and final is right but you don't get the movement

<dael> florian: If one initial and final state is enough or we need a way to declare multiple midpoints I don't know

<dael> florian: Something like this allowing a snapping change instead of moving change might work

<dael> aboxhall_: Fantastic idea to begin experiments with

<Rossen_> q?

<dael> Rossen_: Just to make sure when we talk about animations here it's css only or web animations?

<dael> aboxhall_: scroll-linked animations

<dael> aboxhall_: Just because it seemed like the use cases for that had such a strong overlap with the potentially triggering animations

<dael> aboxhall_: Worth exploring how to more deeply embed that preference into animation APIs

<dael> aboxhall_: To start scroll-linked animations and florian suggestion

<dael> florian: The overlap is there but not all scroll animation are pure decoration. Maybe comics or long form articles. If it doesn't move you don't understand what it's telling you. Being able to reach end maybe with multi step is needed

<dael> Nicole: On mobile animations are meaningful to find drawers and nav. Shame to lose semantic animations that provide that meaning

<astearns> ack fantasai

<Zakim> fantasai, you wanted to talk about !important rules

<dael> fantasai: Meantion we have 2 levels of author rules. Normal and !important. If this is controllable with css property it's possible we could auto override and we could only do that for non-important rules. If an author things it's important they can flag. Only helps to extent it's expressable in css declarations but we can distinguish between things that exist and nice to have

<dael> aboxhall_: That's good, yeah

<fantasai> s/things/thinks/

<fantasai> s/exist and/needs to exist and those/

<dael> astearns: Hearing a lot of interest in solving this problem of scroll animation when p-r-m preference. I don't hear a full idea of what we should be doing

<dael> florian: Not fully, but I propose when this preference is on, the easing function of the animation is transformed to step-wise and have an open issue if it's a single step between start and end or if there's a control about how many steps and where

<dael> astearns: Seems start to end step is easy to spec

<jcraig> q+ to mentioned animations triggered by user animations versus animation that start at unexpected times

<dael> fantasai: Scrolling, there's the time during active scroll and when you have stopped scrolling. When you scroll halfway through what happens? Might not want jsut start and end b/c in middl eyou have to pick. Might suspend animation, find interpolation point when scrolling stops, and show that

<dael> fantasai: Similar to how we snap after you let go of scroll controls. We step-wise animation to that interpolated position after the scroll but not during

<astearns> ack jcraig

<Zakim> jcraig, you wanted to mentioned animations triggered by user animations versus animation that start at unexpected times

<dael> florian: Interesting

<dael> jcraig: We did a ton of research years ago when shipped p-r-m.

<dael> jcraig: On android and iOS you can flip to scroll. We found a number of users with the trigger sensitivity would page at a time. Scroll and release but stop the finger for the after effect.

<dael> jcraig: Another result is the difference between anmations that happen base don user trigger vs those that follow unexpectidly. We found a number of users if they're doing page in and out prefer to keep that. Made that separate in iOS. User can anticipate there will be motion and it doesn't bother as strongly as when not expected

<dael> jcraig: A lot of contextual. Reason we didn't do it automatically is the contextual understanding

<aboxhall_> Anecdote: a friend of mine with a TBI said a lot of her therapy was around "strategically shutting her eyes" in cases like James was just talking about

<dael> jcraig: Open to explore ideas to allow authros to mark up animation as essential. Haven't found place to shut of animations which is why it's in prefers rather than force

<dael> florian: This is probabaly a topic where won't finalize without experiment. Both mine and fantasai suggestions are interesting. Probably need demos to see if people react well to that

<dael> astearns: Can or should this be applied automatically or is this author advice we give?

<dael> fantasai: Definitely give author advice. Maybe additional controls. But definitely if you don't need a scroll animation when p-r-m is on don't do it

<dael> astearns: Anything else to discuss or leave to experimentation?

<dael> florian: Experiments and further thought is necessary but is anyone signing up to do them?

<dael> florian: Just b/c TAG raised the issue doesn't mean we expect TAG to experiment

<jcraig> s/Haven't found place to shut of animations/Haven't found an appropriate way to shut off animations automatically (without risking breaking understandability and context)/

<dael> Rossen_: Certainly not

<dael> astearns: Lacking volunteers maybe the issue hangs until someone has time to experiment?

<dael> astearns: Only forcing function is if and when scroll animations needs those issues to close for progress

<jcraig> q+

<astearns> ack jcraig

<dael> florian: We've have MS, Google, and Apple TAG people discuss. Maybe they can find internal resources?

<dael> jcraig: One more thing from initial p-r-m discussion is we left it open to expand later. May be extreme but I'll mention it. Text is left at reduce but expandable so could be specific triggers we avoid

<florian> s/We've have MS, Google, and Apple TAG people discuss. Maybe they can find internal resources?/We've have TAG people from MS, Google, and from Apple discuss it today, and the same companies have editors on this spec. Maybe they can find internal resources?

<dael> jcraig: Original proposal was p-r-m: no parallax and get it very specific. aboxhall_ linked to original issue

<dael> jcraig: It could be reduce which is vague or more specific values if necessary.

<dael> jcraig: I'll try and dig up old issue

<dael> astearns: Can you open separate issue since that's about MQ and I'd like to keep this scoped to web animations

<dael> jcraig: Sure. Appropraite to mention in the issue

<dael> astearns: Sure

<dael> jcraig: I think we decided didn't need it until there's a use case and this might be the use case

<dael> astearns: Okay, fine to just mention. If we do want to add values to the MQ I'd prefer to break it out so we don't have a giant issue

<jcraig> s/p-r-m: no parallax/p-r-m: no-parallax/

[cookiecrook]

I mentioned in the call today that I would link to some older discussions about more granular syntax for @media (prefers-reduced-motion) in the context of scroll animations. I recalled these as no-parallax etc, but the prior-mentioned prefixes were actually reduce- and exclude-.

From December 2016:

Future values could be granular tokens, even a combined list, if someone wanted to implement them that way.

prefers-reduced-motion: reduce-parallax reduce-scaling; /* reduce-rotation, etc. */

From August 2020:

iOS is already shipping two variants of a native "reduce motion" setting that differentiates between pans (e.g. automatic side scrolls between screens) and other types of problematic vestibular motion like parallax and scale/zoom. The interface pans often convey a hierarchy. […snip…]

One could see a future expansion of prefers-* to one or more optional variants, making the boolean match most useful for authors.

prefers-reduced-motion: no-preference | [ reduce | [exclude-parallax &| exclude-scale &| … ]

In the context of scroll-animations, please note that 3 of the 5 cited uses cases for prefers-reduced-motion were for effects that are commonly associated with scroll-jacking animations.

• animations along a z-axis (e.g. zoom in or zoom out) or scaling of UI elements
• two or more objects are simultaneously moving in different directions
• two or more objects are moving at different speeds (parallax or momentum trailing effects)

In 2016, I recall that we decided to forego the granular values until an appropriate use case arose.

So if the CSS WG is considering a way for authors to mark their scroll-triggered animations as decorative or not, perhaps this is the use case for more discussion on the granularity of prefers-reduced-motion.

[cookiecrook]

And as @Alice mentioned above, there are examples of all of these trigger types in the WebKit post on prefers-reduced-motion. I added before and after videos that detail some of the reductions and why those variants were chosen.

Note that we were able leave in some of the decorative scroll-triggered animations (e.g. the single remaining leaf [sic] in example 6) for stylistic reasons because it was known to _not_ be a vestibular trigger. This kept the site interesting without any negative effect on the user.