prefers-reduced-motion Demo — Free HTML CSS JS Snippet

Motion on the web isn't just decorative — for a meaningful share of users it's a genuine barrier. People with vestibular disorders, migraine conditions, or certain forms of motion sensitivity can experience real physical symptoms (dizziness, nausea, headaches) from parallax scrolling, spinning loaders, sliding transitions, and other animated UI. The prefers-reduced-motion media feature, part of the CSS Media Queries Level 5 spec, lets users declare this preference once at the operating system level (macOS: Accessibility > Display > Reduce Motion; Windows: Settings > Accessibility > Visual Effects > Animation Effects; iOS/Android have equivalent toggles) and have every website that respects the media query honor it automatically, with zero site-specific configuration.

The critical constraint this demo is built around

There is no JavaScript API to change a user's OS-level motion preference — and there shouldn't be, because it's a system-wide accessibility setting the user controls once, outside any individual website's authority. The only thing JavaScript can do is read the current value via window.matchMedia('(prefers-reduced-motion: reduce)').matches, which returns true or false reflecting the live OS setting, and optionally subscribe to future changes with matchMedia(...).addEventListener('change', callback) if the user toggles the OS setting while the page is open. This snippet makes that constraint explicit and honest: the toggle switch you interact with does not touch the real setting at all — it only adds and removes a .reduced-motion class on a wrapper element, purely to simulate, for teaching purposes, what your real production CSS should do automatically via a native @media block. Meanwhile, a separate readout at the top independently reports your browser's actual, live matchMedia() result, so you can compare the simulation against ground truth.

How real production code should be structured

In a real site, you would never rely on a JS-driven class toggle to reduce motion — you'd write the reduction directly into your CSS using the media query itself: @media (prefers-reduced-motion: reduce) { .spinner, .slide-card, .badge { animation: none; } }. The browser evaluates this at the OS level with zero JavaScript required, applies it before your JS even runs, and updates live if the user changes the setting while your tab is open, exactly matching how any other media query (like prefers-color-scheme for dark mode) behaves. This snippet's .reduced-motion class rules are written as a deliberate stand-in for that media query, using an identical rule shape, so that flipping between "read the real API" and "simulate the CSS effect" is a one-line change in a real codebase: swap the class selector for the media query and delete the toggle.

Why full removal of animation isn't always right

The WCAG 2.3.3 (AAA) success criterion and general best practice recommend reducing rather than always fully eliminating motion — replacing large, sweeping transforms with subtle opacity crossfades preserves perceivable state changes (like "this loading indicator is active") without the vestibular trigger of large-scale movement. This demo takes the simpler, fully-off approach for clarity (animation: none), but production code often swaps a spin/slide keyframe animation for a gentler opacity pulse instead of removing feedback entirely, so users still get a sense that something is happening.

What the three demo elements represent

The spinning loader represents infinite-loop UI feedback (loading spinners, progress indicators) — a common vestibular trigger because of its continuous rotational motion. The sliding card represents transform-based transitions (carousels, tab switches, drawer animations) — large translateX/translateY movements are specifically called out in accessibility guidance as high-risk. The pulsing badge represents scale/opacity "attention" animations (notification badges, live indicators) — a milder case, useful for showing that even small looping animations should still respect the preference. Each is driven by a standard CSS @keyframes animation that gets neutralized by the same .reduced-motion ancestor class, demonstrating a scalable pattern: put the "calm" override rules together in one place rather than duplicating animation: none overrides scattered throughout a stylesheet.