Section 1
Why this excludes real customers
Motion sensitivity is a real and not-uncommon condition: for people with vestibular disorders and related sensitivities, on-screen motion can trigger genuine physical discomfort, dizziness, nausea, headaches, disorientation, the way motion sickness does. So a website built with lots of motion (parallax scrolling, large animations, autoplaying video, aggressive transitions) and no way to reduce it can be physically unpleasant or unusable for these visitors, who then leave, not because they weren't interested, but because the site literally made them feel ill. That's the exclusion: real potential customers driven away by a physical barrier, invisibly (they won't tell you they left because your animations made them dizzy). And it compounds the general motion problem (excess motion annoys everyone) with a specific accessibility harm (it physically affects some). The mistake is failing to account for this, building motion-heavy sites as if motion affects no one negatively. Because the affected visitors leave silently, the cost is invisible, which is exactly why the mistake persists. The principle: on-screen motion can cause real physical symptoms for motion-sensitive visitors, so motion-heavy sites with no reduction option exclude real customers, invisibly. (This applies the accessibility and interaction-design research cited across this library.) Your parallax scroll and big animations delight most visitors, and make some physically dizzy or nauseated. They don't complain; they just leave, and your analytics show an ordinary bounce. That's the exclusion: real customers driven off by a physical barrier you didn't know you built. Motion isn't just an aesthetic choice. For some of your visitors, it's the difference between a usable site and one that makes them ill.
Section 2
The simple fix (that almost nobody does)
1, Respect the reduced-motion preference. Operating systems and browsers let users signal they prefer reduced motion (a "prefers-reduced-motion" setting), and websites can detect and honor it, serving a reduced-motion experience to those users. Honoring this preference is the core fix, and it's well-supported and straightforward to implement. 2, Provide reduced/no-motion alternatives. For your animations, ensure there's a reduced or no-motion version for users who need it, so the site is fully usable without the motion that harms them. The content and function should work without the motion. 3, Avoid the most harmful motion patterns. Be especially careful with the patterns most likely to cause symptoms, large parallax effects, big sweeping movements, autoplay, using them sparingly and ensuring they can be reduced. Some patterns are riskier than others. 4, Don't make motion unavoidable. The exclusion happens when motion is unavoidable, built in with no way to reduce it. Ensuring motion can always be reduced (via the preference) removes the barrier. Avoidable motion doesn't exclude; unavoidable motion does. 5, Test with reduced-motion enabled. Turn on the reduced-motion preference and check that your site respects it and remains fully usable and good, confirming the fix works. Most sites have never done this check, which is why most sites fail it. So the fix is simple: respect users' reduced-motion preferences and ensure your site works without the harmful motion, a well-supported, straightforward step that removes the physical barrier and includes the customers motion-heavy sites exclude. The mistake is common; the fix is easy; almost nobody does it. (This guidance reflects the cited accessibility research; this is general information, not legal advice.)
Section 3
The motion accessibility fix, in one view
The takeaway: a common motion mistake, building animated, moving websites without respecting that motion physically harms some visitors, excludes real customers, because for people with vestibular disorders and motion sensitivities, on-screen motion can cause genuine symptoms (dizziness, nausea, disorientation) that make a motion-heavy site unusable, and they leave silently. The fix is simple and almost universally neglected: respect users' reduced-motion preferences (the well-supported "prefers-reduced-motion" signal), provide reduced or no-motion alternatives, use the most harmful patterns (parallax, autoplay) sparingly, never make motion unavoidable, and test with reduced-motion enabled. This removes the physical barrier and includes the customers motion-heavy sites exclude, invisibly, until you fix it. The mistake is common, the cost is hidden, and the fix is easy: respect reduced-motion, and stop excluding customers your animations were making ill. This is general guidance, not legal advice. (The framing synthesizes the accessibility and interaction-design research established across this library.)
Section 4
Execute This With AI
Step 1, Inputs. Note your site's motion (parallax, animations, autoplay), and whether you respect reduced-motion preferences. Step 2, Run the prompt: You are an accessibility strategist on the MOTION mistake that excludes real customers: on-screen motion (parallax, big animations, autoplay) can cause real physical symptoms (dizziness, nausea) for motion-sensitive visitors, so motion-heavy sites with no reduction option exclude them, and they leave silently. The simple, well-supported fix: respect the "prefers-reduced-motion" preference, provide reduced/no-motion alternatives, use harmful patterns sparingly, never make motion unavoidable, test with reduced-motion enabled. This is general guidance, not legal advice. My site's motion: [DESCRIBE]. Do I respect reduced-motion preferences? [yes/no/unsure]. Do four things: 1. Identify my motion most likely to harm motion-sensitive visitors (parallax, autoplay, big moves). 2. Tell me how to respect the reduced-motion preference on my platform. 3. Recommend reduced/no-motion alternatives so my site works without the harmful motion. 4. Give me a test to confirm my site respects reduced-motion and stays fully usable. Remove the physical barrier; include the customers I'm excluding. Step 3, The reduced-motion test. Enable "reduce motion" in your OS/browser settings and visit your site: "Does it respect the setting and reduce the motion, or does it animate anyway, excluding motion-sensitive visitors?" Tools and expected output. Any frontier chat model, plus your OS/browser reduced-motion setting and platform. Expect harmful-motion identification, reduced-motion implementation guidance, alternatives, and a confirmation test. The QA discipline: actually enable reduced-motion and verify your site respects it and remains fully usable, most sites have never tested this and fail it, silently excluding motion-sensitive visitors. Use the most harmful patterns (parallax, autoplay) sparingly. This is general guidance, not legal advice; for conformance, consult accessibility resources/professionals. The model identifies the harm; honoring reduced-motion removes the barrier. A common motion mistake, building animated websites without respecting that motion physically harms some visitors, excludes real customers, because for people with vestibular disorders and motion sensitivities, on-screen motion can cause genuine symptoms that make a motion-heavy site unusable, and they leave silently. The fix is simple and almost universally neglected: respect users' reduced-motion preferences, provide reduced or no-motion alternatives, use the most harmful patterns sparingly, never make motion unavoidable, and test with reduced-motion enabled. This removes the physical barrier and includes the customers motion-heavy sites exclude, invisibly, until you fix it. The mistake is common, the cost is hidden, the fix is easy: respect reduced-motion, and stop excluding customers your animations were making ill. This is general guidance, not legal advice.
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), [Accessibility as a Conversion Advantage, Not Just Compliance](/blog/accessibility-as-a-conversion-advantage-not-just-compliance), [A Practical Accessibility Checklist for Non-Technical Business Owners](/blog/a-practical-accessibility-checklist-for-non-technical-business-owners). Also relevant: [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).