prefers-reduced-motion: Why Parallax Scrolling and Hover Animations Need an Off Switch

Quick answer: WCAG SC 2.3.3 Animation from Interactions says that motion animation triggered by a user’s interaction — scrolling, hovering, clicking — must be possible to disable, unless the animation is essential to the page’s function or the information it conveys. It exists because non-essential motion can trigger real physical symptoms (dizziness, nausea, headaches) in people with vestibular disorders. The criterion’s own named example is parallax scrolling — background elements moving at a different rate than the foreground as a user scrolls. The practical fix on most sites is a single CSS media query, prefers-reduced-motion, that respects an operating-system-level setting most users already have access to. One thing to know before reading further: this is a Level AAA criterion, one level above the WCAG 2.1 AA scope a standard compliance audit targets — more on what that does and doesn’t mean below.

This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA (or any other level) does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.

What SC 2.3.3 actually requires

The criterion’s normative text is short: “Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.” The Understanding doc states the intent directly: “to allow users to prevent animation from being displayed on web pages. Some users experience distraction or nausea from animated content.” Its own worked example is scroll- triggered parallax: “if scrolling a page causes elements to move (other than the essential movement associated with scrolling) it can trigger vestibular disorders… Another animation that is often non-essential is parallax scrolling. Parallax scrolling occurs when backgrounds move at a different rate to foregrounds.”

The criterion carves out an exception for animation that’s load-bearing: it doesn’t apply if removing the motion “would fundamentally change the information or functionality of the content” and that can’t “be achieved in another way that would conform.” A drag-and-drop interface that visually animates an item into its new slot is showing you something essential. A hero banner’s background image drifting slower than its foreground text is not — the page works identically without it.

Why it matters: vestibular disorders, not general annoyance

The Understanding doc’s Benefits section names the mechanism directly, not just “some users find this annoying”: “People with vestibular disorders need control over movement triggered by interactions. Non-essential movement can trigger vestibular disorder reactions. Vestibular (inner ear) disorder reactions include distraction, dizziness, headaches and nausea.” It also notes the severity range: “the impact of animation on people with vestibular disorders can be quite severe. Triggered reactions include nausea, migraine headaches, and potentially needing bed rest to recover.” This is the same underlying physiology behind motion sickness — a mismatch between what a person’s eyes report and what their inner ear expects — and a scrolling page with independently moving layers is a reliable way to produce exactly that mismatch.

Not the same as SC 2.2.2 Pause, Stop, Hide

It’s easy to conflate this with SC 2.2.2 Pause, Stop, Hide (Level A), covered in depth in our carousel and slider article — but they’re triggered differently. The Understanding doc for 2.3.3 draws the line itself: “‘Animation from interactions’ applies when a user’s interaction initiates non-essential animation. In contrast, 2.2.2 Pause, Stop, Hide applies when the web page initiates animation ‘automatically’ that is not in response to an intentional user activation.” An auto-rotating homepage carousel that starts moving on page load is a 2.2.2 case; a background layer that only starts drifting once a shopper scrolls is a 2.3.3 case. The doc adds that “there may be situations where a particular animation may fail both” — an auto-advancing slider with a heavy parallax transition between slides can trip both criteria independently, and needs both fixes.

Where this shows up on e-commerce sites

Parallax hero and category banners. A background image or graphic that scrolls slower than the foreground text and product imagery layered over it — the criterion’s own example, used on homepages and seasonal-campaign landing pages to add a sense of depth.

Hover-triggered product tile effects. A product-grid tile that tilts, zooms, or shifts a secondary image into view on hover is interaction-triggered motion under this criterion, even though it’s brief and localized rather than page-wide.

“Fly to cart” add-to-cart animations. The product-image-flies-into-the-cart-icon effect many storefronts use as add-to-cart feedback is textbook interaction-triggered, non-essential motion — the cart count changing is the essential information; the flying image is decoration on top of it.

Scroll-triggered reveal/fade-in animations. Content that fades in, slides up, or scales into place as it enters the viewport while scrolling is the same scroll-parallax pattern the criterion describes, just applied to foreground content instead of a background layer.

None of these need to disappear — the requirement is that a user who has told their system they want reduced motion gets a version of the page without them, not that the effects can’t exist for everyone else.

The fix: the prefers-reduced-motion media query

