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

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.

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

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.

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.

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.

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

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.

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/

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.

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.

There is another position between stepping from initial to final animation state where we step to the nearest author specified keyframe. I.e. this would be equivalent to overriding the per-keyframe easing functions in the animation with steps(2, jump-none) and would allow the user to see the animation in every author specified position. This would mean that animations with lots of keyframes would still appear to animate, though in most cases this would allow the user access to each important point of the animation.

At a high level, if we are defining a new prefers-reduced-motion policy, should we not apply it to all animations? It seems strange that a specific animation timeline leads to a more restrictive policy - unless we apply the restriction to the list of time values that timeline is capable of producing.

At an animation level, we could also consider only applying this to the interpolation of motion inducing properties - i.e. opacity / background-color animations need not be affected, right?

Also, if we have such a policy, should we allow an author to explicitly assert than their animation has been designed to be okay for users with this issue? I.e. I believe on some platforms prefers-reduced-motion still has some slight motion with cross fades to significantly reduce the total amount of motion.

I've been recently using @scroll-timeline with motion reduction and found I had all the control I needed, see demo.

Like any CSS animation, where I have the potential to create vestibular issues, my escape hatch is observing the user's preference and adjusting accordingly. In the demo, I still have 2 really natural nice animations for users with prefers-reduced-motion enabled, and 1 of them is still a scroll timeline animation! I'd be really sad if that color transition as you scroll, was squashed by a forced option.

@media (prefers-reduced-motion: reduce) {
  /* 
    - swap to border-bottom styles
    - transition colors
    - hide the motion animated .indicator 
  */

  .tabs {
    & > header a {
      border-block-end: var(--indicator-size) solid hsl(var(--accent) / 0%);
      transition:
        color .7s ease,
        border-color .5s ease;

      &:matches(:target,:active,[active]) {
        color: var(--text-active-color);
        border-block-end-color: hsl(var(--accent));
      }
    }

    & .indicator {
      visibility: hidden;
    }
  }
}

and in the JS (where this demo uses scroll-timeline):

const {matches:motionOK} = window.matchMedia(
  '(prefers-reduced-motion: no-preference)'
)

if (motionOK) {
  // create scrollTimelines and animate
}

tldr; css animations in general are capable of causing accessibility issues, it's not specific to scroll-timeline. even though many use cases of scroll-timeline will be parallax, a notoriously inaccessible pattern, it's not scroll-timeline's to blame. As I've shown, scroll-timelines can be created within a preference to reduce motion, and can be more "liquid" if the user is OK with motion.

I'm essentially calling for scroll-timeline's interaction with prefers-reduced-motion to be the same as transitions and animations.

If a user is very sensitive, I hope there's means for them to be forceful and control their web experience. but that sounds like a more extreme case that should squash transitions, animations, scroll-timelines, waapi, etc, like all things. not a case that should block scroll-timeline.

finally: prefers reduced motion IS NOT prefers no animation. I think the current interaction scroll-timelines have with prefers-reduced-motion is the right amount. There's a lot of meaningful and interesting solutions that can keep everyone's stomach normal.

The CSS Working Group just discussed [scroll-animations] TAG feedback: interaction with prefers reduced motion, and agreed to the following:

