Large, uncontrolled animations and auto-playing motion can trigger real physical symptoms — dizziness, nausea, headaches — for visitors with vestibular disorders, and most operating systems let a user set a system-wide preference to reduce motion, which most sites simply ignore even though respecting it is a straightforward, well-supported technical capability.
Check your system’s reduced motion setting against your site’s actual behaviour
Enable “reduce motion” in your device’s accessibility settings, then browse your own site. Animations playing at full intensity regardless of that setting confirms the site isn’t respecting the preference, which is the specific, fixable gap this addresses.
Reduced motion preference support
Animation made conditional on a visitor's reduced motion setting — respected, not removed for everyone.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Your site’s animations play at full intensity regardless of a visitor’s reduced motion preference | This fix covers it |
| You want a broader accessibility audit first, not just motion preferences specifically | Accessibility audit report – WCAG 2.2 AA |
| You want animations removed entirely, not made conditional on preference | Worth describing this specific preference directly — a different, more drastic approach than respecting user choice |
| The issue is unrelated to animation, more about general page performance | A different, performance-focused fix instead |
What you are seeing
- Animations and motion effects playing at full intensity even when a visitor has set a system-level reduced motion preference
- Auto-playing carousels, parallax scrolling effects, or animated transitions unaffected by the setting
- No apparent technical accommodation for the reduced motion preference anywhere on the site
- The issue possibly affecting some animated elements more than others, depending on how each was implemented
Common causes
- Animations implemented without checking for the prefers-reduced-motion media query most browsers and operating systems support
- A theme or page builder’s animation features not built with this preference in mind by default
- Third-party embedded widgets or plugins bringing their own motion effects that don’t respect the setting
- Awareness of the requirement existing, but no one having implemented the corresponding technical check
- An auto-playing video background treated as decorative content rather than as motion needing the same preference check as a CSS animation
What we do
- Identify every significant animation or motion effect on the site
- Implement detection for the prefers-reduced-motion preference
- Reduce or disable the identified effects when that preference is detected
- Verify normal animation still displays correctly for visitors without the preference set
- Test the reduced experience directly using the system setting
- Check across a representative sample of affected pages and components
What is included
- Motion and animation effects made conditional on the visitor’s reduced motion preference
- Verified normal behaviour preserved for visitors without the preference set
- Testing using the actual system-level setting
- The pre-fix backup, kept for 30 days
Not included
- Removing animations for all visitors regardless of preference — this respects individual choice rather than eliminating motion outright
- A full accessibility audit beyond motion preferences specifically
- Third-party widget motion effects outside your direct control, unless a workaround is feasible
- Ongoing implementation as new animated components are added
Questions about this fix
Will this remove animation from my site entirely?
No — this makes animation conditional on the visitor's own system preference, so visitors who haven't requested reduced motion continue seeing your site's animations exactly as designed.
How common is this setting among actual visitors?
It varies, but a meaningful portion of visitors do have it enabled, whether due to a genuine vestibular condition or simply a preference for a calmer browsing experience, making this worth respecting regardless of the exact percentage.
Is this a real accessibility requirement, or just a nice-to-have?
It's a specific, testable WCAG success criterion, not merely a courtesy — for visitors with vestibular disorders, uncontrolled motion isn't just an annoyance but can trigger genuine physical symptoms.
Will this affect third-party embeds, like an ad or a social media widget?
Effects from third-party code outside your direct control are harder to address directly — we'd flag any such cases and discuss whether a reasonable workaround exists, rather than promising to control code we don't own.
How do I test that this is actually working correctly?
Enabling the reduced motion setting in your own device's accessibility settings and browsing the site directly is the most reliable way to confirm the implementation responds correctly, which is exactly how we verify it ourselves.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.