Reduced motion and accessibility
How Keyframery respects prefers-reduced-motion: every cut becomes a short fade, and motion never gets in the way of focus or screen readers.
Reduced motion
When the system setting prefers-reduced-motion: reduce is on, every cut becomes a short fade:
- nothing moves, scales or blurs
- fades last between about 120 and 160 ms
- the page doesn't sink behind sheets and drawers
- no ghosts, and no toasts flying from the button you pressed
- ValueCut swaps the value instantly
- LoadCut still waits before showing a skeleton, so it doesn't flash, then fades
You don't need to do anything for this. It's on for everyone who asks their system for less motion.
To check it, open Chrome DevTools, then Rendering, then Emulate CSS media feature prefers-reduced-motion.
Focus and keyboard
Keyframery never moves focus and never adds focusable elements. Opening, closing and focus trapping stay with Base UI or Radix, exactly as in stock shadcn. Keyboard presses count as the start of a cut just like clicks, so a dialog opened with Enter grows from the focused button.
Screen readers
- Ghosts, the copies Keyframery animates when something leaves, are
aria-hiddenand ignore the pointer. - ValueCut's rolling digits are
aria-hidden. A visually hidden copy always holds the current value. Addannounceto read changes out witharia-live="polite". - LoadCut sets
aria-busywhile loading.
Questions
Does Keyframery respect prefers-reduced-motion?
Yes. When the system asks for reduced motion, every cut becomes a short fade of about 120 to 160 ms: nothing moves, scales or blurs.
How it works
How one <Cuts /> line animates shadcn/ui: the six kinds of interface change, how enter and exit animations play, and how portaled dialogs keep settings.
Base UI vs Radix
Keyframery animates shadcn/ui the same way on Base UI and Radix. What differs underneath: open-state attributes, exit handling, drawers and toasts.