RESOLVED: We are going to start specifying a no motion at all mode that makes motion inducing animations discrete between keyframes where keyframes are sufficiently separated in time

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> flackr: Feedback from TAG was that this could be very disconcerting for people with vistibular disorders so want to be able to disable
<dael> flackr: 2 separate issues here
<dael> flackr: One is idea of adding more granular prefers-reduced-motion values. There are examples of effects devs can fallback to that the dev doesn't believe introduces issues.
<dael> flackr: Also you could still run the animations that are necessary. give the dev freedom to run some animations
<dael> flackr: Other area is if we had model to force animations to be disabled, how would we? I'd like it to be all animations, not just scroll.
<dael> flackr: We need a model to preserve a11y of content. Many examples where scroll linked goes into view and out as you scroll past. First and last isn't sufficient so propose get nearest keyframe so you get all the points in the animation but without smooth motion
<dael> astearns: Take the 2 points in order?
<dael> flackr: Sure
<dael> astearns: First is adding more granular values to prefers-reduced. Purpose is allow devs to gradually add animations?
<dael> flackr: Precident is it's dev makes best effort to reduce. Prop to address serious concerns by having another level dev can't override
<dino> q+ but only if my microphone works
<dino> q+
<dael> TabAtkins: What is the set of additional prefers reduced motion values? See a few different in post by jcraig
<dael> flackr: Simpliest is just one that is no-motion
<dael> flackr: There are intermediates we could consider but detecting which are parallax or scale seems like could be conplicated. In order to meet need of disabling animations I think it would be nice to have a disabled setting
<dael> TabAtkins: Stronger than current reduce value?
<dael> flackr: Yes
<dael> TabAtkins: Okay, seems fine.
<Morgan> q+
<dino> i'm confused. `prefers-reduced-motion` is a media query, not a browser setting. it doesn't impact what the browser does.
<dino> yeah - i give up.
<dael> astearns: Question confuses me. I thought it was a browser setting
<dael> flackr: Setting reflects the OSs environment.
<dael> flackr: Some browser UI responds to preference as well
<dael> TabAtkins: I see issue dino is confused. 2 part thing. MQ for more granular helps. Completely separate is the browser intervention to disable or reduce animations.
<dael> flackr: Correct
<dino> ok.
<dael> flackr: Strictest prefers-reduced-motion could be used by authors for when they know browser intevention is taking place
<astearns> ack dino
<astearns> ack Morgan
<dael> Morgan: Wanted to chime in to say we've been getting increasing number of bugs on FF saying we don't step in enough. Entertaining idea of browser doing more might be a good thing
<dael> flackr: I think it's unclear yet when we'd choose between versions of reduced. Might be browser setting. This would give us more flexibility
<dino> +1 on more granular results in the media-query somehow. But -1 on blocking scroll animations. We can't tell if the scroll animation would cause the issue. That's up to the developer.
<astearns> ack dbaron
<dael> dbaron_mobile: I wanted to...the TAG discussions quoted were a year ago when I was on TAG so I thought I could give more context
<dael> dbaron_mobile: I think one of the big questions that came up in TAG discussion is that the way these mqs work is depend on author to do everything. If author doesn't query for prefers-reduced-motion you don't get anything different
<dael> dbaron_mobile: Deep question is doesn't that seem wrong and shouldn't browser automatically reduce to do right thing for user? and once it does that how should MQ works since they're designed around the author does the thing.
<dael> dbaron_mobile: If browser does the thing what should the MQs look like so they author can say I know what I'm doing in this case
<dael> astearns: MQ would let author know toolkit is reduced. Things they cannot do any they may know a fallback
<dael> flackr: Similar to no script
<dael> TabAtkins: Problem of communicating forced vs do as much as you can is difficult, but in this case golden. If forced is we're turning off your animations and tell the author then the author removing animations is compat. Browser and author actions would match. We can have a harser value and not worry and let interventions happen
<dael> astearns: I was responding to one thing dbaron_mobile mentioned. I don't know if you were finished, though.
<dael> dbaron_mobile: I think I was finished. To respond to TabAtkins I think one of the question is if there's a need for intermediate thing where default is to disable but author can say "yeah I know what I'm doing and I want to do this". We have something liket hat for color but it has to be custom for each thing
<dael> TabAtkins: yeah, for color there are some things that can't be communicated with system colors. I suspect that's not same with animations. We probably can leave that case to the side and do ar easonable job
<astearns> ack fantasai
<dholbert> q+
<dael> fantasai: One thing I was thinking but haven't thought through- what if the UA disables animations by injecting rules between normal and important. Overrides most but author could important the animation if they're really needed
<dael> flackr: Interesting idea.
<dael> flackr: Could be something we add later
<dael> astearns: Talking about that way of implementing? Or ther granular basis all together?
<dael> flackr: We could even if we force disable we could later add a way to reenable either in strong disable or as a third way
<astearns> ack dholbert
<dael> dholbert: Thinking about what user exposed config or UI for this. A little worried about complexity to communicate. Sounds like do not track header vs adding an ad blocked but appied to animations. Weak is send a single and strong is interventions.
<dael> dholbert: I think we need to take that into consideration when thinking about how many values. How do we communicate to user and make it understandable
<dael> astearns: yeah, a little concerned on browser UI
<dael> astearns: From what I understand no UA impl turn it all off
<dael> flackr: Correct
<dael> astearns: So MQ for detecting is kind of cart before horse. Once a browser impl we could do MQ to let authors respond to the harser value
<dael> flackr: Perhaps relates to next part on how browser would strongly disable. If required for scroll-linked animations we need strong disbale
<dael> astearns: Shall we switch to the how?
<dael> flackr: sgtm
<dael> flackr: My prop is when browser wanted to completely disable animations it would change animation type to discrete that flips at 50% between keyframes. All animations would animate between keyframes but no motion between. Gets you access to intermediate positions
<dael> flackr: Gets you intermediate scroll positions or other animations where required for site
<dael> TabAtkins: Basically all animation timing is discrete. Seems okay to me
<dael> astearns: Straightforward. A bit worried about people with animations that have tons of keyframes to get weird motion. if keyframes are close enough in time it would still have a jerky thing
<dael> TabAtkins: Could be detected. Animations that aren't machine generated are small number. machine generated we could take every nth or ever 1sec keyframe
<dael> flackr: Yeah, i would propose something like that
<dael> astearns: Other comments?
<heycam> q+
<dael> astearns: Anyone with a different idea of how to impl harsh mode?
<astearns> ack heycam
<dael> heycam: There was example at end of issue that had scroll linked animations effecting color. Color animations don't fall into same category of effects that cause problems. Should we have a way to allow or distinguish between non-movement animations?
<dael> heycam: If we have the intervention we wouldn't want to cut off those
<dael> flackr: Yes, we could define property set that is capable of introducing motion and only change interp type of those properties
<dael> flackr: Since you would be changing it for all motion properties it shouldn't create inconcsitencies in the animation b/c could have dependent motion properties
<dael> heycam: May be possible to select the set of properties, but may need thinking
<dael> astearns: May be simplier to find the properties that would not create motion
<dael> dholbert: Animated a variable as line height and rgb, would that be inconsistent? Only clamp in one case
<dael> flackr: You would
<dael> TabAtkins: Variables would be clamp by default because you don't know where they're used
<dael> astearns: Makes sense. Also thinking about custom properties defined in JS and we would turn those off b/c don't know what used for
<dael> astearns: Hearing a fair bit of interest in getting this worked out. Looking for resolution to proceed on working on this?
<dael> flackr: Yes, wanted a path forwrd. If this is promising direction. I noticed you mentioned scoll linked animations.
<dael> astearns: I've heard agreement it's for all animations. Any disagreement on all?
<dael> astearns: Prop: We are going to start specifying a no motion at all mode that makes motion inducing animations discrete between keyframes where keyframes are sufficiently separated in time
<dael> astearns: Obj?
<dael> RESOLVED: We are going to start specifying a no motion at all mode that makes motion inducing animations discrete between keyframes where keyframes are sufficiently separated in time
<dael> astearns: Also want resolution on adding a MQ for this?
<dael> astearns: or wait on that until further along?
<dael> flackr: I think it's not blocking but would be nice for devs to be able to respond. Could be deferred.
<dael> astearns: Let's defer. We will have better use cases for MQ once this new mode is mapped out

