Web Design

Accessible Motion: Respecting Reduced-Motion Preferences

Animation can lift conversion, but it carries an obligation most founders never consider: a significant share of users either prefer less motion or are physically harmed by it. Research indicates that 35% of users request reduced motion when the option is available (1), more than one in three. For some, heavy animation isn't a mild annoyance; it triggers genuine symptoms, nausea, dizziness, disorientation, particularly for people with vestibular disorders. Ignoring this isn't just inconsiderate; it excludes users, creates accessibility (and potential legal) exposure under standards like WCAG, and degrades the experience for a large minority. The good news is that respecting motion preferences is straightforward and doesn't mean abandoning animation. This piece shows how. The data is cited; the guidance follows established accessibility practice.

Joshua Agonya Pi'Rwot

By Joshua Agonya Pi'Rwot

Founder, Business Growth Accelerator

Executive summary

Over a third of users want less animation, and for some, motion isn't an annoyance but a trigger for nausea and disorientation. Here's how to keep your animations and respect them too.

Section 1

The principle: offer motion, but honor "less"

The solution isn't to remove all animation, it's to make your animation respect the visitor's stated preference. Operating systems and browsers let users signal that they prefer reduced motion (a setting on every major OS), and your site can detect that signal and adjust accordingly. The principle is simple: deliver your engaging animations to the users who want them, and automatically dial them down or replace them for the users who've asked for less. Everyone gets an experience suited to them, and no one is harmed or excluded. This is the accessible, and increasingly expected, approach to motion. The principle: animate by default, honor reduced-motion automatically. Respecting reduced-motion isn't a constraint on your animation, it's the difference between motion that delights most users and motion that makes one in three uncomfortable or sick. You don't have to choose between engaging and accessible. You detect the preference and serve both.

Section 2

How to respect reduced motion

The implementation rests on a standard mechanism that most modern tools support. Detect the preference. Browsers expose a prefers-reduced-motion setting that reflects the user's OS choice. Your site can detect it, in CSS for CSS-based animations and in JavaScript for scripted ones (1), and respond. Reduce or replace, don't just disable awkwardly. When reduced motion is preferred, replace large, movement-heavy animations (parallax, big transitions, autoplay) with gentle alternatives, a simple fade, or no animation, rather than leaving broken or jarring half-states. The experience should still feel complete, just calmer. Prioritize the worst offenders. The animations most likely to cause problems are large-movement effects: parallax scrolling, big sweeping transitions, zooming, autoplay, and anything that moves a lot of the screen. These are the priority to soften under reduced-motion; small microinteractions are generally fine. Use the right properties for performance too. Lightweight animations using transform and opacity are both more performant and easier to control for accessibility, a double benefit (1). For most service sites on modern builders, much of this is achievable through platform settings or modest code, and tools increasingly include reduced-motion support and "motion accessibility APIs" for granular control (1). It's a modest amount of work for a meaningful inclusion and risk-reduction payoff.

Section 3

Accessible motion, in one view

The takeaway: accessible motion is not about choosing between engaging animation and inclusion, it's about detecting the visitor's preference and serving both. Animate for the users who want it, honor "less" for the 35% who've asked, and prioritize softening the large-movement effects that actually cause harm. This respects your users, reduces your accessibility and legal exposure, and, because the techniques overlap with performance best practice, often makes your site faster too. It's a small amount of work for a meaningful gain in who your site welcomes. (The prioritization guidance follows established accessibility practice; the framing is mine.)

Section 4

Execute This With AI

Step 1, Inputs. List the animations on your site, especially large-movement ones (parallax, autoplay, big transitions), and your platform. Step 2, Run the prompt: You are an accessibility specialist making my site's motion respect reduced-motion preferences (35% of users request it; heavy motion can cause nausea/disorientation for vestibular conditions; it's a WCAG concern). Approach: detect prefers-reduced-motion and reduce/replace large-movement animations, keep small microinteractions. My animations (esp. large-movement: parallax/autoplay/transitions): [LIST]. My platform: [X]. Do four things: 1. Identify which of my animations are most likely to cause problems under reduced-motion (prioritize large-movement). 2. Recommend the reduced-motion alternative for each (fade, soften, remove). 3. Tell me how to implement prefers-reduced-motion detection on my platform. 4. Note which animations are low-risk and can stay (small microinteractions). Keep my engaging animations for users who want them; honor "less" for those who don't. Step 3, Test it. "How do I turn on reduced-motion in my OS to test that my site responds correctly?" Tools and expected output. Any frontier chat model, plus your builder's motion/accessibility settings and your OS reduced-motion toggle for testing. Expect a risk assessment of your animations, reduced-motion alternatives, implementation guidance, and a keep list. The QA discipline: test it yourself, enable reduced-motion in your operating system and confirm your site actually calms down, because an unverified "we support it" helps no one. The model plans the approach; the real test is your site responding correctly when the preference is set. More than a third of users want less motion, and for some, heavy animation isn't an annoyance but a trigger for real physical discomfort. Respecting that isn't about stripping your site of animation, it's about detecting the visitor's preference and serving both: full motion for those who want it, a calmer experience for the 35% who've asked, with the large-movement effects softened where they actually cause harm. It's modest work, it reduces your accessibility and legal exposure, and it often makes your site faster too. Animate generously, honor "less" automatically, and your motion delights the users who want it without excluding or harming the ones who don't.

Section 5

Keep reading

Keep reading in the Accessibility & the EAA cluster and across the library: [The Business Case for Accessibility (Beyond Compliance)](/blog/the-business-case-for-accessibility-beyond-compliance), [Alt Text That Serves Users, SEO, and AI Search at Once](/blog/alt-text-that-serves-users-seo-and-ai-search-at-once), [A Practical Accessibility Checklist for Non-Technical Business Owners](/blog/a-practical-accessibility-checklist-for-non-technical-business-owners). Also relevant: [The Motion Accessibility Mistake That Excludes Real Customers](/blog/the-motion-accessibility-mistake-that-excludes-real-customers), [The Service-Business Website Priority Stack: What to Fix First When Everything Needs Work](/blog/the-service-business-website-priority-stack-what-to-fix-first-when-everything-needs-work), [What Is Conversion-First Web Design? A Plain-English Guide for Founders](/blog/what-is-conversion-first-web-design-a-plain-english-guide-for-founders).

Joshua Agonya Pi'Rwot

Written by

Joshua Agonya Pi'Rwot

Founder, Business Growth Accelerator · Country Director, AVODA Group Uganda · EMBA

Joshua helps service-business operators turn scattered marketing into a clear path from first attention to booked call. He is Founder of Business Growth Accelerator and Country Director of AVODA Group Uganda.