Audit interface motion before shipping

A motion audit checks whether movement helps people understand the interface and whether the same task works without it. Review each effect in context, including rapid input, keyboard use, reduced motion, and failure states. An automated accessibility scan alone will not assess the experience of movement.

Inventory the effects

List entrances, hover effects, list movement, page transitions, loading effects, scrolling, and persistent decoration. For each, write the event that starts it and the information it communicates. “Looks premium” is a visual preference, not an interaction explanation.

Use a review sheet

For a fictional filtered list, a useful note is “Explains existing cards moving to new positions; repeated filtering cancels and settles before remeasurement.” That is more actionable than “smooth animation.”

Run the adverse sequences

Audit these effects with the supplied code and observed behavior.
Check one ordinary interaction, rapid repeated input, unmount during motion,
live reduced-motion change, keyboard focus, and a slow device.
Separate code concerns from behavior actually observed in a browser.
Do not claim an accessibility certification or performance improvement
without the corresponding evidence.
Effects and observations: [paste]

Remove effects that do not earn their attention

A looping illustration beside a form may distract from completing it. A reveal that keeps text hidden until JavaScript runs can block reading. A smooth-scroll effect may need an immediate path when reduced motion is active. Removing an effect can be the correct result of the audit.

Record defects with a reproducible sequence and expected behavior. “Filter twice within the first transition; final cards overlap” is a useful report. Keep accessibility and performance claims bounded to what you measured. W3C’s animation guidance and MDN’s preference documentation support the review, but the full experience still needs practical testing in your actual interface.