I fear this comment may be of larger scope than this discussion. If so, my apologies, as I am having difficulty separating out the various threads. The discussion does seem to spill into the big picture, so I will at least not be the first.

If there are any essential animations, I would rather interact with them through a play/pause button rather than through scrolling, which is much harder for me to control reliably and which, if I am actually on my way to do something else unrelated to the animation, may interfere with my getting to that other place safely. I would rather not deal with cosmetic animation at all.

Details follow:

@argyleink wrote:

prefers reduced motion IS NOT prefers no animation

Actually, the preference wording varies by OS. I'm concerned that too much is being read into the "prefers" wording, which I suspect was chosen as an accident of history.

macOS and iOS use the wording "Reduce motion" and as early adopters of this feature were likely the drivers of the wording prefers-reduced-motion being adopted. This is my conjecture. I do select it and only because they do not make a "Remove motion" preference available.

In Windows 10, the preference reads "Show animations in Windows" which does imply no animation to me if it is set to off. While it does read "in Windows" and not "in apps," this is the preference that Chrome and Firefox use to determine whether to match the prefers-reduced-motion media query.

Android's preference reads "Remove animations," which also seems to imply no animations. However, the explanatory text reads "remove some screen effects".

The Windows 10 and Android terms are unfortunately vague as to whether they mean all animation or only motion animation. And that said, I would find some color animations distracting. I do not wish to conjecture whether they would make some people ill.

