WCAG 2.3.3: Animation from Interactions

What This Rule Means

WCAG 2.3.3 — Animation from Interactions is a Level AAA criterion under the Operable principle. It requires that any motion animation triggered by interaction can be disabled by the user, unless that animation is essential to the functionality or the information being conveyed. The criterion applies to animations initiated by user actions such as clicking, scrolling, hovering, focusing, or any other form of interaction — not to animations that play automatically on page load (which may be governed by other criteria such as 2.2.2 Pause, Stop, Hide).

The key concept here is motion animation. This includes parallax scrolling effects, page transition animations, element sliding or zooming, spinning indicators, and any other movement that occurs as a direct consequence of a user's action. It does not cover simple opacity fades or colour changes, because these do not involve spatial movement that can trigger vestibular responses. The distinction is between movement through space (which can cause harm) and changes in appearance without spatial displacement (which generally cannot).

A pass requires that users have a reliable mechanism to turn off such animations without losing access to the same content or functionality. The most widely accepted technique is respecting the operating-system-level prefers-reduced-motion media query, which reflects the user's system preference to reduce motion. Alternatively, a site-level toggle prominently placed in the interface — such as in a settings panel or accessibility widget — can satisfy the criterion, provided it persists across sessions and is easy to find.

An essential exception is narrow: an animation is essential only if removing it would fundamentally change the information or functionality, and no equivalent non-animated alternative exists. A spinning loading indicator that is the only visual cue that content is being fetched might qualify; a decorative parallax background image moving as the user scrolls does not qualify, even if it is aesthetically central to the design.

The criterion does not require that animations be removed entirely — only that a mechanism to disable them exists. When the mechanism is engaged, content must still be fully accessible, meaning a non-animated alternative must deliver the same information or achieve the same function.

Why It Matters

Vestibular disorders — conditions affecting the inner ear and brain that control balance and eye movement — affect a substantial portion of the global population. According to the Vestibular Disorders Association, approximately 35% of adults aged 40 and over in the United States have experienced some form of vestibular dysfunction. Globally, conditions such as benign paroxysmal positional vertigo (BPPV), Ménière's disease, and vestibular migraines affect tens of millions of people. For these individuals, motion on a screen can trigger immediate physical symptoms including dizziness, vertigo, nausea, headaches, and in severe cases, temporary incapacitation.

Consider a user with vestibular migraine who visits a travel booking website. The site uses a full-page parallax scroll effect where the hero image moves at a different speed than the page content as the user scrolls. Within seconds of beginning to scroll, the user experiences intense dizziness and nausea. They cannot complete the booking and must abandon the site entirely — not because of a cognitive barrier or a motor impairment, but because of a physical reaction to motion on screen. This is the real-world harm that WCAG 2.3.3 is designed to prevent.

Beyond vestibular disorders, motion animations can negatively affect users with attention deficit disorders, who find persistent or triggered motion distracting and difficult to ignore, as well as users experiencing anxiety disorders, for whom unexpected movement can cause distress. People recovering from concussions or traumatic brain injuries are also highly sensitive to visual motion. Even users without any diagnosed condition may find heavy animation fatiguing during extended sessions.

From a usability and business perspective, honouring reduced-motion preferences correlates with improved task completion rates and session duration among sensitive users. Respecting system-level preferences also signals that a product is well-engineered and attentive to user needs, which builds trust. For e-commerce, where cart abandonment due to poor experience directly impacts revenue, removing unnecessary animation barriers is a concrete commercial benefit.

Related Axe-core Rules

WCAG 2.3.3 requires manual testing. No axe-core automated rule maps directly to this criterion, and this is by design rather than an oversight. The reasons automated tools cannot reliably detect violations are substantive:

