Motion Accessibility: The prefers-reduced-motion Guide for Front-End Teams

A parallax hero is a flourish for most visitors. For a user with a vestibular disorder it can mean nausea, dizziness, disorientation, and a headache that lasts hours. Motion is one of the few accessibility failures that causes immediate physical harm - and it is almost never in the backlog, because the animation was signed off by brand.

That asymmetry is the problem this article addresses.

---

Who is affected, and why

The population affected by screen motion is far larger than a "disability" framing suggests.

By age 40, more than 35% of adults have experienced some form of vestibular dysfunction. Vestibular migraine alone affects up to roughly 2.7% of the general population. Around 4% of US adults report chronic balance problems, and a further 1.1% report chronic dizziness. Beyond those figures, a 2023 meta-analysis of population surveys found that between 45% and 74% of adults worldwide experience at least one episode of motion sickness in their lifetime, depending on definition and transport mode.

The mechanism is straightforward. The vestibular system - the inner ear's balance apparatus - expects visual motion to correspond to physical motion. Scrolling animations can cause vestibular disorders when elements other than the main scrolling element move around a lot; parallax scrolling is a particular trigger because background elements move at a different rate than foreground elements. The brain receives conflicting signals and responds with the same symptoms it would produce on a rough sea crossing. Reactions include dizziness, nausea, and migraine headaches, and sometimes require bed rest to recover.

This is not squeamishness. It is physiology.

The population also includes people in concussion recovery, people with migraine (with or without a formal vestibular diagnosis), and people with temporary conditions - an ear infection, a recent head injury - who would never self-identify as disabled. Cyber sickness is more common in people with a history of concussion, a vestibular disorder, migraine, and fainting.

The iOS 7 episode is the clearest demonstration that interface motion, not just video, can make people ill. Apple's iOS 7 made frequent use of zoom and slide animations; the home screen boasted parallax, with icons apparently floating above subtly animating wallpaper - and it made people sick. In a poll displayed alongside coverage of the iOS 7 launch, roughly 28% of users reported mild or serious motion sickness from the system-wide motion effects. That is not a formal study, but it is a striking signal about the scale of the problem.

The widely cited A List Apart account by developer Facundo Corradini puts a human face on the data. After developing a temporary vestibular disorder, he found he could no longer use motion-heavy sites he had himself built. He learned the hard way that "invisible conditions" - vestibular disorders, cognitive differences, dyslexia - are just as important to consider, and that he had been unintentionally making websites inaccessible to some users by barely addressing the issues in order to pass automated tests.

---

Two WCAG obligations - and they are not the same thing

This is the section most teams get wrong. prefers-reduced-motion is a user preference signal. It is not, by itself, a conformance strategy. Two distinct WCAG obligations exist, and conflating them leads to real failures.

WCAG 2.2.2 Pause, Stop, Hide - Level A

WCAG 2.2.2 is the Level A success criterion that gives users control over content that moves on its own. It requires that for any moving, blinking, or scrolling information that starts automatically, lasts more than five seconds, and is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it - unless the movement is part of an activity where it is essential.

Level A means this is inside the WCAG 2.1 AA floor that EN 301 549 and the EAA point at. It is not optional. WCAG 2.2.2 is a Level A success criterion, which means it is part of the baseline for ADA Title II and Title III compliance, Section 508 conformance, and international standards like EN 301 549 and the European Accessibility Act.

The usual failures: autoplaying video, looping GIFs, carousels, marquees, animated backgrounds, and infinite logo tickers. The bar is deliberately high: looking lively, matching a brand, or holding attention are never essential.

The control must be a visible, keyboard-operable button that actually halts the movement - not a hover-pause, which ends the moment the pointer leaves.

WCAG 2.3.3 Animation from Interactions - Level AAA

WCAG 2.3.3 states that motion animation triggered by interaction can be disabled unless the animation is essential. This supports the intent of WCAG 2.3.3, which requires a way to disable non-essential animations triggered by user actions; detecting reduced-motion preferences gives you a reliable way to do that in code. Note that WCAG 2.3.3 is a AAA success criterion.

Being AAA, it is not part of the WCAG 2.1 AA floor that EN 301 549 and the EAA currently reference. Do not overstate the legal position. That said, honouring the OS preference via prefers-reduced-motion is now baseline professional practice regardless of the conformance level. Treat it as non-negotiable craft, not as a legal obligation.

WCAG 2.3.1 Three Flashes or Below Threshold - Level A

Keep this distinct from vestibular harm. For people with photosensitive epilepsy, flashing lights, scrolling images, or alternating patterns of colour can trigger seizures, depending upon the speed of change, brightness, and contrast with the background. Content should not blink more than three times per second; if it does, it is considered flashing and will fail WCAG. This is a seizure risk, not a vestibular one. Both harms are serious; they are not the same harm.

---

Implementation

Pattern 1: Reduce-by-default (the right mental model)

The conventional approach authors the full animation first and then overrides it inside a prefers-reduced-motion: reduce block. The problem: any component you forget to cover defaults to full motion.

The safer pattern inverts this. Author the reduced experience as the base, then enhance inside @media (prefers-reduced-motion: no-preference). A missed component degrades safely rather than silently harming someone.

Starting with no animation and only adding the animation layer if the browser supports the media feature and the user has no preference for reduced motion is more sensitive towards users and takes progressive enhancement one step further.

/* Reduce-by-default: motion is an enhancement, not a default */

.hero-element {
  /* Base: no transform, no transition */
  opacity: 1;
}

