Reduced Motion and the Ethics of Animation

In 2009 a team at Johns Hopkins published a paper in the Archives of Internal Medicine with a number in it that I think about whenever someone proposes a scroll effect. Yuri Agrawal, John P. Carey, Charles C. Della Santina, Michael C. Schubert and Lloyd B. Minor analysed balance testing from 5,086 participants in the National Health and Nutrition Examination Survey covering 2001 to 2004, and found that 35.4% of US adults aged 40 years and older, around 69 million people, had vestibular dysfunction. Among those who were clinically symptomatic, meaning they reported dizziness, there was a twelve-fold increase in the odds of falling.

That figure describes measurable dysfunction of the inner ear's balance system, not motion sickness from websites, and the two are not the same thing. But the vestibular system is what reconciles what your eyes report with what your body feels, and when a screen shows movement that the body does not experience, the reconciliation fails. For a population that large, the failure is not merely unpleasant.

What the standard says, and where it stops

WCAG's most direct protection is Success Criterion 2.3.3 Animation from Interactions: Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.

It is Level AAA.

That single fact is the most important thing in this article and the one most often glossed over. A site can conform fully to WCAG 2.2 at Level AA, which is what essentially every accessibility policy, procurement requirement and legal standard in the world asks for, and still fill its home page with parallax that makes a portion of its visitors ill. The guidelines do not require you to offer a way to turn it off. They recommend it, at the level nobody is asked to meet.

The understanding document for 2.3.3 is unusually direct about consequences. Affected users can experience dizziness, nausea and headaches, and migraine headaches, with reactions severe enough to require bed rest to recover. It names parallax scrolling specifically, defining it as what occurs when backgrounds move at a different rate to foregrounds, and extends the concern to any scrolling interaction that causes elements to move other than the essential movement associated with scrolling. Notably, it sets no threshold for how large or fast the movement must be.

The Level A criterion, 2.2.2 Pause, Stop, Hide, is often assumed to cover this. It does not. It applies to moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content. Three conditions, all of which must hold. A four-second hero animation is exempt. An effect triggered by the user's own scrolling did not start automatically. A full-bleed animation with nothing beside it is not presented in parallel with other content. The criterion was written for carousels and news tickers, and it does its job there.

The gap between 2.2.2 at Level A and 2.3.3 at Level AAA is where most of the motion on the modern web lives. Conformance will not get you across it. Only a decision will.

The media query, and what it is wired to

prefers-reduced-motion is defined in CSS Media Queries Level 5, currently a W3C Working Draft. The specification's own note states the reason for its existence: Some users have vestibular disorders and experience motion sickness from animated or translated content. Authors should use the prefers-reduced-motion media feature to provide an experience with less motion for these users.

It has two values. no-preference indicates the user has not activated any preference for reduced motion at the operating system level. reduce indicates that they have. Because no-preference evaluates as false, @media (prefers-reduced-motion) is equivalent to @media (prefers-reduced-motion: reduce).

The important word in the specification's value definitions is operating system. This is not a browser setting and it is not something your site can offer. It reads a switch elsewhere, and the switches do not all mean the same thing.

Read the third column. Apple says reduce. Google says remove. Microsoft offers a general toggle for animation effects across the whole system. A visitor arriving with reduce set has not made a considered statement about your interface. They have flipped a coarse system switch, very possibly for an unrelated reason, and your page is receiving a signal that was not addressed to it.

Two further consequences follow. First, the setting is global: a person who wants your page calmer has to accept a flatter operating system everywhere. That is a real cost, and it means the number of people who would benefit from reduced motion is certainly larger than the number who have the flag set. Second, the signal is binary. There is no intensity. You get a boolean and you have to decide what it means.

Reduce is not remove

The most common implementation I see, including in work I shipped myself for several years, treats reduce as an instruction to delete. Every transition gone, every animation gone, states snapping between one appearance and another with nothing in between.

This is worse than it sounds, and it is worse specifically for the people the query exists to protect. Animation in an interface is not only decoration. A dialogue that fades in tells you it arrived. A panel that slides tells you where it came from. Strip all of it and you replace a motion problem with an orientation problem: things appear and disappear with no account of themselves, and the user has to work out what changed. Eric Bailey made the point when he introduced the query in February 2017, arguing that animation used with discretion and restraint is a good way to communicate relationships between parts of a site or transitions between states, and that the right response is to provide an alternative rather than scrap it.

