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

> 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](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/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](https://flackr.github.io/reduce-motion/demos/phone/) (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](https://github.com/w3c/csswg-drafts/issues/7440) 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](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion#result)), 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](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion).

-- 
GitHub Notification of comment by stubbornella
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5321#issuecomment-1171522701 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 30 June 2022 18:04:55 UTC