@media (prefers-reduced-motion: no-preference) {
  .hero-element {
    animation: slide-up 600ms ease-out both;
  }
}

/* Smooth scroll is motion - opt-in only */
@media (prefers-reduced-motion: no-preference) {
  html {
    scroll-behavior: smooth;
  }
}

Pattern 2: The global safety net

A global reset catches anything that slips through component-level guards. It is a last line of defence, not a substitute for deliberate per-component decisions.

/* Global safety net - place early in your stylesheet */
@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Note the limits of this approach. It neutralises CSS animations and transitions, but it does nothing for scripted motion: GSAP timelines, scroll libraries, canvas, WebGL, or video.

Pattern 3: Honouring the preference in JavaScript

Any animation driven outside CSS must check the preference itself. Critically, the check must also respond to changes at runtime - a user can toggle the OS setting mid-session.

// Read the preference and respond to live changes
const motionQuery = window.matchMedia('(prefers-reduced-motion: reduce)');

function applyMotionPreference(query) {
  if (query.matches) {
    // Pause scroll-driven animations, skip GSAP timelines,
    // stop canvas particle loops, etc.
    stopAllDecorativeAnimations();
  } else {
    startAllDecorativeAnimations();
  }
}

// Initial check
applyMotionPreference(motionQuery);

// Respond to changes without requiring a page reload
motionQuery.addEventListener('change', applyMotionPreference);

JavaScript-driven motion - a Web Animations API animation, a GSAP timeline, a scroll library - needs to check the preference itself. The CSS guard is irrelevant to that motion.

Video: the autoplay and loop trap

Muted autoplay background video is the most common 2.2.2 failure on marketing landing pages. Muted does not mean harmless. The motion is still there. Auto-playing anything is problematic for both users who experience vestibular disorders and neurodivergent users for whom autoplay can cause major focus issues.

Every autoplaying video needs a visible, keyboard-reachable pause control - regardless of whether the user has set a reduced-motion preference. The preference signal and the pause control are separate obligations.

What "reduce" means in practice

Reduce does not mean zero. Nuking every animation is a mistake - "reduce" means less motion, not a frozen page. Swap large movement for a gentle opacity fade rather than removing all feedback.

In practice, reducing motion means:

• Replacing large-scale translate or scale animations with opacity fades
• Removing parallax entirely (not slowing it down)
• Disabling scroll-jacking and scroll-driven animation
• Stopping auto-advancing carousels (or reducing them to a static first slide)
• Keeping small, purposeful, non-vestibular motion - a subtle button focus ring, a loading spinner - where it is genuinely informative

---

Failure patterns worth naming

---

The coverage gap: prefers-reduced-motion does not discharge 2.2.2

This is the point to remember.

Many users never set the OS reduced-motion preference. They do not know it exists. They are on a shared device, a managed corporate machine, or a public terminal where they cannot change system settings. Some have temporary conditions and have not yet discovered the setting.

Content that autoplays still needs a visible pause control regardless of the media query. The media query is a courtesy to users who have expressed a preference. The pause control is a Level A legal requirement for everyone else.

Honouring prefers-reduced-motion and providing a pause control are complementary, not interchangeable. A site that does one without the other is still failing.

---

Where this belongs organisationally

Motion accessibility escapes audits because animation is owned by brand and marketing, not the accessibility programme. The fix is structural.

Motion tokens in the design system. Duration scales, easing curves, and displacement limits should be design tokens - not ad hoc values per component. A token named --duration-decorative can be set to 0.01ms under reduced-motion globally, once, rather than per component, repeatedly.

A documented motion policy. State explicitly what motion is permitted at what scale, what triggers it, and what the reduced-motion variant must look like. Without a policy, every new landing page is a fresh negotiation.

Reduced-motion variants alongside every animated component. If your design system ships a component with animation, it must ship the reduced-motion variant at the same time. Not as a follow-up ticket. Not as a "nice to have." At the same time.

Review of marketing landing pages and third-party embeds. These are the usual leak. Marketing pages are often built outside the design system, by agencies, under deadline pressure. Third-party embeds - chat widgets, video players, social feeds - are outside your codebase but inside your conformance obligation. Both need motion review as part of the sign-off process.

This connects directly to the argument we have made elsewhere about the design system as accessibility infrastructure: the system is the most efficient place to fix a class of problem once, rather than fixing individual instances repeatedly.

---

Compliance framing

EN 301 549 is the technical route to the EAA's essential requirements. WCAG 2.1 AA is the practical floor. That means 2.2.2 at Level A is squarely in scope - a failure here is a legal exposure, not a best-practice gap.

WCAG 2.3.3 at Level AAA is best practice rather than a legal requirement under the current standard. Do not tell a client it is required; do implement it anyway.

EN 301 549 V4.1.1 was adopted on 24 August 2026. The requirements of clauses 9, 10, and 11 have all been updated to align with the WCAG 2.2 recommendation. The presumption of conformity comes only once the new version is cited in the Official Journal of the European Union, and that citation is expected around late 2026; until then, EN 301 549 v3.2.1, built on WCAG 2.1 Level AA, remains the reference point. The practical implication: WCAG 2.1 AA is still the safe yardstick today, and 2.2.2 has been in that set since WCAG 2.0.

---

Testing routine

---

Motion accessibility is not a niche concern. The affected population is large, the harm is immediate and physical, and the two WCAG obligations - a Level A pause control and a best-practice preference signal - are both achievable with a small amount of deliberate engineering. The gap is not technical difficulty. It is that no one put it in the backlog.

Put it in the backlog.