No-motion / forced-reduced-motion issue draft

The TAG review of scroll linked animations identified an existing issue that without explicit developer support, animations with motion on the web do not respect a user's desire to reduce motion. We explored many options for reducing motion but found that it was not possible to automatically reduce motion without sometimes making content invisible. We still feel it is worthwhile exploring whether we can forcibly reduce or remove motion with a new user setting. From our demo we came up with at least two feasible options to force motion reduction, though we are open to exploring others:

Not running animations.
Stepping between key points of animation.

We propose adding a new setting for users to elect to forcibly reduce motion, possibly breaking content in the same way that other existing settings such as disabling images or Javascript does and exposing a media query value for when this setting is on so that developers can provide a fallback variant.

Thank you for opening this issue. Writing as an individual who is impacted by unsolicited animation from vestibular disorder, attention deficit and hyper-vigilance, I would welcome a force-reduced-motion feature. I would prefer the Stepping between key points of animation over Not running animations, as I do not want to lose content, only the animation.

Pain points for me over and above the ones already identified are:

Animations which I have not initiated through a play button and which thus surprise and distract me, taking attention away from the page content
Forced smooth-scrolling JavaScript overriding my browser settings to not smooth-scroll.
Certain pages behave unpredictably (jumping to an unexpected point on the page) while in the process of reading a single page. I often switch intra-page between navigating a page using the scroll bar (both dragging or, more often, clicking near the top or bottom), my pointing device's scroll wheel, page up/down keys, and arrow up/down keys. I encounter this issue with random websites on a regular basis. While this is not directly an animation issue, I imagine that the same causes of this behavior would also interfere with solving the issue of invisible content on forced reduced animation. At the very least, I respectfully suggest that testing of force-reduced-animation include testing with varying the ways of scrolling a page during a single page visit.

I'm wondering if we should handle this at a more granular level, rather than page-wide.

