W3C home > Mailing lists > Public > public-css-archive@w3.org > January 2021

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

From: Adam Argyle via GitHub <sysbot+gh@w3.org>
Date: Tue, 26 Jan 2021 18:53:42 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-767754077-1611687220-sysbot+gh@w3.org>
I've been recently using `@scroll-timeline` with motion reduction and found I had all the control I needed, [see demo](https://gui-challenges.web.app/tabs/dist/). 

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%);
        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. 

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 26 January 2021 18:53:44 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:25 UTC