• Why automation cannot catch this: Detecting motion animation requires understanding the visual rendering of a page over time in response to user interaction. Automated accessibility scanners analyse static or lightly-rendered DOM snapshots; they do not simulate user interactions such as scrolling or clicking and then observe whether CSS transitions or JavaScript-driven animations produce spatial movement. Even if a scanner could detect the presence of CSS animation or transition properties, it cannot determine whether that animation involves spatial displacement (which may trigger vestibular responses) or a simple opacity fade (which does not). Furthermore, the scanner cannot determine whether a prefers-reduced-motion media query is correctly wired to suppress the animation, whether a site-level toggle exists, or whether the animation is truly essential. All of these judgements require a human tester who can observe the rendered experience, interact with the page, and evaluate the outcome.
• What manual inspection should target: Testers must identify every CSS property that creates spatial movement — including transform: translateX/Y/Z, transform: scale, transform: rotate, top/left/margin transitions, animation keyframes that move elements through space — and verify that each is gated behind a prefers-reduced-motion: reduce media query or a user-controlled toggle. JavaScript-driven animations using libraries such as GSAP, Framer Motion, or custom requestAnimationFrame loops must be reviewed with equal rigour.

How to Test

1. Enable Reduced Motion at the OS level: On macOS, go to System Settings > Accessibility > Display and enable "Reduce Motion". On Windows 11, go to Settings > Accessibility > Visual Effects and turn off "Animation effects". On iOS, go to Settings > Accessibility > Motion and enable "Reduce Motion". On Android, go to Settings > Accessibility > Remove Animations. This sets the prefers-reduced-motion: reduce media query to active.
2. Run an automated scan as a baseline: Open axe DevTools or Lighthouse in Chrome DevTools against the target page. While neither tool will flag a WCAG 2.3.3 violation directly, the scan may surface related issues and confirms the testing environment is functional. Note any animation-related findings for context.
3. Interact with the page while OS Reduce Motion is active: Scroll the page slowly, click interactive elements such as buttons, navigation toggles, dropdowns, carousels, and modals. Hover over elements. Tab through the page with the keyboard. Observe whether any spatial motion animations still play. If animations are suppressed, this is a pass for the OS-preference pathway.
4. Disable OS Reduce Motion and test again: With OS Reduce Motion turned off, repeat all interactions. Identify every motion animation that triggers from user interaction. Document each one with a description of the triggering action and the animation observed.
5. Check for a site-level animation toggle: If OS Reduce Motion is not respected, look for a site-level control — commonly found in an accessibility widget, settings menu, or footer. Activate it and repeat all interaction tests to confirm motion is suppressed.
6. Inspect CSS and JavaScript for prefers-reduced-motion implementation: Open DevTools, go to the Sources or Elements panel, and search for prefers-reduced-motion in stylesheet files. Verify that all identified motion animations are gated by this query. In Chrome DevTools, you can emulate the media query: open the Rendering tab (More Tools > Rendering) and set "Emulate CSS media feature prefers-reduced-motion" to "reduce". Confirm animations are suppressed without restarting the browser.
7. Evaluate essential exceptions: For each remaining animation when reduced motion is active, assess whether it is genuinely essential — does removing it eliminate information or functionality that has no non-animated equivalent? Document your reasoning for each determination.
8. Screen reader verification (NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari): Screen reader users are not immune to vestibular effects if they also have partial vision. Navigate the page using only the keyboard while a screen reader is active and OS Reduce Motion is enabled. Confirm that no animations are triggered by focus events or keyboard-driven interactions that lack the reduced-motion accommodation.

How to Fix

Parallax scrolling effect — Incorrect

<!-- Background moves at a different rate than content on scroll -->
<style>
  .hero {
    background-image: url('hero.jpg');
    background-attachment: fixed; /* Creates parallax on scroll */
    height: 100vh;
  }
</style>
<div class='hero'></div>

Parallax scrolling effect — Correct

