Honouring Reduced Motion
I was elbow-deep in a client’s legacy site last Tuesday—one of those bloated, “drag-and-drop” nightmares that feels like it was built by someone who has never actually seen a browser—when a parallax scroll effect nearly sent me into a literal seizure. It’s the same old story: some designer thinks a sliding, bouncing, spinning hero section is “magical,” completely ignoring the fact that for many users, it’s just nauseating. Most developers treat accessibility like a checkbox at the very end of a project, but if you aren’t figuring out how to respect reduced motion preferences during the initial build, you’re just building a digital minefield.
I’m not here to sell you on some expensive accessibility plugin or a bloated JavaScript library that’ll tank your PageSpeed scores. I’ve spent nine years un-building bad code, and I know that the most elegant solution is usually the simplest one. I’m going to show you how to use a few lines of CSS to honor the decisions your users have already made in their system settings. No fluff, no hype—just straightforward, performant ways to make sure your site doesn’t make people sick.
Table of Contents
Reading the Css Prefers Reduced Motion Media Query
When I’m auditing a new theme, I don’t just look at the pretty hero animations; I look for the exit strategy. That’s where the CSS prefers-reduced-motion media query comes in. It’s not some optional “nice-to-have” feature you sprinkle on at the end of a sprint; it’s a fundamental way to listen to what the user’s operating system is already telling your code. If a user has flagged that they don’t want things spinning, sliding, or bouncing, your CSS needs to acknowledge that immediately.
I’ve seen too many developers treat disabling animations for accessibility as an afterthought, usually because they’re too attached to a flashy parallax effect. But if you aren’t wrapping your heavy transitions in that media query, you aren’t just being annoying—you’re actively handling vestibular disorders in UI poorly. I don’t care how smooth that fade-in looks; if it makes a user feel like they’re on a tilting boat, you’ve failed the design. My rule is simple: if the media query is active, the motion stops. Period. No exceptions, no “halfway” animations, just clean, static layouts that respect the person on the other side of the screen.
Disabling Animations for Accessibility Without Losing Soul
Here is the problem: most developers think that if they strip out every single transition, the site will look like a static 1998 HTML document. They treat accessibility like a kill switch rather than a dimmer. I’ve inherited so many sites where the “fix” was just deleting every line of `@keyframes` in the stylesheet, and frankly, it’s lazy. You don’t have to kill the soul of your design to be inclusive; you just have to stop forcing movement on people who can’t handle it.
Instead of a total blackout, I aim for subtle transitions. If a user has requested reduced motion, they aren’t necessarily asking for a frozen screen—they’re asking you to stop the spinning, sliding, and zooming that triggers nausea. By handling vestibular disorders in UI through smart design, you can swap a high-velocity slide-in for a simple, soft opacity fade. It keeps the site feeling polished and intentional without causing someone to feel physically ill.
Ultimately, disabling animations for accessibility shouldn’t be an afterthought or a “broken” state of your CSS. It’s a design decision. If you’re following WCAG guidelines, you’re already halfway there, but the real skill is making sure the site still feels like a premium product when the motion is dialed back.
Don't just kill the movement—make it intentional
- Stop using scroll-jacking; if I have to fight my own mouse wheel just to see the next section, I’m already halfway out the door.
- Audit your page builder’s “entrance animations”—most of them are set to trigger on every single scroll, which is a one-way ticket to a vestibular headache.
- Swap out the dizzying parallax effects for a simple, high-quality static background; a clean image is better than a sliding mess that makes people nauseous.
- If you absolutely must have a transition, keep it to opacity fades rather than anything that involves sliding, scaling, or bouncing across the viewport.
- Test your site with the “Reduce Motion” setting toggled on in your OS; if the site feels broken or “stuck” because you stripped everything away, your CSS logic is flawed.
Stop forcing the flash
At the end of the day, respecting reduced motion isn’t some niche accessibility checkbox you tick right before launch; it’s about recognizing that your design decisions aren’t universal laws. We’ve talked about how to actually read the `prefers-reduced-motion` query and, more importantly, how to strip back the unnecessary bloat without making your site look like a broken 1998 HTML prototype. You don’t have to kill every single transition to be inclusive. It’s about intentionality. If you can swap a dizzying parallax scroll for a simple, clean fade, you’ve done your job. Stop treating motion like a default setting and start treating it like a deliberate choice that your user might not want to make.
I’ve spent nearly a decade cleaning up the messes left behind by developers who thought “more movement equals more premium.” They were wrong. A truly high-end digital experience is one that feels seamless and respectful, regardless of how the visitor interacts with it. When you build with these constraints in mind from the start, you aren’t just “fixing” a site; you are crafting something that actually works for people. Don’t let a flashy, over-engineered theme dictate your user experience. Own your code, respect the user’s hardware and biology, and build something that stays still when it needs to.
