WCAG 2.3.3 Animation from Interactions: How to Make Website Animations Accessible

What WCAG 2.3.3 requires

WCAG 2.3.3, Animation from Interactions, covers animations that start because a user interacts with a component. The aim is to prevent unexpected or harmful motion after a click, touch, hover or keyboard action. If an animation can cause dizziness, nausea, disorientation or other vestibular symptoms it must be limited, configurable or avoidable.

Who benefits and why it matters

People with vestibular disorders, motion sensitivity, migraine or epilepsy are most at risk. Older users and people using assistive tech can be affected too. Controlling interaction-triggered motion improves comfort and reduces barriers to completing tasks like filling forms or reading content.

When this applies and when motion can be essential

Apply WCAG 2.3.3 when an interaction starts an animation that is not purely essential. Examples: animated page transitions, decorative hover effects, animated icons that loop after a click, parallax that moves content after a scroll interaction. Motion that is strictly necessary to complete a task may be allowed, but then it must be kept minimal and must still respect user preferences where feasible.

Decision checklist: is the animation essential?

• Does the animation convey information that text or static visuals cannot? If yes, it may be essential.
• Is the animation the only way a user can complete a task? If yes, reduce motion and provide alternatives.
• Does the animation run automatically after an unrelated interaction? If yes, treat it as non-essential and provide control.

How to implement compliance

Follow layered controls. First respect OS and browser motion preferences. Second provide per-component or per-page controls. Third limit the intensity, duration and pattern of any remaining motion.

Respect OS and browser preferences

Check for prefers-reduced-motion in CSS and JavaScript. For CSS use a media query like @media (prefers-reduced-motion: reduce) to remove or shorten animations. In JavaScript test the matchMedia API and avoid starting complex motion when the user prefers reduced motion.

Provide clear controls

Give users a visible, keyboard-focusable control to pause, stop or disable interaction-triggered animations. Place it near the component that animates. Use semantic HTML controls like a checkbox or button with clear labels such as “Reduce motion” or “Pause animation”. Ensure the control state is programmatic and preserved when needed.

Limit motion smartly

Keep animations short. Avoid sudden large translations, scaling greater than 10 percent, or fast rotational movement. Prefer opacity and simple fades. Use easing that reduces abrupt acceleration. If you must animate position, animate no more than 10 to 20 pixels for subtle movement when possible.

Design patterns that work

• Toggle motion mode per page. Respect the setting for every interactive component on that page.
• Use reduced-motion versions of components. For example, replace a slide-in menu with an instant appear when motion is reduced.
• Defer non-essential decorative animation until explicit user request.

Accessible implementation details

Make controls reachable by keyboard and screen readers. Use an ARIA role only when native semantics fail. For example, an HTML button with aria-pressed=“true” can represent a toggle. Announce state changes with standard DOM updates rather than relying on live regions for state alone.

JavaScript considerations

When starting animations from code, check window.matchMedia(‘(prefers-reduced-motion: reduce)’).matches before calling requestAnimationFrame or CSS transitions. Use animation-play-state to pause CSS animations dynamically. Cancel timeouts and stop ongoing animation loops when motion should be reduced.

CSS examples described

Use the prefers-reduced-motion media query. Example pattern: inside the query set animation-duration: 0.001s or animation: none to remove non-essential motion. For transitions you can set transition-duration: 0s to make changes instant when reduced motion is preferred.

Testing and QA for WCAG 2.3.3

Test with OS-level reduced motion toggles on macOS, Windows and mobile devices. Test with keyboard only, and with a screen reader active. Manually trigger every interaction that starts animation. Confirm the animation can be disabled or is absent when the preference is set.

Practical test checklist

• Toggle prefers-reduced-motion and repeat the interaction. No non-essential motion should run.
• Use keyboard to activate the control. The control must be reachable and operable.
• Try a quick toggle of the page-level motion control and ensure components update immediately.
• Check persistent state if needed for multi-step flows so a user does not re-enable motion unexpectedly.

Real-world scenario: product image zoom on click

A product gallery uses a click to open a zoom animation that pans and scales the image. To comply implement these changes. Provide a reduced-motion mode that opens the zoom instantly with no pan. Add a visible toggle near the gallery labeled “Reduce motion”. Respect the user preference across the site so the gallery never animates if the visitor has reduced motion enabled.

Common mistakes to avoid

• Only handling hover. Motion can start on click, focus or keyboard input too.
• Providing a visual toggle that is not keyboard or screen reader accessible.
• Hiding the toggle off-screen or behind menus so users cannot find it when motion triggers.
• Assuming small movement is always safe. Even small motion can trigger symptoms for some users.

Small, practical code rules to follow

• Always check prefers-reduced-motion before starting scripted animation.
• Use semantic controls for toggles and label them clearly.
• Keep defaults respectful: avoid starting large animations automatically after any interaction.

Quick audit checklist for teams

1. List all components that animate after user interaction.
2. Confirm each component respects prefers-reduced-motion.
3. Ensure each component has an accessible control or a reduced-motion fallback.
4. Run device and keyboard tests and record failures for remediation.

Where to be conservative

When in doubt reduce motion. A conservative approach avoids disorienting users and lowers support costs. Keep animations optional and provide an immediate fallback so tasks never depend on motion.

Final checks before release

• Verify toggles are visible without extra clicks.
• Verify toggles keep state when useful, such as during checkout flows.
• Document the behavior in your component library so developers implement the same patterns.

Following these steps will make interaction-triggered motion predictable and safe. That reduces risk for users with motion sensitivity while keeping useful motion where it helps the experience.