<!-- Parallax is disabled when the user prefers reduced motion -->
<style>
  .hero {
    background-image: url('hero.jpg');
    background-attachment: fixed; /* Parallax by default */
    height: 100vh;
  }

  @media (prefers-reduced-motion: reduce) {
    .hero {
      background-attachment: scroll; /* Static background; no spatial movement */
    }
  }
</style>
<div class='hero'></div>

CSS transition on interactive element — Incorrect

<!-- Button slides and scales on click with no reduced-motion accommodation -->
<style>
  .btn {
    transition: transform 0.4s ease;
  }
  .btn:active {
    transform: scale(0.9) translateY(4px);
  }
</style>
<button class='btn'>Submit</button>

CSS transition on interactive element — Correct

<!-- Spatial transform is suppressed; a simple opacity shift conveys state without motion -->
<style>
  .btn {
    transition: transform 0.4s ease, opacity 0.2s ease;
  }
  .btn:active {
    transform: scale(0.9) translateY(4px);
  }

  @media (prefers-reduced-motion: reduce) {
    .btn {
      transition: opacity 0.2s ease; /* Only non-spatial change retained */
    }
    .btn:active {
      transform: none; /* No movement */
      opacity: 0.75;   /* State still communicated visually */
    }
  }
</style>
<button class='btn'>Submit</button>

JavaScript animation library (GSAP) — Incorrect

<!-- GSAP tween fires on button click regardless of user motion preference -->
<script>
  document.querySelector('#open-modal').addEventListener('click', () => {
    gsap.fromTo('#modal', { y: 80, opacity: 0 }, { y: 0, opacity: 1, duration: 0.5 });
  });
</script>

JavaScript animation library (GSAP) — Correct

<!-- Check matchMedia before triggering spatial animation; fall back to instant display -->
<script>
  const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

  document.querySelector('#open-modal').addEventListener('click', () => {
    if (prefersReducedMotion) {
      /* Skip spatial movement; just make the modal visible immediately */
      gsap.set('#modal', { opacity: 1, y: 0 });
    } else {
      gsap.fromTo('#modal', { y: 80, opacity: 0 }, { y: 0, opacity: 1, duration: 0.5 });
    }
  });
</script>

Site-level animation toggle (accessibility widget) — Correct pattern

<!-- Persist user preference in localStorage and apply a class to <html> -->
<button id='toggle-motion' aria-pressed='false'>Reduce Motion</button>

<style>
  /* Default: animations active */
  .card { transition: transform 0.3s ease; }
  .card:hover { transform: translateY(-8px); }

  /* When user opts out via widget */
  html.reduce-motion .card {
    transition: none;
  }
  html.reduce-motion .card:hover {
    transform: none;
  }
</style>

<script>
  const btn = document.getElementById('toggle-motion');
  const stored = localStorage.getItem('reduceMotion') === 'true';

  if (stored) {
    document.documentElement.classList.add('reduce-motion');
    btn.setAttribute('aria-pressed', 'true');
  }

  btn.addEventListener('click', () => {
    const isActive = document.documentElement.classList.toggle('reduce-motion');
    btn.setAttribute('aria-pressed', String(isActive));
    localStorage.setItem('reduceMotion', String(isActive));
  });
</script>

Common Mistakes

