[scroll-animations] TAG feedback: interaction with prefers reduced motion #5321
Comments
|
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:
|
|
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 However, there are parallels you can draw the the 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 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
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
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 The full IRC log of that discussion |
|
I mentioned in the call today that I would link to some older discussions about more granular syntax for From December 2016:
From August 2020:
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.
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 |
|
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 |
|
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 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
The full IRC log of that discussion |
|
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:
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:
[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). |
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’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? |
fantasai
added
the
a11y-tracker
Here is a question/feedback from TAG. The original is here but I am creating this issue to track this in CSSWG as well.
The text was updated successfully, but these errors were encountered: