What is "reduced motion" in prefers-reduced-motion?

prefers-reduced-motion-standard.md

What is "reduced motion" in prefers-reduced-motion?

Status: standards research note Date: 2026-07-16 Scope: web motion exposed through prefers-reduced-motion, with WCAG 2.2 conformance and platform guidance used to define practical checks

Question

When a user requests reduced motion, is there a standard definition, numeric threshold, benchmark, or diagnostic that determines when an interface has reduced motion enough?

Conclusion

No current web standard defines a numeric amount, percentage, duration, travel distance, velocity, or acceleration by which motion must be reduced. prefers-reduced-motion is a discrete preference signal, not a motion budget or severity scale. Its reduce value means that the user prefers an interface that removes or replaces motion-based animation that can cause vestibular discomfort or distraction. It does not mean that every visual change or every animation must disappear. The current Media Queries Level 5 definition does not supply a threshold for deciding when a retained motion effect is small enough.

For interaction-triggered motion, W3C's sufficient WCAG techniques provide the clearest available diagnostic: with reduced motion enabled, each effect must be essential or suppressed. Merely shortening, slowing, or shrinking a non-essential effect is not the result those techniques test. Honoring the media feature also does not establish WCAG conformance by itself; every applicable success criterion must still pass.

What Standards Actually Say

The media feature reports a preference

The current Media Queries Level 5 specification defines prefers-reduced-motion as a discrete feature with two values:

• no-preference: the user has made no preference known. It evaluates false in a boolean media-query context.
• reduce: the user prefers an interface that removes or replaces motion-based animation that can trigger discomfort in people with vestibular motion sensitivity or distraction in people with attention deficits.

The same section says the feature detects a request that the system minimize the amount of non-essential motion it uses. The specification is normative except for material explicitly marked otherwise, but it is currently a W3C Working Draft rather than a Recommendation, as stated in its status section.

WCAG separates several motion hazards

WCAG 2.2 is a W3C Recommendation. Its success criteria are normative; its Understanding documents and techniques are informative and do not create conformance requirements.

The relevant requirements answer different questions:

• Interaction-triggered motion: Success Criterion 2.3.3, Animation from Interactions (Level AAA), requires motion animation triggered by interaction to be disableable unless it is essential to the functionality or information. WCAG defines motion animation as interpolated movement or smooth transition. Changes to color, blur, and opacity alone are excluded when they do not alter perceived size, shape, or position.
• Automatically started movement: Success Criterion 2.2.2, Pause, Stop, Hide (Level A), requires a pause, stop, or hide mechanism for non-essential moving, blinking, or scrolling information that starts automatically, lasts more than five seconds, and appears alongside other content. Auto-updating information has a similar control requirement without the five-second exception.
• Flashing: Success Criterion 2.3.1, Three Flashes or Below Threshold (Level A), prohibits more than three flashes in any one-second period unless the flash is below the defined general or red flash thresholds. Success Criterion 2.3.2, Three Flashes (Level AAA), removes the size and brightness exception.

The five-second and three-flash values are real numeric WCAG thresholds, but neither measures whether a reduced-motion variant is reduced enough. They govern separate distraction and seizure risks.

WCAG's sufficient technique uses an essential-or-suppressed test

The informative CSS technique C39 and JavaScript technique SCR40 are sufficient ways to meet Success Criterion 2.3.3. Their test procedure is the closest W3C material comes to a practical diagnostic:

1. Enable the system reduced-motion setting.
2. For every interactive element that triggers motion animation, determine whether the motion is essential.
3. If it is not essential, verify that the motion animation is suppressed.

Techniques are not normative or the only ways to conform. Still, their expected result, essential or suppressed, is clearer than an arbitrary reduction in duration or distance. Understanding 2.3.3 also recommends avoiding unnecessary animation, providing an off control, or using the system reduced-motion preference.

The phrase spatial motion is not a term from the media-query specification or WCAG. In this note it is shorthand for the part of WCAG's motion animation definition that concerns changes in perceived position, size, or shape. WCAG explicitly excludes color, blur, and opacity changes only when they do not alter those perceived spatial properties. This makes spatial motion a useful high-priority review category, not the complete meaning of prefers-reduced-motion.

Platform guidance permits thoughtful replacement

Apple's Human Interface Guidelines for accessibility are platform guidance, not a web standard or WCAG requirement. They tell apps to reduce automatic and repetitive animations when Reduce Motion is active, especially zooming, scaling, and peripheral motion. Suggested responses include tightening springs to reduce bounce, keeping gesture-driven animation directly coupled to the gesture, avoiding animated depth changes, replacing movement on the x, y, and z axes with fades, and avoiding animation into or out of blur. Apple exposes the setting as a Boolean through isReduceMotionEnabled, which likewise supplies no numeric reduction level.

MDN's prefers-reduced-motion example provides a concrete web replacement pattern. Its default pulse animation repeatedly scales a box. When reduce matches, the example replaces that effect with a slower dissolve animation: the box remains spatially stationary while its opacity oscillates between 1 and 0.3. The reduced-motion rule also changes the box's background from purple to green and adds an overline, but those are static markers that make the active media-query branch visible, not properties animated by dissolve. MDN describes the replacement as a more muted animation that is not a vestibular motion trigger. This example supports the distinction between reducing motion and rejecting all animation. It is implementation documentation, not a normative standard, a universal claim that opacity changes are harmless, or a benchmark for how much reduction is sufficient.

