WCAG 2.3.3 — Animation from Interactions

What this requires

Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed. The criterion targets motion that the page initiates in response to user action: scroll-triggered parallax, route-change slide transitions, hover-triggered zooms, large transforms on click.

How AI coding tools fail this

When asked for "smooth page transitions" or "scroll-driven storytelling", AI tools wire up Framer Motion, GSAP, or CSS scroll-linked animations with no prefers-reduced-motion companion. The motion is the visual identity of the site; users with motion sensitivity get it whether they want it or not.

The second pattern: respecting prefers-reduced-motion for some animations but not others. A team adds the media query to its design system but the third-party carousel, the embedded video background, and the marketing landing page still animate at full velocity.

The third: treating motion preference as "no motion at all" instead of "reduce motion to what is necessary". Functional motion (a small state-change animation for a toggle) is fine to keep; large transforms and parallax are what should drop.

Failing examples

Scroll-driven parallax with no reduced-motion handling:

<motion.div
  style={{ y: useTransform(scrollY, [0, 800], [0, -200]) }}
>
  <Hero />
</motion.div>

Large slide-in transitions on every route change:

<motion.main
  initial={{ x: -300, opacity: 0 }}
  animate={{ x: 0, opacity: 1 }}
  transition={{ duration: 0.6 }}
>
  {children}
</motion.main>

Passing examples

Gate the motion on the user's preference:

const prefersReducedMotion = useReducedMotion();

<motion.div
  style={{
    y: prefersReducedMotion
      ? 0
      : useTransform(scrollY, [0, 800], [0, -200]),
  }}
>
  <Hero />
</motion.div>

In CSS:

.page-transition {
  animation: slide-in 0.6s ease-out;
}

@media (prefers-reduced-motion: reduce) {
  .page-transition {
    animation: none;
  }
}

Edge cases

Essential motion is exempt. A loading spinner that communicates "in progress" can stay; replace it with a static indicator under reduced motion.
prefers-reduced-motion is the standard signal. Respect it globally, not per component.
Subtle micro-animations (a 150ms fade, a small scale on hover) don't usually trigger the criterion. The threshold is "motion animation" — large transforms, parallax, motion-heavy effects.
Auto-play motion that runs without an interaction trigger falls under 2.2.2, not 2.3.3.
Browser-level reduce-motion controls are common (macOS Reduce Motion, Windows Animation effects). The web exposes those through the media query.

How Jeikin handles this

The scanner flags CSS animations, transforms over a threshold, and Framer Motion / GSAP usages that lack a prefers-reduced-motion companion. The dashboard records each finding and tracks which animations have a reduced-motion path. The harder question — "is this motion essential?" — is captured as a reviewer note.