home / skills / dylantarre / animation-principles / accessibility-issues

This skill helps you make animations accessible by applying Disney principles to reduce motion, manage focus, and announce changes for assistive technologies.

npx playbooks add skill dylantarre/animation-principles --skill accessibility-issues

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.4 KB
---
name: accessibility-issues
description: Use when animation excludes users with vestibular disorders, cognitive disabilities, or assistive technology needs
---

# Accessibility Issues

Make animations inclusive using Disney's principles thoughtfully.

## Problem Indicators
- Motion sickness complaints
- Vestibular disorder triggers
- Screen reader confusion
- Cognitive overload
- Seizure risk (flashing)
- Keyboard focus lost during animation

## Diagnosis by Principle

### Squash and Stretch
**Issue**: Excessive distortion causes disorientation
**Fix**: Reduce or eliminate squash/stretch for users with `prefers-reduced-motion`. Use opacity changes instead.

### Secondary Action
**Issue**: Too many moving elements
**Fix**: Limit to one animated element at a time. Secondary actions should be subtle or removed.

### Exaggeration
**Issue**: Dramatic motion triggers vestibular responses
**Fix**: Reduce scale, rotation, and position changes. Keep movements small and predictable.

### Timing
**Issue**: Animations too fast or too slow
**Fix**: Provide consistent, predictable timing. Avoid sudden speed changes.

### Arcs
**Issue**: Curved motion paths cause tracking difficulty
**Fix**: Use linear motion for essential UI. Save arcs for optional decorative elements.

## Quick Fixes

1. **Respect `prefers-reduced-motion`** - Always check and honor
2. **No autoplay animation** - Let users trigger motion
3. **Keep focus visible** - Never animate focus indicator away
4. **Announce changes** - Use ARIA live regions for dynamic content
5. **Provide pause controls** - For any looping animation

## Troubleshooting Checklist

- [ ] Does animation respect `prefers-reduced-motion`?
- [ ] Is there a way to pause/stop animations?
- [ ] Are state changes announced to screen readers?
- [ ] Does keyboard focus remain visible and logical?
- [ ] Is flash rate under 3 per second?
- [ ] Can users complete tasks without animation?
- [ ] Are animations triggered by user action (not autoplay)?
- [ ] Test with screen reader enabled

## Code Pattern

```css
@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}
```

```js
// Check preference in JS
const prefersReducedMotion = window.matchMedia(
  '(prefers-reduced-motion: reduce)'
).matches;
```

Overview

This skill helps creators identify and fix animation patterns that exclude users with vestibular disorders, cognitive disabilities, or assistive technology needs. It maps common problems to Disney-style animation principles and offers practical fixes to make motion accessible. Use it to audit animations and implement quick, standards-based remediations.

How this skill works

The skill inspects animation behaviors against accessibility indicators like motion sickness reports, screen reader confusion, flashing frequency, and keyboard focus loss. It diagnoses issues by principle (e.g., squash-and-stretch, timing, arcs) and provides concrete fixes such as honoring prefers-reduced-motion, simplifying secondary actions, and offering pause controls. It also supplies a troubleshooting checklist and code patterns for immediate implementation.

When to use it

  • Designing UI motion or characters for web and app interfaces
  • After user reports of nausea, dizziness, or task difficulty
  • Before shipping features with autoplaying or looping animations
  • When animations disrupt keyboard navigation or screen readers
  • During accessibility audits and remediation sprints

Best practices

  • Respect the user preference prefers-reduced-motion and implement a global reduction strategy
  • Avoid autoplay; require user initiation for nonessential motion
  • Limit moving elements: prioritize one clear animated object and minimize secondary actions
  • Keep timing consistent and predictable; avoid abrupt speed changes
  • Ensure keyboard focus stays visible and not moved or hidden by animation
  • Provide controls to pause, stop, or reduce looping motion and use ARIA live regions for state changes

Example use cases

  • Convert a decorative looping hero animation to a static image when prefers-reduced-motion is set
  • Replace dramatic squash-and-stretch with subtle opacity or scale changes for sensitive users
  • Add pause/stop buttons to decorative carousels and ensure they are keyboard accessible
  • Simplify complex UI transitions into linear movements for essential state changes
  • Audit a game or interactive lesson for flashing rates and reduce to under three flashes per second

FAQ

How do I detect a user’s motion preference in code?

Use the prefers-reduced-motion media query in CSS or window.matchMedia('(prefers-reduced-motion: reduce)') in JavaScript to adapt animations.

What if animation is essential to understanding content?

Keep essential motion minimal, provide a non-animated alternative, and ensure state changes are fully accessible via ARIA announcements and keyboard focus management.