What Standards Do Not Say

The reviewed sources do not define:

• a required percentage reduction in duration, distance, speed, acceleration, area, or number of animated elements;
• a universal maximum duration, such as 100 ms or 200 ms, for a retained effect;
• a universal maximum travel distance or scale factor;
• a scoring function that combines duration, distance, easing, field of view, contrast, repetition, and user control;
• a certification benchmark for “reduced enough”; or
• a rule that adding @media (prefers-reduced-motion: reduce) makes a page WCAG conformant.

There is also no standards basis for treating no-preference as permission to ignore the independently applicable WCAG requirements on automatic movement or flashing. It means only that the user has not expressed this particular preference through the system.

Practical Diagnostic

The following is synthesized practice, not a standard.

Test every representative page and state twice, with the system setting off and on. In the reduced-motion run:

1. Inventory motion by trigger. Record motion that starts on load, timer, scroll, hover, focus, pointer or keyboard activation, route change, data update, drag, and media playback. Include CSS, JavaScript, canvas, SVG, images, video, and third-party content.
2. Classify necessity effect by effect. Call motion essential only when removing it would fundamentally change information or functionality and no conforming alternative can provide the same result. That is WCAG's definition of essential, not a synonym for useful, branded, polished, or expected.
3. Suppress non-essential motion-based animation. Prioritize effects that change perceived position, size, or shape, including parallax, simulated camera movement, large translations, zoom and scale transitions, animated depth, bounce, auto-panning, and peripheral loops. Also review other animated effects for distraction rather than assuming that non-spatial means safe. Prefer an immediate state change or a restrained replacement that does not flash.
4. Constrain retained essential motion. Keep it directly controlled by the user's action where possible, avoid overshoot and oscillation, limit its extent, and provide pause or stop controls when applicable.
5. Run the separate WCAG checks. Test automatic movement against 2.2.2, flashes against 2.3.1 and the claimed conformance level, and interaction-triggered motion against 2.3.3 when targeting AAA. Passing one check does not imply passing the others.
6. Check function and meaning without motion. Every task, state change, relationship, progress indication, and error must remain available. A reduced variant that removes information or traps the interface is not an accessible alternative.
7. Verify live preference changes where supported. Toggle the setting while the page is open. New and running effects should follow the current value.

A concise release gate is: with reduced motion enabled, every non-essential motion-based animation is absent or replaced; spatial effects receive particular scrutiny; every retained motion has a documented essential purpose or user control; all tasks and information remain intact; and the independent WCAG movement and flashing criteria pass. This is a defensible team policy, not a W3C-defined benchmark.

Edge Cases and Examples

• Accordion or menu: Instantly revealing the new state, or using a simple fade without perceived size or position change, avoids WCAG's motion-animation category. That exclusion is not proof that every fade is harmless or that it fully honors the broader media-query preference. Sliding the panel a shorter distance remains motion animation. For an AAA 2.3.3 target, it should be disableable unless essential.
• Route transition: A page-flip, push, zoom, or shared-element flight is non-essential in most products and should be suppressed under the W3C sufficient-technique test. A direct swap or restrained fade can preserve the state change without simulated travel.
• Scrolling: Movement needed to scroll content is essential to that interaction. Added parallax, scroll-linked zoom, or horizontal fly-ins are separate, usually non-essential effects, as explained in Understanding 2.3.3.
• Data visualization or animation authoring tool: Motion may itself be the information being inspected. Preserve access to that essential content, but do not assume surrounding transitions, autoplay, or looping previews are also essential. Provide explicit play, pause, and replay controls.
• Video and animated images: The media query does not automatically rewrite pixels inside a video, GIF, or third-party canvas. Teams must decide whether to pause autoplay, substitute a still image, expose controls, or provide an alternate asset. Flashing content still needs its own WCAG analysis.
• Very short animation: Being under five seconds avoids only one condition in 2.2.2 for certain automatic movement. It does not make an effect satisfy 2.3.3 or prove that it is reduced enough for the preference.

Sources

Normative standards

• W3C, Media Queries Level 5: prefers-reduced-motion, Working Draft, 19 February 2026.
• W3C, Web Content Accessibility Guidelines 2.2, Recommendation, 12 December 2024.
• W3C, WCAG 2.2 Success Criterion 2.2.2: Pause, Stop, Hide.
• W3C, WCAG 2.2 Success Criterion 2.3.1: Three Flashes or Below Threshold.
• W3C, WCAG 2.2 Success Criterion 2.3.2: Three Flashes.
• W3C, WCAG 2.2 Success Criterion 2.3.3: Animation from Interactions.

Informative W3C guidance

• W3C WAI, Understanding Success Criterion 2.2.2.
• W3C WAI, Understanding Success Criterion 2.3.1.
• W3C WAI, Understanding Success Criterion 2.3.2.
• W3C WAI, Understanding Success Criterion 2.3.3.
• W3C WAI, Technique C39: Using the CSS prefers-reduced-motion query to prevent motion.
• W3C WAI, Technique SCR40: Using the CSS prefers-reduced-motion query in JavaScript to prevent motion.

Platform guidance

• Apple, Human Interface Guidelines: Accessibility, Motion.
• Apple, UIAccessibility.isReduceMotionEnabled.

Implementation documentation

• MDN Web Docs, prefers-reduced-motion examples, “Toning down the animation scaling.”