Re: [csswg-drafts] [scroll-animations] TAG feedback: interaction with prefers reduced motion (#5321)

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 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*.

GitHub Notification of comment by alice
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 15 September 2020 01:34:23 UTC