Your Animations Are Making Some Users Sick. Most Teams Never Test It.

Cover Image for Your Animations Are Making Some Users Sick. Most Teams Never Test It.

The parallax scroll effect looked beautiful in the design review. Everyone agreed. The developer shipped it in a Wednesday release. By Thursday morning, three users had filed support tickets saying the homepage made them feel sick. One described it as "motion sickness but on a website." The team spent two hours on a call debating whether the effect needed to be "toned down."

Nobody mentioned prefers-reduced-motion. Nobody had tested it.

This is not unusual. Vestibular accessibility — the accessibility of motion, animation, and scroll effects — is the category that consistently falls out of testing checklists, design reviews, and accessibility audits. Not because teams don't care, but because the failure mode is invisible in any standard testing environment.

Vestibular Disorders Are Not Rare — You Just Can't See Them

The vestibular system controls balance and spatial orientation. When it's disrupted — through conditions like benign paroxysmal positional vertigo, Meniere's disease, vestibular migraines, or post-concussion syndrome — visual motion can trigger symptoms ranging from mild disorientation to nausea, vertigo, and full incapacitation.

The Vestibular Disorders Association estimates that approximately one in three people will experience a vestibular disorder in their lifetime. In the United States, that's roughly 69 million adults. Among that population, vestibular sensitivity to digital motion is documented and common.

Motion-triggered symptoms don't look like other accessibility failures. A screen reader failure shows up in testing. A color contrast failure is measurable. Vestibular distress is reported by a user who closes the browser and doesn't file a ticket — they just don't come back.

Val Head, whose research on animation and accessibility has been cited in browser documentation and WCAG working groups, documented in a 2019 Smashing Magazine article that many people with vestibular conditions manage their digital exposure by avoiding sites that trigger symptoms. They don't complain. They leave.

What prefers-reduced-motion Actually Does (and Doesn't Do)

The prefers-reduced-motion CSS media query reads the operating system's motion setting. On macOS, it corresponds to "Reduce Motion" in Accessibility preferences. On iOS, the same. On Windows, it maps to "Show animations in Windows" in Ease of Access settings.

When a user has enabled these settings, prefers-reduced-motion: reduce evaluates to true. Any CSS or JavaScript inside a matching media query runs instead of the default animation. The animation doesn't run.

@media (prefers-reduced-motion: reduce) {
  .parallax-element {
    transform: none;
  }

  .animated-entrance {
    animation: none;
    transition: none;
  }
}

The API has been supported in Chrome, Firefox, and Safari since 2017. Edge has supported it since Chromium adoption. The WCAG 2.1 Success Criterion 2.3.3 — Animation from Interactions, Level AAA — references the ability to disable motion-triggered animation as a criterion. The European Accessibility Act, which entered full enforcement in June 2025, treats AAA criteria as best practice indicators for public-facing digital services.

What prefers-reduced-motion doesn't do: it doesn't automatically reduce or eliminate animation. It provides a mechanism for the developer to do so. If you don't write the media query, nothing changes for the user who has enabled "Reduce Motion" in their OS settings.

The Scroll-Triggered Animation Trap

Parallax effects — where background elements move at a different speed than foreground elements during scroll — are the highest-risk animation category for vestibular accessibility. They're also among the most popular design choices in modern web interfaces.

The problem is structural: parallax creates a conflict between proprioceptive input (the body's sense of position in space) and visual input (what the screen is showing). The body is still. The screen suggests movement in multiple directions at different speeds. For users with healthy vestibular systems, this reads as "design." For users with vestibular sensitivity, it replicates the same signal conflict that causes motion sickness in a moving vehicle.

Scroll-triggered entrance animations — elements flying in from the left, content fading while moving down as you scroll — create a similar problem at lower intensity. They're typically added late in the project, often by developers implementing final design specs, often after any accessibility review has already concluded.

Other high-risk patterns: animated loading spinners on long-running operations, looping background videos, bounce physics on interactive elements, and any animation that plays without user initiation and cannot be paused.

Why It Never Makes It Into the Testing Checklist

Three reasons, all structural.

The tester doesn't have the condition. Unlike keyboard navigation testing (where the tester can use only the keyboard) or screen reader testing (where the tester can run NVDA), vestibular testing requires either having a vestibular sensitivity yourself or reliably simulating the user's environment. Most teams do neither.

The OS setting is off by default. "Reduce Motion" must be actively enabled by the user. Testing with default system settings means motion effects run normally, vestibular responses aren't triggered, and the test passes. The experience being tested is not the experience the affected user has.

Animation is added after accessibility review. Most accessibility reviews happen during interaction design, not visual polish. Scroll-triggered animations, parallax effects, and microinteractions are often finalized after the last accessibility checkpoint. By the time they ship, the review window has closed.

The fix for all three is procedural: add prefers-reduced-motion testing as a required step in the pre-ship checklist, alongside keyboard navigation and contrast ratio. Enable "Reduce Motion" in the test device's OS settings before any animation testing pass. In Chrome DevTools, you can emulate prefers-reduced-motion: reduce in the Rendering panel without changing OS settings.

The Fix Is Not "Remove All Animation"

prefers-reduced-motion does not require removing animation. It requires providing an alternative.

This matters because animation often carries genuine design value — it communicates state change, directs attention, provides feedback on interactions. Eliminating it entirely for users who need reduced motion degrades the experience unnecessarily.

The correct approach is replacing motion with non-motion alternatives:

  • Parallax scrolling → fade in with opacity only (no positional movement)
  • Slide-in transitions → opacity fade (no directional travel)
  • Animated loaders → static progress indicators or text-based states
  • Looping background video → static poster image

WCAG 2.1 SC 2.3.3 describes the goal as giving users the ability to disable motion-triggered animation "without losing information or functionality." The animated version and the reduced-motion version should convey the same information through different means.

This pattern should look familiar. The dark mode accessibility problem follows the same structure: a design feature that appears accessible on review and fails under specific user conditions that standard testing doesn't simulate. The WCAG neurodivergent gap is the same problem from a cognitive load direction — passing an audit and being accessible are not the same thing when the audit was built for a different user.

Vestibular accessibility is one of the easier wins available. The API exists, browser support is universal, and the implementation in most cases is ten lines of CSS. Teams not doing it aren't failing from complexity. They're failing from a missing item on a checklist that nobody added it to.

Cover photo by Francesco Paggiaro via Pexels.