- From: Adam Argyle via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Jan 2021 18:53:42 +0000
- To: public-css-archive@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. ```css @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): ```js 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