How do you handle motion for users who get sick from animation?

You handle it by making motion degrade gracefully: respect the user’s reduced-motion preference, soften or replace heavy effects when it is set, and keep any essential animation gentle. The mechanism behind the requirement is physical. People with vestibular disorders process motion through an inner-ear system that can be triggered by large, sweeping, or parallax movement on screen, producing real symptoms (dizziness, nausea, migraine, sometimes hours of recovery). For them an animation is not a nuisance but an illness trigger, so the design has to offer a path that does not move that way.

The tool that makes this practical is a preference the user already sets in their operating system. WCAG Success Criterion 2.3.3, Animation from Interactions (a Level AAA criterion), asks that motion triggered by interaction be disable-able unless it is essential, and the standard companion to that goal is the CSS media query prefers-reduced-motion. When a user turns on “reduce motion” at the OS level, the browser exposes it, and your stylesheet can respond by cutting or calming animation. The honest default is to build the full-motion version, then add a reduced-motion branch that strips the heavy stuff, rather than treating reduced motion as an afterthought. A belt-and-suspenders approach pairs the media query with a visible in-page toggle, since not every sensitive user has the OS setting configured.

The recognizable offender is the marketing page built around big scroll-driven parallax, where the background drifts at one speed and the foreground at another, plus elements that fly in as you scroll. It feels like delight to the team and reads as motion sickness to a vestibular user. A second, quieter offender hides in ordinary product UI: a card grid where every item zooms and slides on hover, or a route change that pushes the whole screen sideways in a large sweep. None of that announces itself as “animation,” yet the cumulative large movement triggers the same symptoms. Handled well, both check prefers-reduced-motion and, when reduce is requested, drop the parallax to a static background, replace fly-ins and zoom-slides with a simple fade or an instant appearance, and shorten or remove the large transitions. The content is identical; only the movement is calmed.

There is one real limit: reducing motion does not mean banning it. Some animation carries meaning (a loading spinner, a state change that shows a panel opening, a focus move) and removing it entirely can make the interface harder to follow. So the practice is to keep essential motion but make it gentle: small, brief, no large translations or parallax, and to reserve the aggressive degradation for decorative effects. The judgment call is what counts as essential, and the safe rule is that motion is essential only when it conveys information the static state cannot, not merely when it looks polished; a spinner that signals work in progress earns its motion, a logo that bounces on load does not. Reduced-motion is about giving sensitive users a tolerable experience, not flattening the interface into something inert for everyone.

Build every animation with a reduced-motion fallback in place. Wrap decorative and large-movement effects so that under prefers-reduced-motion: reduce they soften to a fade or vanish, keep essential motion small and short, and avoid parallax as a default rather than an opt-out. Then test by enabling “reduce motion” in your own OS and walking the site, confirming that nothing large sweeps, drifts, zooms, or flies, and that the page still communicates everything it did at full motion.