Motion is the accessibility frontier most design systems never audit, because motion is hard to see as a category until it makes someone sick. A parallax scroll, an auto-playing background loop, a card that zooms in on hover, a page transition that slides the whole viewport - each looks like polish and each can trigger nausea, dizziness, or migraine in a user with a vestibular disorder, and in 2026 a lot of that motion is being generated by Runway or Adobe Firefly Video and dropped into products with no accessibility pass at all. This lesson audits motion the way the previous one audited tokens: against named criteria, with AI doing the structured analysis and you owning the judgment. You will audit a generated motion sample against WCAG 2.3.3 Animation from Interactions and against correct prefers-reduced-motion behavior, and you will walk away with a motion-accessibility findings memo and a prefers-reduced-motion token recommendation your system team can adopt - turning motion from an unaudited liability into a governed, accessible-by-default part of the system.

Why Motion Is the Unaudited Frontier

Ask a design team to show you their accessibility work and they will show you contrast audits, focus states, alt text, maybe target sizes. Ask about motion and the room goes quiet, because motion accessibility is genuinely harder to reason about than color. Contrast is a number you can compute. Motion is a behavior over time, and its harm is invisible to anyone who does not experience it - a designer without a vestibular disorder watches a parallax hero and sees elegance, while a user with one watches the same hero and feels the floor tilt. The harm is real, common (vestibular disorders affect a meaningful share of the population), and completely outside the experience of most of the people shipping the motion.

This gap got wider in 2026 because motion got cheap to generate. Runway and Adobe Firefly Video produce polished motion samples in seconds, and that motion flows into onboarding loops, empty-state animations, hero backgrounds, and transitions without anyone asking whether it is safe. The generators optimize for impressive, not for accessible, and impressive motion - large movement, parallax, zoom, rapid change - is frequently exactly the motion that triggers vestibular symptoms. So the same forces making motion abundant are making it abundantly risky, and the audit discipline has not kept up. A senior IC's job is to close that gap: to make motion auditable against named criteria, the same way contrast already is.

The Two Things You Are Auditing

A motion accessibility audit checks two related but distinct things, and conflating them is the most common mistake. The first is whether the motion itself is safe and controllable - governed by WCAG 2.3.3. The second is whether the system correctly respects a user's stated preference to reduce motion - governed by prefers-reduced-motion. They are different questions: the first asks "is this animation harmful or excessive?" and the second asks "when a user has said 'I don't want motion,' does the product actually honor that?" A product can pass one and fail the other, and a complete audit covers both.

WCAG 2.3.3: Animation From Interactions

