Manual Motion Accessibility Audit Checklist

Part of Motion Testing & Automation in Accessible Motion Architecture.

The problem

An automated suite checks that reduced motion removes animations and that no page exceeds a flash threshold. It still misses the things that matter most: a modal whose entrance animation moves focus before the content exists, a carousel whose pause button disappears when the pointer leaves, a tooltip that is unreachable by keyboard, an animated progress indicator that is never announced. Automation cannot judge whether motion communicates correctly.

A manual pass is the complement. Done in a fixed order, it takes under an hour per flow and finds a different class of defect.

Root cause analysis: what only a person can judge

Automated checks answer yes-or-no questions: does an animation run, does a contrast ratio pass, does an element have a name. Four kinds of question need judgement.

Is the motion essential or decorative? A spinner communicates that work is happening; a parallax hero does not. The reduced-motion branch should keep the first and remove the second, and only a person can tell which is which.

Does the animation carry meaning that is otherwise unavailable? A list item sliding out to indicate deletion must also be announced; an arrow that rotates to show expansion must be backed by aria-expanded.

Is the timing humane? Whether a toast stays long enough, whether a carousel advances too fast, whether an entrance delays usable content — all judgement calls.

Is the experience coherent at magnification? At 400% zoom, an element animating in from off-screen may arrive outside the magnified viewport; a sticky header that shrinks may cover the content it was moving away from.

The audit is structured as five passes because each requires a different setup, and switching tools repeatedly is what makes ad-hoc reviews incomplete — the same reasoning behind the criteria in WCAG animation conformance.

Which pass catches which problemFive passes, each with its own setup and its own class of finding.Which pass catches which problemSetupTypical findingsInventoryNormal browsingUndocumented or forgotten animationsReduced motionOS setting or emulationMissing branches, lost feedbackKeyboardNo pointerLost focus, unreachable controlsScreen readerNVDA, VoiceOver or NarratorSilent changes, noisy regionsZoom andmagnification200-400% zoomOff-screen arrivals, covered content
Five passes, each with its own setup and its own class of finding.

Step-by-step resolution

The five-pass auditRun in order; each pass assumes the previous one's findings are recorded.The five-pass audit1Walk the flow and list every animation with its trigger and purpose.An inventory to check against2Enable reduced motion and repeat the flow.Branch coverage and lost-feedback findings3Repeat using only the keyboard.Focus and reachability findings4Repeat with a screen reader.Announcement findings5Repeat at 200% and 400% zoom.Magnification findings6Record each finding with criterion, impact and suggested fix.
Run in order; each pass assumes the previous one's findings are recorded.

The checklist

Pass 1 — Inventory. For each animation: what triggers it, what it communicates, how long it lasts, whether it loops, and whether it can be interrupted.

Pass 2 — Reduced motion. With the preference enabled:

  • Decorative motion — parallax, ambient loops, entrance travel — is gone, not merely faster.
  • Essential feedback still exists in some form: loading is still indicated, state changes are still visible.
  • Nothing depends on an animation completing: panels open, content appears, flows finish.
  • Auto-advancing content does not advance on its own.
  • No layout shifts were introduced by the reduced branch.

Pass 3 — Keyboard. Using Tab, Shift+Tab, arrows, Enter, Space and Escape:

  • Focus is visible at every step, including during and after animated changes.
  • Focus never lands on an element that is animating out or already hidden.
  • Opening an animated overlay moves focus into it; closing returns focus to the trigger.
  • Hover-triggered motion has a focus equivalent.
  • Pause controls for moving content are reachable and operable.

Pass 4 — Screen reader. With a screen reader running:

  • Content that appears with an animation is announced, or reachable where the user is.
  • Animated state changes — expanded, selected, busy — are exposed as ARIA state.
  • Live regions are not flooded by animation-driven updates.
  • Decorative animated graphics are hidden from the accessibility tree.
  • Nothing is announced twice because it animated.

Pass 5 — Zoom and magnification. At 200% and 400%:

  • Elements animating in arrive within the visible area.
  • Sticky and fixed elements do not cover content after their animation.
  • Motion does not require the user to track something across a magnified viewport.
  • Text remains readable throughout; nothing relies on seeing the whole viewport.
Time to complete one flow's auditTypical for a checkout or onboarding flow once the passes are familiar.Time to complete one flow's auditinventory + reducedkeyboard + screen readerzoom0102030405060 minutesinventory 10 minuteskeyboard 30 minuteszoom 50 minutes
Typical for a checkout or onboarding flow once the passes are familiar.

Recording findings so they get fixed

A finding needs four things to become a fix: where it happens, what the user experiences, which criterion or principle it relates to, and a suggested remedy. “Carousel keeps advancing with reduced motion enabled (WCAG 2.2.2; users cannot stop moving content; add a pause control and stop autoplay when the preference is set)” is actionable. “Carousel not accessible” is not.

Group findings by component rather than by page, because one component’s fix usually resolves findings across many pages, and rank them by how many users are affected rather than by how easy they are to fix. Feed the recurring ones back into automated checks so the same defect cannot return silently, which is the loop described in automating reduced-motion checks in CI.

Verification checklist

Constraints and trade-offs

  • Manual audits are time-consuming; run them per flow, not per page.
  • Screen reader behaviour differs between products; testing two is a reasonable minimum.
  • Auditors become accustomed to their own product’s motion and stop noticing it; rotate reviewers.
  • A checklist cannot cover everything; leave room for judgement findings.
  • Findings without owners are rarely fixed; assign them at the component level.

Frequently asked questions

What can a manual audit find that automation cannot?

Whether motion communicates correctly: essential versus decorative, whether meaning is available another way, whether timing is humane, and how motion behaves under magnification.

How often should a manual motion audit run?

Per major flow change, and at least once per release cycle for the core flows. Regressions should be caught by automated checks in between.

Which screen readers should be used?

At least two across different platforms, because announcement behaviour for live regions and state changes varies.

Why audit at 400% zoom?

At high magnification only part of the viewport is visible, so motion that arrives from off-screen or relies on seeing the whole page fails.