Respecting prefers-reduced-motion on Animated Sites

For a meaningful group of users, including people with vestibular disorders, large on-screen motion is not a style preference but a physical problem: it can cause genuine dizziness and nausea. Every major OS ships a reduce-motion setting, and an animated site that ignores it is broken for those visitors.

What should change under reduced motion?

• Remove: parallax, pinned scrub storytelling, horizontal scroll sections, zoom and rotation effects, smooth-scroll libraries like Lenis.
• Replace: slide and rise entrances become plain opacity fades.
• Keep: color and opacity transitions, focus states, anything essential to understanding the interface.

The goal is equivalence, not punishment. The reduced experience should present the same content in the same order, just without the choreography.

The clean way to implement it in GSAP

gsap.matchMedia() is built for exactly this. Register your full animation set inside mm.add('(prefers-reduced-motion: no-preference)', ...) and a minimal fade set inside mm.add('(prefers-reduced-motion: reduce)', ...). GSAP handles setup and teardown automatically, including when the user flips the setting while the page is open. This beats scattering if-checks through your code, because every animation is guaranteed to live inside one branch or the other. All of our templates ship with this fallback wired in, and both Scroll Animation Mastery and the accessibility section of Premium Website Masterclass treat the reduced-motion branch as part of the definition of done, not an optional extra. It is also less work than it sounds: a site with well-organized animation code can usually add a complete reduced-motion branch in under an hour, and it is easier still when planned from the start.