• Applying prefers-reduced-motion only to CSS animations but not to CSS transitions: Both the animation shorthand and the transition property can produce spatial movement. Teams often write a media query for keyframe animations and forget that transition: transform 0.3s on hover or focus also triggers motion that must be gated.
• Using prefers-reduced-motion: no-preference as the query condition instead of reduce: The correct pattern wraps reduced-experience styles in @media (prefers-reduced-motion: reduce), not the inverse. Wrapping animation styles in @media (prefers-reduced-motion: no-preference) can work but is more error-prone and is often misapplied, leaving animations active for users who have not explicitly set a preference.
• Caching the matchMedia result once and never re-checking: A user may change their OS preference while the page is open. Subscribe to matchMedia(...).addEventListener('change', handler) so that JavaScript-driven animations respond to live preference changes without requiring a page reload.
• Treating opacity-only fades as motion animations that must be suppressed: The criterion specifically targets spatial movement. Removing opacity transitions when reduced motion is active is overly aggressive and degrades usability. Fades that do not move elements through space are generally acceptable to retain.
• Placing the animation toggle deep in an inaccessible settings menu: If a site-level control is used instead of (or in addition to) the OS media query, it must be easy to find — ideally in the persistent site header, footer, or an accessible overlay widget — not buried three levels deep in a user account settings page that requires login.
• Assuming all animation libraries automatically respect prefers-reduced-motion: Most JavaScript animation libraries, including GSAP, Anime.js, and custom requestAnimationFrame implementations, do not automatically honour the media query. Each programmatic animation must be individually guarded with a matchMedia check in the JavaScript layer.
• Declaring an animation essential without adequate justification: Teams sometimes mark complex decorative animations as essential to avoid the remediation work. The essential exception is narrow; an animation is essential only if the information it conveys cannot be expressed through any static or non-animated means. Loading spinners, decorative parallax, and page-entry transitions almost never qualify as essential.
• Failing to test interactions beyond click — especially scroll and hover: Parallax scroll effects and hover-triggered transforms are among the most common vestibular offenders, yet testing is often limited to click interactions. Comprehensive testing must cover all interaction modalities including scroll, hover, focus, drag, and keyboard navigation.
• Not persisting the site-level toggle preference across sessions: If a user sets a site toggle to reduce motion and then navigates to another page or returns to the site the next day and the setting is reset, the accommodation has effectively failed. Preferences must be stored in localStorage or a user profile and reapplied on every page load.
• Forgetting third-party embeds and widgets: Embedded social feeds, chat widgets, map embeds, and advertising scripts may introduce their own motion animations entirely outside the host site's CSS control. Third-party content must be audited and vendors must be engaged to provide reduced-motion support, or the embeds must be wrapped in containers that suppress motion via CSS containment strategies where feasible.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette (Resmî Gazete) No. 32933 on 21 June 2025, establishes binding digital accessibility obligations for a defined set of entity types operating in Turkey. The covered entities include public institutions and agencies, e-commerce platforms, banks and financial service providers, hospitals and private healthcare facilities, telecommunications operators with 200,000 or more subscribers, licensed travel agencies, private transport companies, and private schools authorised by the Ministry of National Education (MoNE).

The Circular mandates conformance with WCAG 2.1 at Level AA as the baseline standard for digital services produced or substantially updated after the effective date. WCAG 2.3.3 — Animation from Interactions is a Level AAA criterion and is therefore not a mandatory requirement under Presidential Circular 2025/10. Covered entities are not legally obligated to implement this criterion to achieve compliant status under Turkish law.

However, achieving Level AAA conformance on criteria such as 2.3.3 carries significant practical and reputational value for Turkish organisations. Vestibular and motion sensitivity conditions are invisible disabilities that are frequently overlooked in accessibility audits focused narrowly on screen reader compatibility. For sectors such as healthcare (hospitals and private health platforms), where users may include patients with neurological conditions that heighten motion sensitivity, and for e-commerce and travel agencies, where high-engagement scrolling and animated UI patterns are common, implementing 2.3.3 demonstrates a mature, user-centred approach to accessibility.

Organisations pursuing voluntary AAA conformance — such as those seeking public tender advantages, international market entry, or industry certification — should treat 2.3.3 as a priority criterion given the relatively low remediation cost (a well-structured prefers-reduced-motion media query strategy can be applied systematically across a design system) and the direct physical harm its absence can cause. Including an animation control within an accessibility overlay widget, such as Accsible, allows Turkish organisations to offer this accommodation without requiring users to locate their operating system settings — making the pathway to reduced motion discoverable and usable for the broadest possible audience.