Designing micro-interactions that respect reduced motion
By uiux.ink ·
Operating systems let people ask for less motion, and browsers expose that preference through the prefers-reduced-motion media query. For some people large or continuous movement causes discomfort, so honouring the setting is an accessibility requirement rather than a nice-to-have.
Reduce, don't remove meaning
Reduced motion is not the same as no feedback. Keep state changes visible with colour, opacity or an instant position change, and remove the travel: springs, parallax, continuous loops and large translations.
Check the pointer, too
Pointer-driven effects such as magnetic buttons and tilting cards make no sense on touch screens, where there is no hover position. Gate them behind (hover: hover) and (pointer: fine) so phones get a plain, reliable control.
A checklist for every animated component
- The component is fully usable with animation disabled.
- Interactive elements stay native buttons and links, reachable with the keyboard and with a visible focus style.
- Decorative duplicates (such as the letters in a letter-swap effect) are hidden from assistive technology, and the real label is exposed once.
- Nothing loops forever unless it communicates ongoing work, like a loading state.
- Animations use transform and opacity so they never shift surrounding layout.
Every component in the uiux.ink library is reviewed against this list before it is published, and its integration prompt asks your coding agent to verify reduced-motion behaviour after integrating it.
Try it with real components
Browse the component index or create a free account to copy source and integration prompts.