Motion & animation remediation — high-level pointers (local fallback)

oricorio tells you what motion is unsafe or expensive on a page. The detailed, current motion & reduced-motion standards — house duration budgets, which properties are compositor-safe, how to structure a prefers-reduced-motion block — live in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• No reduced-motion path — wrap an @media (prefers-reduced-motion: reduce) block that keeps opacity/colour transitions and drops transform-based movement. Reduced means fewer and gentler, not zero.
• Infinite animation with no pause — give the user a control to stop it, or suppress it entirely under prefers-reduced-motion.
• Layout-triggering properties — re-express motion as transform (translate/scale) and opacity; watch for transition: all, which sweeps up layout properties by accident.
• Long one-shot transitions — bring UI motion under roughly 300ms; looping motion (spinners, progress indicators) is exempt and not a target for shortening.
• An unreadable stylesheet is a coverage gap, not a clean page — a cross-origin sheet that throws on .cssRules means part of the site’s motion was never checked; note it rather than assuming PASS.
• JS-driven motion is out of scope — Web Animations API calls and inline styles set at runtime don’t show up in the CSSOM this audit reads; a manual check is still needed for those.
• Prioritize serious over advisory — a missing reduced-motion path or an unpausable infinite animation is a real accessibility failure; a slightly long transition is a polish item.

Full playbook → the team wiki’s motion & reduced-motion standards.