WCAG 2.3.3 Animation from Interactions (a Level AAA criterion, but the right bar for a system that takes accessibility seriously) says that motion animation triggered by a user interaction can be disabled, unless the animation is essential to the functionality or information being conveyed. The key words are "triggered by interaction," "can be disabled," and "essential." A hover-zoom, a scroll-driven parallax, a transition that fires when you click - these are interaction-triggered motion, and 2.3.3 requires that a user be able to turn them off, unless the motion is genuinely essential (a progress indicator's movement, for example, conveys information and is essential). The audit asks, for every piece of interaction-triggered motion: can it be disabled, and if it cannot, is it truly essential or merely decorative? Decorative motion that cannot be disabled fails.

prefers-reduced-motion: Honoring the Stated Preference

The second axis is the prefers-reduced-motion media query, the mechanism by which a user tells their operating system "reduce motion," which the browser exposes to your product. Correct behavior is that when a user has set this preference, your product removes or substantially reduces non-essential motion - replacing a slide transition with a simple fade or an instant change, stopping auto-playing loops, removing parallax. The audit checks whether the product actually responds to the query at all (many do not), and whether its response is correct (reducing motion meaningfully, not just trimming one animation while leaving the nauseating parallax running). This is where AI-generated motion fails most often, because a Runway clip dropped into a product has no prefers-reduced-motion variant at all - it plays the same for everyone, including the user who explicitly asked it not to.

Two questions, not one: can the user turn this motion off (2.3.3), and when they have already said "reduce motion" at the OS level, does the product honor it (prefers-reduced-motion)? Generated motion routinely fails both, because it was made to impress, not to be controlled.

How AI Audits Motion, and What You Still Have to See

Motion is harder to hand to AI than contrast, because there is no single number to compute - but a structured prompt turns it into a tractable analysis. You give Claude a precise description of the motion sample (or the motion specification: what moves, how far, how fast, what triggers it, how long it lasts) along with the named criteria, and ask it to evaluate against each. The model is good at the structured reasoning: classifying whether motion is interaction-triggered, identifying whether it is decorative or essential, flagging the specific properties that correlate with vestibular triggers (large-area movement, parallax, zoom, spin, rapid acceleration), and checking whether a prefers-reduced-motion variant is specified. With a good prompt it produces a thorough, criterion-by-criterion findings pass that a human would take much longer to assemble.

What the AI cannot do is feel the motion, and that limit is sharper here than anywhere else in accessibility. The harm of vestibular-triggering motion is experiential, and neither you (likely) nor the model experiences it, so both of you are reasoning about a harm you cannot perceive. This is why the audit leans hard on the known triggers - the categories of motion documented to cause symptoms - rather than on anyone's judgment of whether a given clip "looks like a lot." The discipline is to treat the documented triggers as the standard and audit against them mechanically, exactly because the people running the audit are not the people who get hurt. The AI structures the analysis against the triggers and the criteria; you bring the knowledge of which motion is essential to your product's function, you make the disable-versus-essential calls, and you own a finding that protects users whose experience neither of you shares. Humility about the experiential gap is part of the craft.

Running the Audit on a Generated Sample

Take a concrete case: a Runway-generated background loop for an onboarding screen - a slow, large-scale drifting-gradient-with-floating-shapes animation, the kind that reads as premium and plays automatically on load. Run it through the audit.

Describe the motion precisely. Large-area movement (full background), continuous and auto-playing (not interaction-triggered in this case, which matters), slow but constant, with parallax-like depth between layers. Precision here is what lets the AI reason correctly - "a nice background animation" is not auditable; "full-viewport continuous parallax drift, auto-playing, ~20s loop" is.

Audit against 2.3.3. This motion is auto-playing, not interaction-triggered, so 2.3.3 (which is specifically about interaction-triggered motion) does not directly govern it - but the related principle does: auto-playing motion that lasts more than five seconds has its own considerations (2.2.2 Pause, Stop, Hide), and the user must be able to stop it. The audit flags that there is no pause control. This is exactly the kind of criterion-routing the AI helps with and you verify.

Audit against prefers-reduced-motion. The Runway clip has no reduced-motion variant. A user who set "reduce motion" at the OS level still gets the full parallax drift. This is the central failure: the motion does not respond to the stated preference at all. Finding: must provide a reduced-motion variant (a static gradient, or a vastly slower/smaller motion) gated on the media query.

Flag the trigger properties. Large-area movement plus parallax depth are both documented vestibular triggers, so even at slow speed this animation carries real risk for susceptible users, which raises the severity of the missing reduced-motion variant from "nice to have" to "harm prevention."

The Motion-Accessibility Findings Memo

The first artifact is a findings memo, structured like the token report but adapted to motion. Each finding names the motion element, the criterion or principle it was tested against (2.3.3, 2.2.2, or prefers-reduced-motion behavior), the specific issue, the trigger properties present, the severity (weighted by both the criterion and the vestibular-risk properties), and the recommended remediation. A finding reads: Element: onboarding background loop. Tested: prefers-reduced-motion behavior and 2.2.2 (auto-playing >5s). Issue: full-viewport parallax drift, auto-playing, no pause control, no reduced-motion variant. Triggers present: large-area movement, parallax depth. Severity: High (vestibular trigger with no reduced-motion path). Remediation: gate the loop on prefers-reduced-motion - serve a static gradient when reduced motion is requested - and add a pause control for the animated variant.

The memo's discipline mirrors the rest of the program: name the criterion so the finding is defensible, name the trigger properties so the severity is justified by documented risk rather than by anyone's feel for the clip, and propose a specific remediation rather than a vague "make it more accessible." Because motion harm is invisible to most reviewers, the memo has to be especially explicit about why a finding matters - it cannot rely on the reader seeing the problem, because by definition the reader who is not vestibular-susceptible will not. The trigger-property column does that work: it grounds the severity in the documented science of what causes symptoms, so a reviewer who feels nothing watching the clip still understands the harm.

The prefers-reduced-motion Token Recommendation

The second artifact is the system-level fix, and it is what makes this an L3 lesson rather than a per-screen one. Rather than fixing the onboarding loop in isolation, you recommend a prefers-reduced-motion token pattern the whole system adopts, so that respecting the preference becomes the default for every animated element, not a thing someone remembers to do per component.

The pattern works like this. The system defines motion tokens - durations, easing curves, distances - and a prefers-reduced-motion variant for each: a motion-duration-base that resolves to its normal value when motion is allowed and to 0ms (or a minimal value) when reduced motion is requested, an easing token, a distance token that collapses to zero translation under reduced motion. Any component built on these tokens automatically gets correct reduced-motion behavior, because the tokens carry the media-query response. This is the exact same leverage as the contrast token audit: instead of auditing motion screen by screen forever, you make the system's motion tokens reduced-motion-aware, and every component that uses them inherits the correct behavior. The recommendation specifies the token structure, the reduced-motion values, and the rule that all non-essential motion must be expressed through these tokens so the reduced-motion path is guaranteed rather than hoped for.

This also handles the generated-motion problem at the system level. The recommendation includes a rule that auto-playing generated motion (a Runway or Firefly Video clip) must ship with a reduced-motion fallback specified before it can enter the product - a static poster frame, typically - gated on the same token-driven query. That turns "we dropped in a cool Runway loop" from an unaudited liability into a governed pattern with a required accessible path, which is the only way to keep generated motion from quietly reintroducing the failure on every new screen.

The Judgment That Stays Human: Essential vs. Decorative

The one call the AI cannot make for you is whether a given piece of motion is essential, and it is worth dwelling on because it is where the audit's accuracy lives. 2.3.3 and the reduced-motion patterns both hinge on "non-essential" motion - essential motion is exempt, because removing it would destroy meaning or function. A loading spinner's motion is essential; remove it and the user does not know the system is working. A progress bar's fill is essential; it conveys state. A parallax hero is decorative; removing it costs nothing but elegance. The audit's correctness depends on classifying each piece of motion correctly, and that classification requires understanding what the motion communicates in your product, which is product knowledge the model does not have.

The trap is to over-claim essentialness to protect a beloved animation. A designer who insists the parallax hero is "essential to the brand experience" is misusing the word - essential in the accessibility sense means essential to functionality or information, not to aesthetic preference, and brand vibe is not function. The discipline is to be honest and strict: motion is essential only if its removal breaks the user's ability to understand or operate the interface, and almost all decorative motion fails that test. Holding this line is what keeps the reduced-motion path real, because every animation wrongly classified as essential is an animation that keeps playing for the user who asked it to stop. The senior IC is the person who can tell a designer their favorite animation is decorative and must reduce, and make that stick against the standard.

Why This Completes the Accessibility Picture

Motion is the axis of accessibility that gets skipped precisely because it is the hardest to perceive from the outside, which makes it the one where a rigorous, AI-assisted, criterion-based audit adds the most value. The contrast you can see and the token audit catches; the focus state you can tab to and check; but the motion harm is invisible to the people shipping it, so without a deliberate audit against named triggers and criteria, it ships unexamined essentially every time. Bringing motion into the same auditable, token-governed framework as contrast is what turns an accessibility practice from "the parts we can see" into something that covers the parts we cannot, which is exactly the parts that need a standard most.

And it is the right shape for 2026 specifically. The flood of cheap generated motion from Runway and Firefly Video means more motion is entering products, made by tools optimized for impact, with no accessibility consideration built in - the conditions for a quiet accessibility regression at scale. The token-governed, audit-backed approach is the countermeasure: it makes the reduced-motion path a system default that generated motion has to plug into, and it makes every piece of motion auditable against documented triggers and named criteria so its risk is legible even to reviewers who feel nothing watching it. You let the AI structure the analysis and route the criteria, you bring the product knowledge and the essential-versus-decorative judgment, and you ship a token recommendation that makes the whole system respect the preference of users whose experience of your motion neither you nor the model will ever directly share. That last part - protecting people through a standard precisely because you cannot feel what they feel - is the heart of accessibility, and motion is where it is tested hardest.

Key Takeaways

• Motion is the unaudited accessibility frontier because its harm is invisible to anyone without a vestibular disorder - the designer sees elegance, the susceptible user feels the floor tilt - and in 2026 cheap generated motion from Runway and Firefly Video floods products with motion optimized for impact, not safety.
• A motion audit checks two distinct things: whether interaction-triggered motion can be disabled and is not merely decorative (WCAG 2.3.3), and whether the product honors a user's OS-level "reduce motion" setting (prefers-reduced-motion). Generated motion routinely fails both, because a dropped-in clip has no reduced-motion variant at all.
• AI does the structured analysis well - classifying interaction-triggered versus auto-playing, decorative versus essential, flagging documented vestibular triggers (large-area movement, parallax, zoom, spin, rapid change), and checking for a reduced-motion variant. It cannot feel the motion, so the audit leans on documented triggers as the standard precisely because the people running it are not the people harmed.
• Audit against the named criteria and route them carefully: 2.3.3 governs interaction-triggered motion, 2.2.2 governs auto-playing motion over five seconds, and prefers-reduced-motion governs honoring the stated preference. A piece of motion can pass one and fail another.
• The findings memo names the element, the criterion, the issue, the trigger properties present, the severity (weighted by documented vestibular risk), and a specific remediation. The trigger-property column is essential because it justifies severity to reviewers who feel nothing watching the clip.
• The system-level fix is a prefers-reduced-motion token recommendation: motion duration, easing, and distance tokens that carry their own reduced-motion values, so every component built on them inherits correct behavior - and a rule that generated motion must ship a reduced-motion fallback before it enters the product. Same leverage as the contrast token audit.
• The judgment that stays human is essential versus decorative: motion is essential only if removing it breaks understanding or operation, not brand vibe. Over-claiming essentialness to protect a beloved animation keeps it playing for the user who asked it to stop, so holding this line strictly is what keeps the reduced-motion path real.