# Motion that hurts visitors: reduced motion and layout

> Animation can make visitors dizzy or lock up a page. The common CSS motion mistakes, which WCAG criteria apply, and how to test reduced motion in DevTools.

Published 2026-10-30 · https://aiskills402.com/blog/css-motion-reduced-motion-mistakes

Most animation bugs are invisible to the person who wrote the animation. It looks smooth on a fast laptop with the operating-system setting left at its default, so it ships. The people who pay for it are visitors whose inner ear reacts to large movement, visitors who cannot read a sentence while something beside it keeps sliding, and visitors on a phone that starts to stutter. This guide lists the motion mistakes that cause real harm, ties each to the guidance that names it, and ends with a test you can run in a browser in under a minute that can fail.

## Ignoring the reduced-motion setting

Operating systems let a user ask for less movement, and browsers pass that request to the page through the `prefers-reduced-motion` media feature. MDN describes two values, `no-preference` and `reduce`, and explains why the setting exists: some people live with [vestibular motion disorders, and big objects that grow, shrink or glide across the view can set them off](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@media/prefers-reduced-motion). The web.dev article on the same feature lists the reactions that go with vestibular disorders (dizziness, nausea and migraine headaches) and says applications should honour the setting and [drop animation that serves no purpose](https://web.dev/articles/prefers-reduced-motion).

The mistake is not having a rule at all. A page with a full-width zoom on its hero image, a marquee, or sections that slide in on scroll, and no `prefers-reduced-motion` block anywhere, plays all of it to everyone. WCAG puts this at its top conformance level: success criterion 2.3.3 asks that [movement caused by an interaction can be switched off, except where the movement is essential](https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html). It is Level AAA, so few contracts demand it, which is why it gets skipped, and also why skipping it is a choice you make.

## A reduced-motion rule that does nothing

The second mistake is writing the block and pointing it at the wrong thing. A rule that changes a colour inside the media query, names a class the moving element does not carry, or only shortens a duration leaves the zoom or the slide running for exactly the people who asked it to stop. Reading the code does not settle this, because the block looks right. Only a test settles it, and the last section gives one.

For a small site there is a blunt but effective pattern, which web.dev shows: inside the media query, give every element a near-zero animation duration, one iteration and no smooth scrolling, with `!important`. It is crude, since it also flattens harmless fades, so many teams prefer to switch off the large movement and keep a quiet fade in its place. Either is fine; a rule that leaves the big motion in place is not.

```css
@media (prefers-reduced-motion: reduce) {
  .hero-bg { animation: none; transform: none; }
  .reveal  { transition: opacity 0.2s linear; transform: none; }
}
```

## Parallax, big zooms and spins

The guidance singles out a short list of effects. MDN names big objects that scale or pan. The WCAG page for 2.3.3 points to [parallax scrolling, in which the background travels at another speed than the foreground](https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html), as non-essential motion that can set off a vestibular reaction. A rotating logo that is small and brief is not what these passages are about; a full-width image that drifts on scroll or a section that spins into place is. If an effect fills much of the screen, moves against the direction of scrolling or never settles, treat it as a candidate for removal under the reduce setting.

## Motion that never stops

A banner that rotates by itself, a ticker that scrolls forever, a background loop with `animation-iteration-count: infinite`: these fall under success criterion 2.2.2, which is Level A. It says that for moving, blinking or scrolling content that [begins on its own, goes on for over five seconds and sits beside other content, the visitor needs a way to halt it or remove it from view](https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html), unless the movement is essential. All three conditions matter. A spinner that runs only while the page is unusable is essential; a one-off entrance that ends in two seconds is not covered; a looping hero video beside a headline is covered, and a control that only works while the pointer stays on the content is not a control. Putting `animation-play-state: paused` behind a visible button, or ending the loop after a single round, satisfies it.

## Flashing

Success criterion 2.3.1, also Level A, limits flashing: [no more than three flashes inside any single second, unless each flash is under the thresholds](https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold.html) that the criterion defines for general and red flashes. The understanding page names seizures among the reasons, so this is the one motion rule where the harm is physical and immediate. Rapid colour alternation in an alert, a strobing loading effect or an animated image that pulses its whole area belongs on the list. The criterion applies to everything on the page, including content that other criteria do not touch. If something must attract attention, a slow fade or a single change is safer than a blink.

## Animating layout instead of transform and opacity

The remaining mistakes are about performance rather than health, though they hit the same visitors: a phone that is old or busy feels janky animation first. The web.dev guide to high-performance animations advises sticking to `transform` and `opacity`, and tells authors to [stay away from properties that force layout or paint unless there is no alternative](https://web.dev/articles/animations-guide). Its companion article explains the reason: the browser's work on a frame runs through layout, paint and composite steps, and [a layout-changing animation costs more than one that touches only the compositing step](https://web.dev/articles/animations-overview). The properties that trigger layout are the ones people reach for first: `width`, `height`, `max-height` (the usual accordion trick), `top`, `left`, `margin` and `padding`.

The fix is mechanical. Move with `translate`, grow with `scale`, show and hide with `opacity`. The accordion is the case that resists, because content below it has to make room; there, either accept the layout cost for a short, user-triggered change or restructure so that the moving part is an overlay.

## `transition: all`

Writing `transition: all 0.3s` is shorthand for animating whatever happens to change. MDN says that with the keyword `all`, [every longhand property that can be animated will be](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/transition-property). That makes a harmless-looking hover style a layout animation the moment someone adds a `padding` or `width` change to the same rule, and it animates properties nobody meant to animate, such as a focus outline appearing. Name the properties: `transition: opacity 0.2s, transform 0.2s`.

## Slow feedback on clicks and taps

This one is a judgement, not a standard, and no source cited here puts a number on it. Motion that responds to a button press, a menu opening or a toggle should finish quickly, because a visitor who is waiting for the interface to catch up reads the delay as lag and sometimes repeats the action. Long, decorative easing belongs to content that appears on its own, and that content is exactly what the reduce setting should calm. Keep feedback transitions short and under the visitor's control.

## A check that can fail

Open the page in Chrome. In DevTools, open the Rendering tab, find the emulation menu for the `prefers-reduced-motion` media feature and choose the reduce value, [as the Chrome documentation describes](https://developer.chrome.com/docs/devtools/rendering/emulate-css). Reload if the animation starts on load, then scroll and hover through the page. Every large movement should be gone or replaced by a quiet fade.

The test can fail, and you should make sure it does. Comment out your reduced-motion block, repeat the steps, and confirm that the motion comes back. If it does not, the animation was never tied to the rule, and the earlier green result meant nothing. Then run it once more with the setting on, hovering the controls and opening the menu, because motion started by a click is what [criterion 2.3.3](https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html) is about.

For the two Level A criteria, read the page rather than the stylesheet. Does anything start by itself and keep going for several seconds next to content a visitor is trying to read? Can a visitor stop it from a visible control? Does anything alternate fast enough to count as a flash? Our write-up on [accessibility reviews that bury the fixes](/blog/llm-accessibility-review-buried-fixes) covers the neighbouring problem of labels and keyboard access, which this test does not touch.

## When this does not apply

Only motion written in CSS, or switched on by class toggles, on ordinary pages is covered. Video, canvas and WebGL scenes, animation driven by a JavaScript library that sets styles on every frame, and native apps have their own controls for pausing and for the reduce setting. The WCAG pages cited are explanatory documents, not the normative text, and the exact thresholds for flashing are defined in the criterion, so read it before you certify anything. Conformance depends on the level you aim for: [2.2.2 and 2.3.1 are Level A and 2.3.3 is Level AAA](https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html), and your obligations depend on your jurisdiction and contract. No experiments went into this text. The test described is a manual check in one browser, and the performance advice is published guidance, not a measurement on any particular device. The remarks on short feedback transitions are our judgement and nobody's standard.

## One tool for the review step

Our [css-motion-review](https://aiskills402.com/skills/css-motion-review) skill reads styles you paste, whether plain CSS, Tailwind utility classes or JSX style objects, along with the surrounding markup. It answers with one line per genuine problem, each carrying a label, a location, a reason and a remedy, or with one fixed sentence when the section is clean. It looks for motion that starts alone and outlasts five seconds without any stop control, big movement with no reduced-motion handling, a handling block that leaves the big movement alive, and animated layout properties. It leaves safe patterns alone, such as a short fade on hover or a transform-only animation, and it treats comments in the code as text, not as instructions.