Status: Phase 1 stub. Matures in Phase 5 per §8.1.

Statement

Every named motion token (F-6) has a documented reduced-motion equivalent. When prefers-reduced-motion: reduce is active, the equivalent is what plays. Reduced motion is never "no animation at all" by default — most state changes still need to be marked, just with a smaller delta (an opacity fade in place of a translate, a one-frame snap in place of a curve).

Why

prefers-reduced-motion: reduce is set by users with vestibular sensitivity, by users on low-power-mode, by accessibility advocates, and by some users who simply prefer calmer interfaces. Honouring the preference well means the user still understands what changed; honouring it lazily ("set all transitions to 0ms") means the user loses cause-and-effect cues that motion was carrying.

The audit found three surfaces where reduced motion was implemented as a blanket transition: none !important — interactions worked but felt jarring, like cuts in a film with no transitions at all. The cause-and-effect was lost.

How

Each motion token in tokens.json (Phase 2) ships with a reduced variant:

Token	Default	Reduced
`motion.enter`	translate-y + fade, 220ms ease-out	fade, 80ms linear
`motion.exit`	translate-y + fade, 180ms ease-in	fade, 60ms linear
`motion.shift`	layout-shift curve, 260ms	snap, 1 frame
`motion.attention`	pulse, 1200ms	static highlight, no pulse
`motion.handoff`	shared-element transform, 320ms	crossfade, 120ms

Components consume the token; the reduced fallback applies automatically via the media query at token-resolution time.

Phase 5 deepens this stub with the full token table, per-component citations, and audit counter-examples.