E.g. startViewTransition() might be defined turn off the transitional rendering and just create an instant view change when a user has prefers-reduced-motion (https://github.com/WICG/view-transitions/issues/19#issuecomment-1226141044), but have an optional argument that allows overriding that auto-shutoff. That way the author can override one particular transition, without opting the whole page into “I have adapted appropriately let me do anything I want” mode.

We could consider this type of override for other types of transitions and animations also. Then for each individual effect, the author can opt to keep the motion, or let it get shut off by the UA, or change out and simplify the motion based on a prefers-reduced-motion MQ.

See also discussion in https://github.com/WICG/view-transitions/issues/19

The CSS Working Group just discussed No-motion / forced-reduced-motion issue draft, and agreed to the following:

RESOLVED: Adopt the general path forward of allowing more granular animation control, Rob will write proposed explainer for it

The full IRC log of that discussion

<emeyer> flackr: In TAG review, we determined they were going to cause a lot of full-page animations
<emeyer> …There’s concern that we have a query for reduced motion, but there’s interest in a UA policy to shut off animation
<emeyer> fantasai: We could shut off all animation forms, but people want a way to override that
<Rossen_> q?
<PaulG> q+
<emeyer> …Don’t think we should have it at a page level
<emeyer> …If we want the ability to override a forced shutdown of all animations, we need to provide it on a granular level
<emeyer> flackr: Would this be per element?
<emeyer> fantasai: Per animation
<emeyer> flackr: So we’re talking about a new property?
<emilio> q+
<emeyer> fantasai: We might not want the author to be able to override the UA, but if we do, it shoudl be per animation.
<emeyer> …This would mean adding some kind of way to set this for each animation
<flackr> q+
<Rossen_> ack PaulG
<emeyer> PaulG: It sounds like developers in commercial and ad spaces will put !important on all their animations, leading to a back-and-forth war between devs and users. I don’t love the idea of overrides.
<Rossen_> ack emilio
<emeyer> emilio: For users who do this, what I’ve seen user stylesheets set animation: none
<emeyer> …I guess that doesn’t work with web animations, but we could make it work with a user setting to ban web animations
<jensimmons> q+
<emeyer> …I don’t feel great about a per-animation switch
<emeyer> …This seems somewhat similar to forced-colors, perhaps we could use a similar approach here
<Rossen_> ack flackr
<jensimmons> q-
<emeyer> flackr: Even though this opens the door for authors to override, they can already do it in JS, and in a worse way
<fantasai> scribe+
<TabAtkins> emeyer: If there's a property that allows authors to turn on animation, won't they just override it for every animation?
<fantasai> emeyer: If there's a property that lets authors disable per-animation, wouldn't they use a universal selector to override for every element every animation?
<PaulG> q+
<TabAtkins> q+
<emeyer> emeyer: If this is done with a property, won’t authors just override with a universal selector or something?
<jensimmons> q+
<emeyer> flackr: Won’t they use GSAP or something?
<Rossen_> ack PaulG
<TabAtkins> More generally, we have similar "let me handle this manually" properties in a few places and trust people to use it responsibly.
<emeyer> PaulG: People with serious disorders or epilepsy will disable JS. It would be better for them if they can disable CSS animations.
<emeyer> …If they can’t shut off CSS the same way they can JS, they have less control
<Rossen_> ack fantasai
<emeyer> fantasai: If we do this declarative way, that allows the browser to have different levels of policy. One could be force all animations off, another force off unless overridden. We can allow that explicitly.
<emeyer> …There was a suggestion at proposal time to set a level and let users set it in the UA.
<emeyer> …If someone wants to behave badly, they can always go to JS. With the CSS approach, authors will have to confront their decision to override accessibility concerns.
<emeyer> …It is a little bit different from normal ad wars, I think
<emeyer> TabAtkins: We have other properties where we let authors explicitly opt into handling things manually, and trust they’ll be used when necessary and good
<fantasai> s/unless overridden/, and a third could be force off and ignore overrides/
<emeyer> …As a general rule, our policy seems to be to let people opt out on individual levels when there’s a good reason
<Rossen_> ack TabAtkins
<Rossen_> ack jensimmons
<emeyer> jensimmons: Part of the complexity is people have different needs for levels of motion, and a boolean doesn’t work
<fantasai> s/set a level and let users set it in the UA/allow a force-off, but allow authors to override with a switch/
<flackr> q+
<emeyer> …A lot of people want or need to turn off extreme or fast animation; a designer might do that stuff because they think that’s cool
<flackr> q-
<emeyer> …users who don’t want extreme animation might want small animations
<PaulG> https://www.w3.org/TR/adapt-content/ provides levels of importance in animation
<emeyer> …I’m for something that will let authors deal with this kind of nuance
<emeyer> …If we can also have a switch for users who need no motion at all, that would be an ideal way to go
<Rossen_> q?
<emeyer> flackr: From what I hear, there’s general support for this idea, which is good. Let’s put together a more concrete proposal and bring it back to the WG
<jensimmons> We should design CSS to work the way we want, to provide the result we want, and not rely on a dependency on JS. CSS itself should be well defined as a language, and we don't want to require Authors to use JS to handle animation motion properly.
<emeyer> fantasai: I think this should be a standalone for now, but this will have to integrate into animation, scroll-animations, web animations, transitions, [a couple more the scribe missed]
<flackr> q+
<emeyer> flackr: We have a bit of flexibility because these are delcarative to split apart whether the anio9mation is motion-inducing or not. Is there an appetite to distinguish those from opacity and so forth?
<Rossen_> ack flackr
<emeyer> PaulG: If you look at the adapt-content document, they talk about levels of distraction. The more descriptive we can get, the better.
<emeyer> s/anio9mation/animation/
<emeyer> RESOLVED: Adopt the general path forward of allowing more granular animation control, Rob will write proposed explainer for it

See Official Minutes

Was there discussion of a new forced value on the existing prefers-reduced-motion media feature? If for no other reason, it would keep the Boolean match working.

At the time of that media feature proposal, we discussed other future granular values, including forced values.

@cookiecrook I'm not sure it was explicit, but I was assuming that we'd add such a value, yes.

Asking because the minutes aren’t clear on how a “new property” would interact with the the existing MF.

For example, if the UA disabled image based animations (e.g. GIFs), or dropped all interstitial key frames in CSS animations/transitions, would the property affect all of the above? Why should an author be able to override a user safety feature?

@cookiecrook Thanks for bringing that point up.l The author shouldn't be able to override a user safety feature.

As a vestibular sufferer & researcher, the best solution is snapping to the finished state with no transition or keyframes.

@nattarnoff wrote:

The author shouldn't be able to override a user safety feature.

I agree.

the best solution is snapping to the finished state with no transition or keyframes.

I'm not convinced of this statement re: "best solution" to fit all needs, though that'd certainly be a reasonable implementation, and if the user desires transition snapping, great.

A detail you may not be considering is that many humans will miss single frame transitions. I notice this whenever I'm subjected to bullet point slide decks; often I blink and don't immediately realize we're on a new slide.

Another implementation that may be able to achieve the same benefit (no vestibular discomfort) while still getting the user to acknowledge meaningful transitions could be to compute a non-moving dissolve transition between the starting state and ending state.

Effectively a dissolve (aka cross-fade) where previously there had been a zoom or pan that could be a vestibular trigger.

@cookiecrook In this case "best solution" is based on not having the granular control in prefers-reduce-motion. If we had to make a call on what prefers-reduce-motion does in these cases, it is better to account for the edge scenarios knowing that will work for those less severe. But we don't have to be so strict. The key is to make the transition feel instant for those who have motion based issues. So instead of a 5 second transition, we do something below half a second. Anything that can happen in under 100ms will feel instantaneous and most likely not affect most motion sensitive users.

The syntax of prefers-reduce-motion was designed to allow more granular control if needed... Future values could be added... Cite: stop-all value in https://github.com/w3c/csswg-drafts/issues/5594#issuecomment-724308217 or forced-no-motion value in https://github.com/w3c/csswg-drafts/issues/442#issuecomment-265206909

So it still matches the boolean context, but in this case, the implementation can change what's rendered/animated instead of leaving it up to the author. (Note: the "implementation can change what's rendered/animated" is still a hard problem IMO.)

Mac's "reduce motion" is analogous to its "increase contrast" in that it's adjusted, but not to extremes… Where Windows' "Stop Animations" pref could be more analogous to its [forced and often extreme] "high contrast" settings.

For the prefers-contrast media feature, we changed it to prefers-contrast: more; to account for variance, and future potential values like high which do not match the Mac implementation but could someday. The more value or boolean @media (prefers-contrast) would both evaluate to true for the Window's high contrast.

I think something similar could be done for any forced motion changes.

https://www.w3.org/TR/adapt-content/ provides levels of importance in animation

I'm sorry, I must be missing it. Can you clarify which part of the document has levels of importance in animation?

I've put together an updated explainer with a possible proposal at: https://github.com/flackr/reduce-motion

After having given this some thought, I'm wondering if we could re-use the existing media query support and automatically annotate animations declared within a reduce motion media query to be supporting of reduced motion. This would reduce the syntactic overhead for authors not having to think about a new property. We would of course still need such a property in the web animations API but it could be a hidden internal value in CSS for both transitions and animations, e.g.

@keyframes pulse {
  from { transform: none; }
  to { transform: scale(15%); }
}

.attention {
  animation: pulse 1s infinite alternate;
}

@media (prefers-reduced-motion) {
  @keyframes outline {
    from { outline: 2px solid red; }
    to { outline: 2px solid orange; }
  }
  .attention {
    /* This animation would be implicitly marked as supporting reduce motion
       as it has been specified inside an @media query matching prefers-reduced-motion: reduce */
    animation: outline 1s infinite alternate;
  }
}

Edit: If we don't want to use the media query implicitly, it would probably need to be a new property for animations and transitions - e.g. animation-motion / transition-motion with values normal | reduced to reflect whether the animation defined supports reduced motion. It feels a bit redundant to have to specify this when you're in a media query block for reduced motion but could be flagged by developer tooling.

When we forcibly reduce motion (for those normal animations) I think we should do so by disabling smooth interpolation rather than completely removing animations, as their animated values may be critical to the usability of the page.

The CSS Working Group just discussed No-motion / forced-reduced-motion issue draft.

The full IRC log of that discussion

<fantasai> flackr: I didn't add this to agenda, was already agenda+
<fantasai> flackr: where we left off, we thought it would be valuable for the UA to reduce motion on websites
<fantasai> flackr: in a way that didn't require developers to do extra work to make it just work
<fantasai> flackr: we previously, in december, talked about a global strategy where there would be some meta tag to say whether site had support for animations reduction
<fantasai> flackr: decided later to make it a per-animation toggle
<plinss> Whoever edits the minutes, fell free to put above comments on the record
<fantasai> flackr: only development since has been putting together a straw man proposal of an animation/transition/WA property
<fantasai> flackr: to say whether the animation has been written to support reduced motion
<fantasai> flackr: UA could use this to implement reduced motion
<fantasai> flackr: I was going to put together examples
<fantasai> flackr: asking around for thoughts
<smfr> q+
<TabAtkins> fantasai: the idea is to tag a partiuclar animation as being conformant with reduced-motion or not
<TabAtkins> fantasai: then if the author wants to change which animations to do they'd use an MQ?
<TabAtkins> flackr: yes
<TabAtkins> flackr: don't really like it since in the worse case you're specifying reduced-motion twice
<TabAtkins> flackr: But as said earlier today we don't want MQ matching to affect how we process rules
<TabAtkins> fantasai: this seems pretty reasoanble to me actually
<astearns> ack smfr
<TabAtkins> smfr: I want some backgroudn what UAs do when the user turns on reduce-motion
<TabAtkins> flackr: to my knowledge, it's currently entirely on the dev to give a reduced motion experience
<ntim> q+
<TabAtkins> smfr: are you suggesting a world in which UAs suppress all animatios not tagged with this new property?
<TabAtkins> flackr: yes, it's still unclear how thsi would work o nthe platform - a different mode, or waht
<TabAtkins> smfr: I do think it's a valid concern and important
<astearns> ack fantasai
<TabAtkins> fantasai: so you're tagging the @keyframes? or what?
<TabAtkins> fantasai: is there a way to sipmlify some things and say "this animation gets dropped if you're in reduced-animation"?
<TabAtkins> flackr: we could drop animations that haven't been marked as supporting reduced mode
<TabAtkins> flackr: but then it would be backwards incompatible break
<TabAtkins> flackr: it would break the experience of users who have this option turned on
<TabAtkins> fantasai: the opposite, the author saying in the tag that "this animation is optional"
<TabAtkins> hober: the author can already do that with an MQ
<ntim> q-
<TabAtkins> fantasai: They have to do it on each animation property tho.
<TabAtkins> hober: Ah so this is sugar
<TabAtkins> fantasai: basically
<ntim> q+
<TabAtkins> flackr: whether this is sugar or not gets into what we do with animations in this mode
<nicole> q+
<TabAtkins> flackr: view/scroll animations often display infomration so they can't be ignored
<TabAtkins> hober: so are you saying that this wouldn't have any effect on scroll-linked?
<TabAtkins> flackr: it would change the interpolation behavior, but it wouldn't drop them, yeah
<TabAtkins> flackr: but if this is fully opt-in then it might be safe to just drop things
<TabAtkins> flackr: But with an opt-in we're not solving the appraoch that authors aren't thinking about it
<TabAtkins> myles: i'm confused
<TabAtkins> astearns: I think i'm hearing we have two options
<TabAtkins> astearns: The first is rob's original idea: people can tag animations that say 'this is okay for reduced motion'.
<TabAtkins> astearns: Second is... wait i'm confused
<TabAtkins> flackr: Two options are: 1) UA turns off all aniamtions that aren't tagged as supporting.
<TabAtkins> flackr: 2) make it easy for authors to declare animations that can be skipped
<TabAtkins> myles: So right now websites have all animations. They can use the MQ to turn off specific ones.
<smfr> q+
<TabAtkins> myles: Sounds like you want the opposite, off by defualt (in reduced-motion mode) and they can turn specific ones back on
<TabAtkins> flackr: yes, because most authors aren't thinkinga bout reduced-motion
<astearns> ack ntim
<TabAtkins> flackr: so the option really isn't doing anything
<TabAtkins> ntim: a concern with this appraoch is fingerprinting
<TabAtkins> ntim: the JS could detect whether you're in forced reduced motion or not
<TabAtkins> hober: Which is 1 bit more than just preferring reduced motion
<TabAtkins> flackr: yes, they can detect if you're in prefers-reduced today; if this is a separate mode it would be detectable as well
<TabAtkins> nicole: Rob could you show the demo with the 14 different ways we tried to force reduced motion?
<astearns> ack nicole
<TabAtkins> nicole: the goal is great, we want people who want reduced motion to get it
<TabAtkins> nicole: but the reality of doing it in a forced way is just very complicated
<flackr> There's a demo at https://flackr.github.io/reduce-motion/demos/phone/ exploring some automated interventions
<TabAtkins> nicole: our example was apple homepage, a device slid in fro one side and words from the other and they met in the middle to connect them mentally
<myles> q+
<TabAtkins> nicole: that's why rob said scroll-driven was hard to turn off, getting them to arrive together is v important
<TabAtkins> nicole: i'm someone who gets nauseated with animations, and if I can control the animatio like with scroll it's much easier for me
<TabAtkins> nicole: so form a personal angle, scroll-driven is less bad for me than normal animations
<TabAtkins> nicole: But I also don't really turn on reduced motion, because a spatial sense is often an important part of navigating
<TabAtkins> nicole: Lots of infomration from motion
<TabAtkins> nicole: This issue deserves a lot of thought and care
<TabAtkins> nicole: maybe no-motion is a hard a11y setting where some breakage is okay and worth it
<jensimmons> Same. I don't turn off animation, because I want it much of the time. And for me, when the animation is in reaction to my actions, it doesn't bother me. What is really hard to take are animations that loop over and over and over without any input from me.
<TabAtkins> nicole: but hard to picture it's an everyday feature people browse with, considering how much would break
<astearns> ack smfr
<TabAtkins> flackr: i think of it as similar to disabling JS
<TabAtkins> smfr: I'd be concerned that turning off anims isn't web-compatible.
<TabAtkins> smfr: like a fill-forward animation that puts something in place
<TabAtkins> smfr: so not turn them off, maybe, but snap them to their final state
<TabAtkins> flackr: exactly that, yes
<TabAtkins> nicole: we tried a lot of options yeah, most were terrible
<TabAtkins> smfr: one issue is different users have different issues with animations.
<TabAtkins> smfr: so maybe the UA needs to decide what the user wants and the author doesnt need to know
<TabAtkins> myles: a lot of animatios are driven by rAF(), too, and we can't turn those off
<TabAtkins> myles: so you end up in a situation where some animatios are turned off and some aren't
<TabAtkins> nicole: which will drive people to move their animations to JS
<TabAtkins> flackr: yes, this convo has been had several times o the TAG issue, i'm trying to find a path forward
<TabAtkins> flackr: hope is that we can find a path that doesn't break sites
<astearns> ack myles
<TabAtkins> (the "tag the animation as okay" thing avoids the "move to rAF()", right?)
<TabAtkins> fantasai: I wonder if having multiple ways for authors to get around this, like tag your animation as what kind of animation it is
<TabAtkins> fantasai: it won't solve the case of authors that aren't thinking about it, but lets us get some reduced motion without having to go thru all animation properties or rearchitect styles
<myles> q+
<TabAtkins> fantasai: so tagging your animations and request handling by the UA
<TabAtkins> astearns: like tag it with something telling the UA how to adapt it to reduced motion?
<TabAtkins> fantasai: yeah, like dro pit entirely, or skip to end, or jump to each discrete keyframe
<TabAtkins> fantasai: so like slides can show each keyframe but lose the animation between them
<smfr> s/dro pit/drop it/
<miriam> +1 fantasai's proposal (as an author)
<TabAtkins> fantasai: so if the author can tell us that, the UA can intervene in the way best suited
<florian> q?
<TabAtkins> fantasai: I think a lot of your experimentation could inform what interventions are useful
<TabAtkins> fantasai: the actions that were reasonable sometimes, even if they wern't good for everything
<florian> q+
<TabAtkins> astearns: And that could be compatible with the UA choosing something, and the author overriding
<florian> q-
<astearns> ack myles
<TabAtkins> myles: i think i'm letting perfect be enemy of good
<TabAtkins> myles: fundamental problem is authors don't consider reduced motion
<TabAtkins> myles: i'm suspicious that the solution is add mor eknobs
<miriam> q+
<astearns> ack miriam
<TabAtkins> miriam: as an author who often thinks about it but wants better defaults
<TabAtkins> miriam: right now i have to build them myself. jump to end isn't simple, i ahve to set it up myself manually
<TabAtkins> miriam: a lot of resets include a jump-to-end keyframe set that's added for you; it doesn't always work
<hober> q+
<TabAtkins> miriam: if there was a qicker way to do it people would use it
<TabAtkins> miriam: not everyone, and it doesn't solve everything, but these shortcuts would be really useful
<astearns> ack fantasai
<TabAtkins> fantasai: +1 to that
<TabAtkins> fantasai: If we improve ergonomics it'll get used a lot more
<TabAtkins> fantasai: and if you shift responsibility from invoker to provider of keyframes, you can put it into libraries
<TabAtkins> fantasai: authors can use a predefined library of animations, with fallback instructions built in, only needs to be done once
<TabAtkins> miriam: also if we've done the research and have a good sense of what the solutions are, if i as an author see a list of three good solutions that are semantic to particular situations
<TabAtkins> miriam: like skip-to-end is good for content flying in...
<TabAtkins> miriam: if I know those are the options i have a better sense of why i would use them
<TabAtkins> fantasai: you could also use the same mechanism to indicate something is important, so keep it even if animations are turned off
<astearns> ack hober
<TabAtkins> hober: in general im' sympathetic to this general appraoch of lettings authors sprinkle declarative animation that UAs can use to improve the UX
<TabAtkins> hober: in this case i'm worried about a few things
<TabAtkins> hober: tim mentioned 1bit of fingerprinting
<TabAtkins> hober: but depending on diversity of impl behavior it woudl easily be several
<TabAtkins> hober: if there's a gradation of settings for how muc hanimation you want suppressed
<TabAtkins> hober: from authoring perspective, if there's hints that don't do anything obvious, you often run into situations where authors develop cargo-culty behavior
<TabAtkins> hober: they just add something they were told is a best practice
<astearns> q+
<ntim> +1
<TabAtkins> hober: so over time the quality of the signal declines, and interventions that were initially good have to be thrown out
<TabAtkins> hober: so I'm concerned if we game it out a few steps if we actually make an improvement
<astearns> ack fantasai
<astearns> ack astearns
<TabAtkins> astearns: could we make this not detectable, skip the animation but make it seem to JS that it does run?
<TabAtkins> dbaron: no
<TabAtkins> astearns: ok
<TabAtkins> fantasai: One way to avoid is to provide a "simulate reduced motion" mode where it shows the effects
<TabAtkins> fantasai: so from the privacy aspect, maybe a UA would want multiple levels, but we know of 2 right now
<miriam> q+
<TabAtkins> fantasai: at the very least we could make "reduced" better for authors to hook into
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<TabAtkins> fantasai: if devtools is helping to simulate that mode, then you can epxerience what that user would see and you're less likely to pick a bad hint
<nicole> q+
<TabAtkins> fantasai: this might not fully solve the problem and we still might want to force things, but i think making it easy to get some type of result would help the situation
<TabAtkins> flackr: there's already an option for that in chrome
<TabAtkins> flackr: this discussion was helpful. the TAG said they wanted something that devs didn't have to interact with at all, but here it sounds like we want something that lets athors help.
<TabAtkins> flackr: So we can still have the MQ, and then also make some properties that let authors help out.
<TabAtkins> flackr: like animation-interpolation-mode or something like that. but i dont' want to propose just yet.
<fantasai> I would propose "reduced-motion: <keywords>"
<astearns> ack miriam
<TabAtkins> miriam: I think Tess makes a good point, but I'd say the cargo cult already exists
<fantasai> Where keywords is things like "drop" or "skip" or "discrete" or anything else we think up
<TabAtkins> miriam: a big chunk of keyframes that do one thing and do it poorly. providing a better tool ameks it more likely people use the right thing
<TabAtkins> nicole: generally i like personalization issues. have to be aware that it puts a burden on author testing
<TabAtkins> nicole: it gets combinatorial
<TabAtkins> nicole: so we need to be thoughtful. i like the idea of skip-to-end, etc
<TabAtkins> nicole: just need to be thoughtful about burden we put on devs
<fantasai> And where "reduced motion" is something you can declare inside @keyframes
<fantasai> or inside a single keyframe
<TabAtkins> astearns: think we'll leave the discussion here and keep working on it
<TabAtkins> flackr: this is a change in direction, nicely concrete. i can come up with more details around this

