Summary of "A framework for designing and engineering safe, resilient, & inclusive motion I Axe-con 2026"

Overview

Stefan Kitsu (Adobe Spectrum) opened by introducing himself and his lived experience with epilepsy. He explained that commonplace UI motion — especially loading spinners and celebratory animations — can cause real harm (motion sickness, migraines, panic, seizures) for many people, not just “edge cases.” He argued that animations must be designed to fail safely: treat motion with the same defensive mindset used in security or validation so failures don’t become hazards.

Animations must be designed to fail safely — anticipate failure modes and build guard rails so failures don’t become hazards.

Core thesis

Defensive animation: anticipate animation failure modes (infinite loops, flicker, resource spikes, orphaned/conflicting animations, conflicts with user settings) and build guard rails so users are protected when things break.
WCAG currently provides reactive guidance (pause/stop/hide, flashing limits), but the industry needs preventative, systemic practices that make safe defaults part of design systems.

Practical framework — five principles (with demos)

Time and count limits
- Enforce hard caps on duration and iteration (e.g., maximum seconds or maximum pulses).
- Monitor frequency to detect runaway flicker.
- Demo: infinite spinner vs spinner that times out and shows a clear failure message.
Circuit breakers and emergency stops
- Detect abnormal resource behavior or event storms and stop motion (like a fuse box).
- Provide global kill switches and emergency stop mechanisms.
- Respect prefers-reduced-motion (it reduces non-essential motion, not necessarily a full kill switch); also offer a final safety valve when needed.
- Demo: uncontrolled ripple effects vs ripples that clean themselves or a global “stop animation” action.
Fallbacks and safe failures
- Always provide a non-animated/readable alternative when motion fails.
- Replace failed/looping animation with a calm static state and clear guidance (e.g., “failed to load — retry”).
- Demo: skeleton screens that loop forever vs skeletons that time out and show actions/notifications.
Monitoring and consolidation
- Watch performance metrics (CPU, memory, frame rate) and reduce or stop motion when overloaded.
- Consolidate repeated/competing animations (batch error notifications instead of stacking many alerts).
- Demo: many overlapping error toasts vs a single batched notification.
State and coordination control
- Maintain a single source of truth for running animations; cancel and clean up previous animations before starting new ones.
- Sequence and debounce transitions to avoid overlap and “orphaned” animations.
- Demo: rapid tab switching causing overlapping transitions vs coordinated transitions that cancel/clean previous ones.

User agency and settings

Honor prefers-reduced-motion as a first-class signal.
Make motion controls discoverable, persist user choices, and provide manual toggles/shortcuts.
Offer static alternatives (opacity fades and content swaps are safer fallbacks) rather than simply disabling motion without an alternative.

Operationalizing defensive animation

Log and test for long-running or failed animations; include animation behavior in automated tests.
Treat animation bugs with the same severity as memory leaks or accessibility violations.
Bake these guard rails into design systems as defaults, not as afterthoughts.

Practical checklist (recommended before shipping any motion)

What happens when my animation fails?
Who gets hurt if it doesn’t stop?
How can I make it stop safely every single time?

Q&A highlights

Delight without harmful animation: build the motion, then offer slowed or static alternatives and let users choose.
Long-running or unpredictable processes: move from indeterminate → determinate states; after a short delay (a few seconds) present alternatives, determinate progress, or a notice.
Advertising vs safety: balance attention-grabbing needs with user safety; prioritize responsible design (companies can and have provided reduced-motion options).
Timing guidance: no universal rule — use hypotheses and test. Stefan suggested using under ~10 seconds as a heuristic for most components.
prefers-reduced-motion: replace micro-animations with safer alternatives (opacity fades, content swaps) rather than just disabling them.
Color/pattern concerns: red + motion is particularly problematic for sensitive users; avoid repetitive high-contrast patterns (e.g., zebra stripes) and consult resources about static graphics and epilepsy-safe design.

Resources and follow-up

Stefan shared demos, a longer article, his slide deck (QR code), and links (LinkedIn, AxCon Discord).
He’s writing a public book, “When Design Hurts” (on Substack), and offered an article about safe static graphics for epilepsy.