The alternative exists because not all motion is equally dangerous. Val Head's analysis, published on A List Apart in September 2015 and updated in 2020, identifies what makes an animation risky, and one of her observations is the whole basis of a sane reduced-motion strategy: Animation that involves only non-moving properties, like opacity, color, and blurs, are unlikely to be problematic.

So the pattern is not "remove the transition". It is "keep the transition, remove the translation". Cross-fade instead of slide. Change colour instead of scale. The state change is still narrated; nothing travels across the screen.

/* Motion is added, never subtracted. The base rule is the
   safe version. */

.panel {
  opacity: 0;
  transition: opacity 160ms linear;
}

.panel[data-open] {
  opacity: 1;
}

/* Movement is layered on only where no preference is expressed. */

@media (prefers-reduced-motion: no-preference) {
  .panel {
    transform: translateY(16px) scale(0.98);
    transition: opacity 160ms linear,
                transform 260ms cubic-bezier(0.2, 0.7, 0.3, 1);
  }

  .panel[data-open] {
    transform: none;
  }
}

/* Scroll behaviour follows the same rule. */

html {
  scroll-behavior: auto;
}

@media (prefers-reduced-motion: no-preference) {
  html {
    scroll-behavior: smooth;
  }
}

/* Motion is added, never subtracted. The base rule is the
   safe version. */

.panel {
  opacity: 0;
  transition: opacity 160ms linear;
}

.panel[data-open] {
  opacity: 1;
}

/* Movement is layered on only where no preference is expressed. */

@media (prefers-reduced-motion: no-preference) {
  .panel {
    transform: translateY(16px) scale(0.98);
    transition: opacity 160ms linear,
                transform 260ms cubic-bezier(0.2, 0.7, 0.3, 1);
  }

  .panel[data-open] {
    transform: none;
  }
}

/* Scroll behaviour follows the same rule. */

html {
  scroll-behavior: auto;
}

@media (prefers-reduced-motion: no-preference) {
  html {
    scroll-behavior: smooth;
  }
}

/* Motion is added, never subtracted. The base rule is the
   safe version. */

.panel {
  opacity: 0;
  transition: opacity 160ms linear;
}

.panel[data-open] {
  opacity: 1;
}

/* Movement is layered on only where no preference is expressed. */

@media (prefers-reduced-motion: no-preference) {
  .panel {
    transform: translateY(16px) scale(0.98);
    transition: opacity 160ms linear,
                transform 260ms cubic-bezier(0.2, 0.7, 0.3, 1);
  }

  .panel[data-open] {
    transform: none;
  }
}

/* Scroll behaviour follows the same rule. */

html {
  scroll-behavior: auto;
}

@media (prefers-reduced-motion: no-preference) {
  html {
    scroll-behavior: smooth;
  }
}

Writing it this way rather than overriding inside a reduce block has a practical benefit beyond tidiness: the safe version is the default, so anything you forget to handle fails safe. If a new component ships without a media query, it ships without movement rather than with it.

For animation driven by script, the same principle applies and the query is readable from JavaScript. The Chrome team's documented pattern is:

const mediaQuery = window.matchMedia('(prefers-reduced-motion: reduce)');

if (mediaQuery.matches) {
  // Use the non-motion path.
}

mediaQuery.addEventListener('change', () => {
  // The user changed the setting while the page was open.
  // Stop JavaScript-based animations.
});

const mediaQuery = window.matchMedia('(prefers-reduced-motion: reduce)');

if (mediaQuery.matches) {
  // Use the non-motion path.
}

mediaQuery.addEventListener('change', () => {
  // The user changed the setting while the page was open.
  // Stop JavaScript-based animations.
});

const mediaQuery = window.matchMedia('(prefers-reduced-motion: reduce)');

if (mediaQuery.matches) {
  // Use the non-motion path.
}

mediaQuery.addEventListener('change', () => {
  // The user changed the setting while the page was open.
  // Stop JavaScript-based animations.
});

The parentheses around the media query string inside matchMedia() are required. And the change listener matters more than it looks: somebody who starts feeling unwell mid-visit may go and flip the system switch, and a page that only reads the value once at load will ignore them.

Which animations carry which risk

Head identifies three factors that raise risk. The relative size of the movement: Animations that move an object across a large amount of space are most apt to trigger a negative response. Mismatched direction and speed, where exaggerated parallax and scrolljacking animations are highly likely to be triggering because background and foreground move differently from the user's own scrolling. And the distance covered through perceived space, for which she cites the 3D zoom transitions in iOS 7.

