What are Movement-Triggered Disorders in Software?
Movement-triggered disorders: how motion, flashing and shake gestures affect users, what WCAG 2.2 requires, and how to build and test for it.
What are movement-triggered disorders in software?
"Movement-triggered disorders" is not a WCAG term. It describes people for whom motion causes symptoms or errors: vestibular disorders (dizziness, nausea, headaches from animation), photosensitive seizures from flashing, and motor conditions such as tremor, where shaking or tilting a device fires an action by accident. Good design limits motion, lets users switch it off and never makes motion the only way to do something.
Three groups, three different risks
- Vestibular disorders. The W3C notes that reactions include dizziness, nausea and headaches, and can be severe. MDN names scaling or panning large objects as typical triggers. Parallax, zooming transitions and auto-scrolling are the usual culprits.
- Photosensitive seizures. Rapid flashing is the trigger, not movement as such. WCAG 2.3.1 (level A) says a page must not flash more than three times in any one second, unless the flashes are below the general and red flash thresholds.
- Motor conditions. Users with tremors can trigger shake or tilt features by accident, and some users cannot make the gesture at all. Path-based and multi-finger gestures and tiny tap targets cause similar problems.
What WCAG 2.2 requires
- 2.3.1 Three Flashes or Below Threshold (A): no content flashing more than three times per second above the thresholds.
- 2.2.2 Pause, Stop, Hide (A): moving, blinking or scrolling content that starts automatically, lasts more than five seconds and sits beside other content needs a way to pause, stop or hide it.
- 2.3.3 Animation from Interactions (AAA): motion animation triggered by interaction can be disabled, unless essential. It is the strictest of the set, so many teams treat it as a goal.
- 2.5.4 Motion Actuation (A): anything done by shaking or tilting must also work through a normal control, and the motion response can be turned off. A pedometer-style function where motion is essential is exempt.
- 2.5.1 Pointer Gestures (A): multi-point or path-based gestures need a single-pointer alternative, unless the gesture is essential, such as a signature.
- 2.5.8 Target Size, Minimum (AA): pointer targets are at least 24 by 24 CSS pixels, with exceptions such as spacing and inline links.
The overall framework is covered in WCAG, and video and audio are covered in accessible media types.
How to build it
Respect the operating system setting through the prefers-reduced-motion media query. MDN describes it as telling the browser that the user prefers an interface that removes, reduces or replaces motion-based animations:
.hero { animation: slide-in 600ms ease-out; }
@media (prefers-reduced-motion: reduce) {
.hero { animation: none; }
}
Also add an in-app switch for people who cannot reach the OS setting, never autoplay looping video without a pause control, give every shake or tilt gesture a visible button, and replace motion with a fade instead of removing the feedback entirely.
Common mistakes
- Respecting reduced motion in CSS but forgetting JavaScript-driven animation, carousels and autoplaying video.
- Removing all feedback instead of swapping a large movement for a gentle one.
- Shake to undo with no Undo button.
- Assuming a passing automated scan means the page is safe. A tool cannot judge whether an animation makes someone dizzy.
Testing and monitoring
Turn on "reduce motion" in your OS or browser dev tools and walk through key journeys by hand, then add a few checks to your manual accessibility tests. Automated accessibility testing catches only part of the picture, so keep it as a regression alarm. Heavy animation also costs performance: LoadFocus page speed monitoring runs scheduled Lighthouse audits, so you see when a new effect slows the page. More on what automated checks can and cannot say is in this post on performance testing and accessibility.
FAQ: Movement-triggered disorders
Is "movement-triggered disorder" an official accessibility term?
No. WCAG talks about specific success criteria such as flashing, animation from interactions and motion actuation. The phrase is a convenient umbrella for the conditions those criteria protect.
What is prefers-reduced-motion?
A CSS media feature that reports whether the user has asked their device to reduce motion. You use it to remove or soften animations for those users.
Is flashing content the same as animation?
No. Flashing is rapid brightness change and can trigger seizures, so WCAG 2.3.1 limits it at level A. Animation from interactions is a separate concern, mainly for vestibular disorders.
Do I need to avoid all animation?
No. Small, purposeful transitions are fine. Avoid large scaling, panning and parallax for users who ask for reduced motion, and offer a pause control for auto-playing content.
Can an automated tool find these problems?
Only some of them, and not whether an animation is uncomfortable. Check by hand with reduced motion on.
Related terms
- What is an Accessible Layout in Web and Mobile?
- ARIA: Accessible Rich Internet Applications
- What is Automated Accessibility Testing?
- What is User Experience (UX)? Definition, Pillars, Examples
- What is an Accessibility Conformance Report (ACR)?
- Accessibility Conformance Testing (ACT) Explained
- Accessibility Definition: What It Means in Tech
- Assistive Technology (AT): Definition, Types, Web Examples
Related LoadFocus Tools
Put this concept into practice with LoadFocus, the same platform that powers everything you just read about.