animation-safe

name	animation-safe
description	Audit animations and transitions for motion accessibility, performance safety, and design intent. Enforces prefers-reduced-motion compliance and blocks layout-triggering transitions.
version	0.1.0
level	2
triggers	["animation safe","animation audit","check animations","motion review","/animation-safe"]
context_files	["context/project.md"]
steps	[{"name":"Inventory","description":"List all CSS transitions, keyframe animations, and JavaScript-driven motion in scope."},{"name":"Accessibility Check","description":"Verify prefers-reduced-motion is handled for every animation. Flag missing wrappers."},{"name":"Performance Check","description":"Identify transitions on layout-triggering properties. Flag non-compositor animations."},{"name":"Design Intent Check","description":"Audit for gratuitous animations — entrance on every element, looping animations without purpose, identical timing everywhere."},{"name":"Verdict","description":"BLOCK/WARN/CLEAN per animation with specific remediation."}]

Animation Safe Skill

Audit animations before they ship. Motion that ignores accessibility preferences, triggers layout recalculation, or exists purely as decoration creates real problems — vestibular disorders, janky 60fps misses, and UI that feels busy rather than intentional.

What Claude Gets Wrong Without This Skill

Claude adds animations because they look good in the moment. transition: all 0.3s ease gets added to every interactive element. Scroll-triggered fade-ins appear on every section. CSS keyframes loop indefinitely. None of it is gated on prefers-reduced-motion. None of it distinguishes compositor-safe properties from layout-triggering ones.

The second failure: Claude writes transition: all because it is the shortest transition declaration. transition: all transitions every CSS property simultaneously — including layout properties like width, height, padding, margin. This forces layout recalculation on every frame, destroying performance on lower-end hardware and causing visual glitches when other properties change.

Motion Accessibility — The Core Requirement

The W3C defines two motion-sensitive accessibility needs:

Vestibular disorders — large-scale motion (parallax, zoom, full-screen transitions) can trigger nausea or disorientation. Approximately 35% of adults over 40 have vestibular dysfunction.

Attention/cognitive sensitivity — looping, blinking, or auto-playing animations can make a page unusable for users with attention or sensory processing differences.

The CSS media query prefers-reduced-motion: reduce is set by users in their OS accessibility settings (macOS: Settings → Accessibility → Display → Reduce Motion; Windows: Settings → Ease of Access → Display → Show animations). When set, it signals that the user wants minimal motion.

This is not optional. WCAG 2.3.3 (AAA) requires that motion triggered by interaction can be disabled. Practically, all non-essential animation should respond to this preference.

Required Pattern

Every animation block must have a prefers-reduced-motion counterpart:

/* Allowed: transition on compositor-safe properties */
.button {
  transition: background-color 0.2s ease, box-shadow 0.2s ease;
}

/* Required: reduced motion override */
 (: reduce) {
   {
    : none;
  }
}