CSSWG explored the idea of allowing authors to tag animation keyframe sets for reduced motion (see minutes above), so that the UA can know the best way to adjust that particular frame set. Options could some of the explorations @flackr has been doing, e.g.

skip to the end
drop the animation and use underlying styles
step through keyframes with no transition
cross-fade between keyframes (either throughout the gap between them, or for a short period stepping up to the next frame)
don't change the animation, this one is important / already adjusted for reduced motion

Authors could use the media query to make additional adjustments to animations, but this would allow simple adjustments to be made in the keyframe set so that whenever it is referenced it will have the adjustments built in.

Thinking about it some more, being able to substitute the easing curve (without rewriting all the frames) might also be a useful ability.

... And also, when this spec is drafted up, we should include a lot of really good examples of different use cases and show appropriate adjustments for each, so that developers can understand how to use them. And/or publish a separate NOTE that walks through examples and shows best practices together with their code and rendering, which can be easily referenced from reference documentation such as MDN.

Reminder that it's not just VIMS but also hyper-vigilance. Any animation disrupts my train of thought, not just potentially makes me ill.

Ideally, the user agent would allow the website visitor to choose the animation remediation method that they prefer rather than the browser manufacturer making the decision for them:

skip to the end
drop the animation and use underlying styles
step through keyframes with no transition (include being able to set limiting the number of keyframes and setting the minimum time for each key frame to display)
cross-fade between keyframes
don't change the animation, this one is important / already adjusted for reduced motion (letting the website visitor choose that they don't want the animation to display unless they actively click a play button)

A potential issue with step through key frames would be that a website developer can specify an arbitrarily large number of key frames.

With regard to don't change the animation, this one is important, I still don't want it automatically playing. I specifically want to click a play button. Automatically playing animations are disruptive to me.

I read the log and, as mentioned, different people have different sensitivities. Unlike a couple folks quoted in the log, I am very much triggered by scroll-based animation and it will cause me to leave a website.

One thing that was not mentioned and maybe even need to be a different Github issue is a matter of background animations, which generally occur in the form of a video. Again, these cause me to need to leave a website.

w3c / csswg-drafts

No-motion / forced-reduced-motion issue draft #7440