Because motion on a screen can trigger the same inner ear response as motion in the real world. For people with vestibular disorders, a parallax hero or an aggressive scroll effect is not a design flourish. It can cause dizziness, nausea, and migraines that last well after they close the tab.
This is one of the few accessibility issues where the harm is physical and immediate. A poorly labelled button is frustrating. A page that hijacks the scroll and slides content sideways can put someone in a dark room for the rest of the afternoon.
The web platform has had a proper answer to this since 2020, and it takes about ten minutes to implement. Most sites we audit still do not have it.
It is a CSS media feature that tells your site whether the visitor has asked their device to minimise motion. MDN describes it as "a CSS media feature that is used to detect if a user has enabled a setting on their device to minimize the amount of non-essential motion." You write one media query, and the browser tells you what the person already chose.
The feature takes two values. The no-preference value means the visitor has expressed no preference, and it evaluates as false. The reduce value means they have turned the setting on. MDN notes that because of how it evaluates, writing the query with no value is equivalent to writing it with reduce, so the shorthand is safe to use.
Support is not a concern. MDN lists prefers-reduced-motion as Baseline widely available, noting "it''s been available across browsers since January 2020." That is more than six years of support across Chrome, Safari, Firefox, and Edge. There is no browser argument against using it.
The part that makes it genuinely good design is that the visitor never has to interact with your site to express the preference. They set it once at the device level, and every site that bothers to check gets the answer for free. No banner, no toggle, no cookie.
More than most teams assume, and the number is rising. A 2023 study in OTO Open using National Health Interview Survey data found that in 2016, 36.8 million US adults, or 15.5%, reported a balance problem in the prior twelve months, up from 24.2 million adults, or 11%, in 2008.
That is roughly one in six adults reporting a balance problem in a single year, in one country. Not all of them will be triggered by web animation, and the study measured self-reported balance problems rather than sensitivity to screens. But it puts the affected population in the same order of magnitude as the audiences companies happily build features for.
It is not only adults. The National Institute on Deafness and Other Communication Disorders reports that "about 5% of children in the United States (3.3 million) have experienced dizziness or balance problems in the past year." If your product has a younger audience, the consideration does not go away.
The honest framing for a business owner is this: you will never see these visitors in your analytics as a distinct group. They will bounce, and the bounce will look like any other bounce. The absence of complaints is not evidence that nobody is affected.
Two separate criteria apply, at two different levels. The one most sites already fail sits at Level A, which is the minimum bar, and it covers anything that moves on its own. The one specifically about interaction-triggered motion sits at Level AAA, which is stricter and less commonly required.
Success Criterion 2.2.2 Pause, Stop, Hide is Level A. It requires that for any moving, blinking, or scrolling information that starts automatically, lasts more than five seconds, and appears alongside other content, there is a mechanism to pause, stop, or hide it. That five second threshold catches a lot of auto-playing carousels and looping background videos.
Success Criterion 2.3.3 Animation from Interactions is Level AAA. Its text is short: "motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed." That is the parallax and scroll-effect criterion, and prefers-reduced-motion is the standard way to satisfy it.
The W3C''s explanation of the impact is unusually direct for a standards document. It states that triggered reactions include "nausea, migraine headaches, and potentially needing bed rest to recover." Standards bodies do not normally write like that, and the plainness is the point. Our WCAG accessibility guide covers where these criteria sit in a full compliance picture.
No, and treating it that way is the mistake that stops teams from implementing it. Reduced motion means reduced, not removed. The goal is to cut large positional movement, not to strip every transition and leave an interface that changes state with no feedback at all.
The distinction that matters is between motion and change. A fade is a change in opacity with nothing travelling across the screen, and it is generally safe. An element sliding four hundred pixels while the background moves at a different rate is motion, and that is the category that causes trouble. Swapping the second for the first preserves the feedback and removes the harm.
WCAG''s own wording leaves room for this by carving out animation that is "essential to the functionality or the information being conveyed." A loading spinner communicates that work is happening. A progress bar conveys information. Those are not what the criterion targets.
We think the strongest version of this is to design the reduced-motion experience as a deliberate variant rather than a stripped-back fallback. It should feel finished, not broken.
Start with a single global rule that neutralises long animations and transitions inside a prefers-reduced-motion query, then go back and handle the specific effects that need something better than a blunt override. That one rule gets a typical marketing site most of the way in an afternoon.
The blunt approach is to reduce animation and transition durations to something near zero inside the media query. It is crude, and it will make some interactions feel abrupt, but it is dramatically better than doing nothing and it takes minutes. Ship that first, then refine.
The refinement is replacing rather than removing. Where you had a slide-in, use a fade. Where you had a parallax hero, use a static image. Where you had a number counting up, show the number. Each replacement keeps the intent of the design and drops the movement.
JavaScript animation needs its own handling, because CSS media queries will not touch it. Libraries like GSAP and Framer Motion, and embedded formats like Lottie and Rive, keep animating regardless of your stylesheet. Query the preference in JavaScript and skip or simplify those animations explicitly. This is the step most implementations forget, and it is usually where the worst offending effects live.
Anything that moves large areas of the screen independently of the scroll, and anything that takes control of scrolling away from the visitor. Parallax layers, full-page scroll snapping, horizontal sections that slide as you scroll down, and background video with movement in it are the repeat offenders.
Scrolljacking deserves a special mention because it combines two problems. It moves a lot of content, and it breaks the expectation that scrolling does the thing scrolling always does. For someone sensitive to motion, losing control of the scroll while the screen moves is the worst version of this. We have written about why we generally avoid it in our piece on scrolljacking in web design.
Auto-playing carousels are the most common Level A failure we find, and they are rarely worth defending on their own merits either. They move without being asked, they usually run longer than five seconds, and they sit alongside other content, which is precisely the situation Success Criterion 2.2.2 describes.
We have seen no reason to think so, and the logic runs the other way. The people receiving the reduced version are the people for whom the animated version was actively unpleasant. Serving them a calm page is not a downgrade for them. It is the difference between a page they can use and one they leave.
It also costs you nothing with everyone else. Visitors who have not enabled the setting see exactly what you designed. This is one of the rare accessibility improvements with genuinely no tradeoff, because the audience is self-selecting and nobody else is affected.
The broader question of whether heavy animation helps conversion at all is a separate one, and our answer is that it depends far more on whether the motion clarifies something than on how impressive it is. We went into that in our piece on website animation and conversion. Motion that explains earns its place. Motion that decorates usually does not.
Yes, and it is small enough that it does not need to wait for a redesign. Add the media query, neutralise the long transitions, then work through your JavaScript animations and your heaviest effects. For most marketing sites this is a morning of work, not a project.
Test it by turning the reduced motion setting on in your own device settings and browsing your site normally. That is the whole test. If anything still slides, floats, or hijacks your scroll, you have found the work.
If you are not sure which effects on your site are the problem, or you want the reduced-motion variant designed properly rather than bolted on, we are happy to walk through it. It is a short piece of work with a clear finish line. Reach out through phoenix.studio and we will take a look.
Tell us where you want to go. We'll tell you how we'd get you there.