Speaking as someone who is often distracted by animations and who can be sickened by them, the ideal behavior for me of a non-granular prefers-reduced-motion, which is currently available, or forced-reduced-motion, which I believe is not, media query would be:

For a cosmetic animation, don't render. Jump immediately without animation to the end state.
For an instructional or illustrative animation, don't autoplay; do render a play button which will allow playing the animation at the user's request. Allow pausing and possibly speed control. Of course, the play button would need to be triggerable by click, tap, or keyboard navigation. If these are triggered by scrolling, perhaps not use scrolling as the trigger for reduce motion preferences.
For an animation with essential keyframes, again don't autoplay; perhaps a Next button? Or step one keyframe at a time with each scroll? Just don't do it with motion.

[removed comments on loading animations as off-topic]

I recognize that I do not represent all people impacted by animation.

One area that I think we didn't cover in the meeting is how to still empower developers who have made reasonable choices for devices which prefer reduced motion. I propose that we should consider this similar to support of dark mode. I.e. we should have a concept of whether the page supports reduced motion, similar to which color schemes it supports, and when the site supports reduced motion it would still be allowed high fidelity animation.

In sites which do not explicitly support reduced motion, we could apply interventions deemed appropriate to reduce the motion of the site (e.g. the above proposed intervention and/or immediately finishing time-based animations).

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!)

I’m not sure this is true of all users with vestibular disorders, but for me, motion that I control (via scrolling) is much less troublesome than motion that happens on its own. Perhaps it is similar to being a driver versus a passenger in a car? I’m much more likely to get sick as a passenger. (And yes, I am the PM for animations on Chrome and I have a vestibular disorder!)

We’ve been doing some research to address the points that Alice made. And it seems like there is a tradeoff between visibility of content (is all the content visible?) and motion accessibility (is any of the content moving in ways that could trigger vestibular disorders?)

Today, prefers-reduced-motion empowers developers to define reduced motion for their animations. The browser doesn’t intervene on the user’s behalf, so a benefit is that content visibility is not impacted. The downside is that developers need to code reduced motion versions of their animations.

We explored what it would look like for the browser to take a more active role by providing more strict motion reduction for animations when users don’t want any motion. Unfortunately, in some cases, forcing reduced motion made content invisible.

We tried 7+ options in this demo (polyfilled). We’ve identified two options for reducing motion that may be technically feasible, TBD if they are good for users:
- No animations
- Nearest keyframe animations
Both options listed above will sometimes make content invisible, so we don’t think we should force reduced motion for scroll-linked animations as a part of prefers-reduced-motion. We don’t want to break the web. For example, if motion reveals content or motion connects pieces of related content. Like an image and text are timed to line up at the right moment, letting a user know they are connected.
We still think it is worth exploring if animation motion can be reduced automatically by the browser as a part of a new user setting. It would need to be expanded to all motion and not just scroll linked animations. Cynthia Shelly’s team will take that exploration on. However, Alice’s point stands, it might be difficult to explain to users the difference between prefers-reduced-motion and force-reduced-motion. User Research on that issue could be part of the exploration
- It would also (unavoidably, we think) make content invisible, so users would need an easy way to switch between modes.
- We figured this issue is probably not the best place to kick off the larger discussion about forcing reduced motion, so we opened another issue around questions like:
  - WCAG techniques/failures
  - Media query for forced-reduced-motion So in summary, the accessibility story for scroll linked animations is prefers-reduced-motion. It can be used today to follow accessibility guidelines for reducing motion (example), and we're also interested in exploring whether a forced reduce motion feature is useful and feasible.

We’ll also look into submitting a WCAG technique, similar to this MDN article.

@cookiecrook I've been working with @stubbornella and @flackr on this proposal. What do you think?

w3c / csswg-drafts

[scroll-animations] TAG feedback: interaction with prefers reduced motion #5321