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.
Step-by-step resolution
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.
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.
Related
- Motion Testing & Automation — the parent topic
- WCAG Animation Conformance — the criteria findings map onto
- Automating Reduced-Motion Checks in CI — turning findings into automated checks