Technique C39, one of the sufficient techniques the Understanding doc cites, is built around a single CSS media feature. The CSS Media Queries Level 5 specification defines what it detects: prefers-reduced-motion: reduce “indicates that user has notified the system that they prefer an interface that removes or replaces the types of motion-based animation that either trigger discomfort for those with vestibular motion sensitivity, or distraction for those with attention deficits.” It reads a setting the user sets once, system-wide (macOS’s Reduce Motion, Windows’ “Show animations” toggle, or the equivalent in iOS/Android/most browsers) — no custom in-page toggle is required, though a site can offer one too if it wants.

/* Approach 1: define the motion effect normally, then strip it out
   when the user has asked for reduced motion */
.hero-banner__background {
  transform: translateY(var(--parallax-offset));
  transition: transform 0.1s linear;
}

@media (prefers-reduced-motion: reduce) {
  .hero-banner__background {
    transform: none;
    transition: none;
  }
}

/* Approach 2 (Technique C39's inverse pattern): default to static,
   and only add the motion effect when the user hasn't opted out */
.product-card__hover-zoom {
  transform: scale(1);
}

@media (prefers-reduced-motion: no-preference) {
  .product-card__hover-zoom:hover {
    transform: scale(1.05);
    transition: transform 0.2s ease;
  }
}

For effects driven by JavaScript rather than pure CSS — a “fly to cart” animation triggered by a click handler, for example — Technique SCR40 covers reading the same preference via window.matchMedia('(prefers-reduced-motion: reduce)').matches and branching the animation logic accordingly, rather than relying on CSS alone.

Can an automated scanner catch this?

No. A direct check of axe-core’s own rule descriptions turns up zero rules anywhere in the file matching motion, animation, parallax, or vestibular — not a weak or disabled check, a genuine absence. That tracks with what the criterion actually requires: determining whether a page’s motion is “essential” to its information or function is a judgment call about intent and content, not something a static DOM/CSS parser can resolve, and whether prefers-reduced-motion is honored only shows up by simulating the OS-level preference and watching what the page actually does — a runtime behavioral check, not a markup check. This is a sharper version of the automated-vs-manual gap our article on what scanners miss covers more broadly: a page can score clean on every automated rule and still fail this criterion outright.

How to check your own site

1. Turn on your OS’s reduce-motion setting (macOS: System Settings → Accessibility → Display → Reduce Motion; Windows: Settings → Accessibility → Visual effects → Animation effects, off) and browse your storefront — hero banners, product grids, checkout.
2. List every scroll-, hover-, and click-triggered effect still moving with that setting on. Each needs the CSS media query treatment above, or a JavaScript check against the same preference.
3. Separate essential from decorative. If the page works identically with an effect gone, it’s in scope for this fix; if removing it would remove information, it’s likely exempt.

FAQ

Is this required for a standard WCAG 2.1 AA audit? No — SC 2.3.3 is Level AAA, above the AA target most accessibility audits (including Quietramp’s) scope to, and above what most legal and policy frameworks reference. It isn’t a gap in an AA-scoped report to not flag it. It’s covered here because it’s a one-line fix with a documented, real physical-health benefit — worth doing outside a formal compliance target.

Does this mean I can’t use parallax or hover effects at all? No. The fix is conditional, not a ban — the effect still runs for anyone who hasn’t set a reduce-motion preference. Only users who’ve told their operating system they want less motion get the static version.

What about video autoplay — same criterion? No. Autoplaying video/audio falls under different criteria (1.4.2 Audio Control; 2.2.2 Pause, Stop, Hide past five seconds) — those govern stopping ongoing media, not interaction-triggered movement. A promo video that starts on hover with fast strobe-style cuts could separately raise a SC 2.3.1 flashing concern — seizures, not vestibular symptoms, with a different fix.

Get a full audit that goes beyond what a scanner checks

Motion sensitivity is a AAA-level, outside-our-scope example of a broader pattern: axe-core and other automated scanners can only flag what’s present in the DOM at a single point in time, not behavior — whether a modal actually traps focus, whether an error message actually gets announced to a screen reader, whether a custom widget actually responds to a keyboard the way its markup suggests it should. That gap is what a manual, human-verified review is for, and it’s the core of what Quietramp does within our standard AA-scoped audits. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.

---

This article is general accessibility information, not legal advice. Meeting WCAG 2.1, at any conformance level, does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.