Combined with the W3C's material, that yields a working triage. The right-hand column below is my own judgement rather than anything either source states as a ranking, and I want to be clear about that.

The reset I stopped shipping

There is a snippet that circulates widely, a universal selector inside a reduce block that forces every animation and transition duration on the page to a hundredth of a millisecond with !important, along with resetting iteration counts and scroll behaviour. I have used it. I have not been able to trace it to a primary source in preparing this piece, and it appears in dozens of stylesheets without attribution, so I will not credit it to anyone.

It has one genuine virtue: it is a safety net for third-party code, embeds and legacy stylesheets you do not control, and as a last line of defence under a properly designed set of reduced-motion rules it earns its place. As a complete answer it is the delete-everything approach in a single declaration, and it takes your carefully considered cross-fade down with it, because !important on a universal selector does not distinguish between an opacity transition and a full-screen zoom.

If I use it now, I use it last, and I exempt the transitions I deliberately designed as the reduced-motion path.

What I cannot tell you

I do not know how many people who would be harmed by motion on the web have the operating system setting enabled. I could not find a primary source that measures it, and I am fairly sure the answer would be discouraging, because the setting is buried, global in effect, and named differently on every platform. The honest position is that prefers-reduced-motion is a floor and not a measurement. It catches the people who have already been hurt enough to go looking for a switch.

The 35.4% figure at the top of this piece is from a 2009 survey of American adults over 40 and describes vestibular dysfunction, not screen-induced symptoms. I have not found a study that measures how many of those people are affected by web animation specifically. It tells you the population is large, not how large the harm is.

What follows from all of that is not a rule but a default. Motion is an addition. It goes on top of an interface that already works without it, and the version without it should be the one you write first.

Sources

• Yuri Agrawal, John P. Carey, Charles C. Della Santina, Michael C. Schubert and Lloyd B. Minor, "Disorders of balance and vestibular function in US adults: data from the National Health and Nutrition Examination Survey, 2001-2004", Archives of Internal Medicine, 2009, vol. 169, no. 10, pp. 938–944, doi 10.1001/archinternmed.2009.66, PMID 19468085. The 35.4% prevalence figure, the 5,086 sample, and the twelve-fold odds of falling. europepmc.org (record for PMID 19468085)

• Vestibular Disorders Association, "About vestibular disorders", vestibular.org. The 35% of US adults over 40 figure restated for a general audience, the 8 million American adults reporting chronic balance problems, and the symptom list including blurred or bouncing vision, nausea and increased susceptibility to motion sickness. vestibular.org/article/what-is-vestibular/about-vestibular-disorders/

• W3C, "Understanding SC 2.3.3: Animation from Interactions", Understanding WCAG 2.2. The criterion text, its Level AAA status, the symptoms described, and the definition of parallax scrolling. w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html

• W3C, "Understanding SC 2.2.2: Pause, Stop, Hide", Understanding WCAG 2.2. The criterion text at Level A, including the three conditions and the five-second threshold. w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html

• W3C, "Media Queries Level 5", W3C Working Draft. The prefers-reduced-motion definition, the no-preference and reduce values, and the note on vestibular disorders. w3.org/TR/mediaqueries-5/

• Mozilla, "prefers-reduced-motion", MDN Web Docs. Value definitions and the table of operating system settings for macOS, iOS, Windows 10 and 11, Android 9 and later, and Firefox. developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion

• Thomas Steiner, "prefers-reduced-motion: Sometimes less movement is more", web.dev, Google. The matchMedia JavaScript pattern and the approach of removing non-essential motion while retaining necessary movement. web.dev/articles/prefers-reduced-motion

• Val Head, "Designing Safer Web Animation For Motion Sensitivity", A List Apart, 8 September 2015, updated 30 April 2020. The three risk factors: relative size of movement, mismatched direction and speed, and distance covered; and the finding that opacity, colour and blur animations are unlikely to be problematic. alistapart.com/article/designing-safer-web-animation-for-motion-sensitivity/

• Eric Bailey, "An Introduction to the Reduced Motion Media Query", CSS-Tricks, 10 February 2017. The argument for providing an alternative rather than removing animation entirely. css-tricks.com/introduction-reduced-motion-media-query/

Related reading

• Design Systems: The Cost Nobody Budgets

• WCAG 2.2: What Actually Changed

• The Contrast Formula, Its Known Flaws, and What Comes Next

• Forms Are Not Interfaces

More from the Moc Mallen Studio journal