Will It Vibe?Animation library used with no reduced-motion handling in the project
Part of Documentation, UX & Accessibility, which counts for 15% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
The project imports framer-motion or GSAP to drive animation, but no file anywhere (CSS media query or a JS matchMedia check) tests prefers-reduced-motion, so users who need reduced motion get every transition at full strength regardless of their OS setting. Guard the animation config with a prefers-reduced-motion check, either through matchMedia in JS or by disabling the animated variant in CSS. Heuristic and project-wide by necessity, since JS-driven animation is not tied to one stylesheet; a reduced-motion check that exists elsewhere in the codebase silences this for every file.
Why it matters
Importing framer-motion or GSAP without any prefers-reduced-motion handling anywhere in the project means every JS-driven animation plays at full strength regardless of the user's OS setting, since CSS-only reduced-motion media queries cannot touch animations that are entirely orchestrated in JavaScript. This is easy to miss because there is no visual sign anything is wrong; the animation just always runs.
How to fix it
Check prefers-reduced-motion with window.matchMedia("(prefers-reduced-motion: reduce)").matches (or the animation library's own reduced-motion hook, where one exists) before configuring animation durations/transforms, and fall back to an instant or near-instant transition when it is true. Framer Motion exposes a useReducedMotion() hook for exactly this; GSAP can gate its timelines behind the same matchMedia check.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo