Contrast is the easy accessibility audit, because contrast is math and the tool can just compute it. The criteria in this lesson are harder, because they require judgment the tool cannot fully supply: is this focus indicator obscured by a sticky header, is this drag-only interaction operable without dragging, is this 24-pixel tap target actually 24 pixels once it renders, does this Runway-generated transition fire from a user interaction and ignore the user's reduced-motion preference. These are the WCAG 2.2 Level AA criteria most reliably broken by AI-generated UI and AI-generated motion, precisely because the model generates what an interface looks like and has no model of how a keyboard user, a screen-magnifier user, or a motion-sensitive user actually operates it. This lesson audits an AI-generated screen and a Runway transition against 2.4.11, 2.5.7, 2.5.8, and 2.3.3, reads the WCAG 3.0 Working Draft as a forward signal, and leaves you with an a11y findings memo plus a WCAG 3.0 horizon note.

The Criteria Generated UI Breaks Most

Generated interfaces fail accessibility in a predictable cluster, and it is not random. A model produces what a screen looks like at one canvas size, in its resting visual state, for a sighted pointer user, because that is the overwhelming majority of its training data. The criteria it breaks are exactly the ones that concern states and interactions outside that default: keyboard focus, drag operations, touch-target size, and motion triggered by use. Four WCAG 2.2 criteria capture most of the damage, and a working designer should be able to audit each by hand because the tools cannot fully.

The Four Criteria

1. 2.4.11 Focus Not Obscured (Minimum). When a component receives keyboard focus, it must not be entirely hidden by other content - a sticky header, a cookie banner, a floating action button. Generated layouts love sticky headers and overlays and have no concept of keyboard focus, so a focused element can scroll behind the sticky header and become invisible to the keyboard user who just tabbed to it. You audit this by tabbing through the rendered flow and watching whether the focused element ever disappears behind fixed content.
2. 2.5.7 Dragging Movements. Any functionality that uses a dragging movement must have a single-pointer alternative that does not require dragging - a reorderable list needs up/down buttons, a slider needs a tappable track or input, a drag-to-dismiss needs a close button. Generated UI proposes drag interactions because they look modern and never provides the alternative, stranding users who cannot drag (motor impairments, switch devices, some touch contexts).
3. 2.5.8 Target Size (Minimum). Interactive targets must be at least 24 by 24 CSS pixels, or have sufficient spacing around a smaller target. Generated UI routinely ships 16-pixel icon buttons, tightly packed link rows, and tap targets that look fine on a desktop mock and fail on a phone. You audit this by measuring the actual rendered target, not the visual glyph, because the hit area and the icon are not the same thing.
4. 2.3.3 Animation from Interactions. Motion triggered by a user interaction (a parallax scroll, a slide transition, an animated expand) must be disable-able via the prefers-reduced-motion preference, because vestibular-disorder users can be made physically ill by motion they did not ask for. AI-generated motion, including Runway transitions dropped into a prototype, has no concept of prefers-reduced-motion and will play full motion regardless of the user's system setting.

Notice the through-line: every one of these is about a use-state the model never represented. The screen looks accessible because it looks fine at rest to a sighted pointer user, and it behaves inaccessibly the moment a keyboard, a non-dragging input, a small touch target, or a motion preference enters the picture. That gap between looks-accessible and behaves-accessibly is the entire audit.

A generated interface is accessible-looking and frequently inaccessible-behaving, because the model rendered the resting visual state for a sighted pointer user and never modeled the keyboard user, the non-dragging user, or the motion-sensitive user. The audit is where you supply the use-states it ignored.

Auditing the Generated Screen

Take an AI-generated screen - say a Galileo or Figma Make dashboard with a sticky top nav, a reorderable widget list, a row of icon-only actions, and an animated panel expand - and run it against the four criteria. The method is to operate the interface the way the affected users do, because the failures only appear in operation, not in the static mock.

Focus (2.4.11): Tab through every interactive element in order and watch the focused element. When you tab to a control near the top, does it scroll up behind the sticky header and vanish, leaving you with focus on something you cannot see? Generated sticky headers cause this constantly because the model never reasoned about scroll-into-view behavior under keyboard focus.

Dragging (2.5.7): Find the reorderable widget list and ask: can I reorder these without dragging? If the only way to move a widget is to drag it, the criterion fails, and the fix is to add explicit move-up and move-down controls. The generated UI offered drag because drag looks polished; it never considered the user who cannot perform a drag.

Target size (2.5.8): Inspect the row of icon-only actions and measure the actual hit area. A 16-pixel icon with no padding is a 16-pixel target and fails the 24-pixel minimum; the visual glyph being small does not excuse it. Measure the rendered target, increase the hit area to at least 24 by 24, or add sufficient spacing.

Motion (2.3.3): Trigger the animated panel expand with prefers-reduced-motion enabled in the system or browser. If the full animation plays anyway, it fails; the expand must be instant or minimal under that preference. Generated motion ignores the preference because the model has no concept of it.

Each of these is found by doing, not by looking, which is why a static contrast-style tool cannot fully cover them and why the human audit is irreducible here.

Overlays: The Concentrated Focus Hazard

One sub-case deserves its own attention because generated UI gets it wrong so reliably: overlays. Modals and drawers are where focus management concentrates, and generated overlays frequently fail to trap focus inside the overlay, fail to return focus to the triggering element when they close, or let a focused element hide behind the backdrop. Audit every overlay by opening it with the keyboard and confirming that focus moves into it and stays trapped within it, that Escape and the close control both work, that focus returns to the trigger on close, and that nothing focused vanishes behind the backdrop or a sticky header. Because generated overlays inherit the model's complete absence of a keyboard model, treat each one as a required focus-management sub-audit, and fix it with a shared overlay component that handles focus trap, return-focus, and visible focus so the fix is structural rather than re-done per modal.

Auditing the Runway-Generated Transition

Now the motion case specifically, because AI-generated video and motion is increasingly dropped into prototypes and products as transitions, and it carries a particular accessibility liability. A Runway-generated transition - a sweeping, dynamic, camera-move-style animation between two states - looks impressive and is, from an accessibility standpoint, often a 2.3.3 problem waiting to happen. The model generated motion that looks good; it has no concept that this motion plays on interaction, that some users have vestibular disorders, or that prefers-reduced-motion exists.

Audit it by asking three questions. First, does this motion trigger from a user interaction (a click, a scroll, a navigation)? If yes, 2.3.3 applies. Second, does it respect prefers-reduced-motion - is there a reduced or no-motion alternative that plays when the user has expressed that preference? Generated motion almost never has one, so this is usually a fail. Third, even setting aside the preference, is the motion itself within safe bounds - no large-scale movement that could trigger vestibular reactions, nothing that flashes more than three times per second (which is the separate seizure-risk concern under 2.3.1)? The fix is to gate the impressive transition behind prefers-reduced-motion, providing a calm fade or an instant cut for users who have asked for reduced motion, and to keep even the full version within safe motion bounds. The transition can stay; it just cannot be the only option and cannot ignore the preference.

The WCAG 3.0 Horizon: A Forward Signal, Not a Standard

It is worth lifting your eyes to where the standard is going, with a crucial caveat stated plainly: as of 2026, WCAG 3.0 is a W3C Working Draft, not a W3C Recommendation. You audit against WCAG 2.2 today because 2.2 is the recommendation and 3.0 is not done. Treating the Working Draft as if it were binding would be a mistake; treating it as a forward signal is smart, because it tells you where the discipline is heading and which of today's judgment calls are likely to harden into requirements.

Read the WCAG 3.0 Working Draft for direction, not for rules. The headline shift is from the pass/fail conformance model of 2.x toward a more graduated, outcomes-and-scoring approach intended to capture accessibility quality more richly than a binary, and a broader scope that looks beyond what 2.x could express. What this signals for a working designer: the criteria you audit by judgment today - is the focus genuinely usable, is the motion genuinely safe, is the target genuinely operable - are the kind of holistic, user-outcome questions 3.0 is trying to formalize. The skill of operating an interface as the affected user and judging whether it actually works, which this lesson is built on, is exactly the skill 3.0 is moving toward. So the horizon note is not "comply with 3.0 now" - you cannot, it is a draft - but "the judgment-based auditing you are learning is where the standard is going, so investing in it is future-proof."

The discipline for the horizon note is restraint. State clearly that 3.0 is a Working Draft, not a Recommendation, in 2026; do not let a stakeholder mistake your forward-looking summary for a current obligation; and frame the value as preparation, not compliance. A designer who can hold both the current standard (2.2, binding) and the direction (3.0, signal) without confusing them is exactly the kind of accessibility-literate practitioner the discipline needs.

The Artifact: The A11y Findings Memo Plus a Horizon Note

The named artifact is an a11y findings memo covering the four criteria - focus, target size, dragging, and motion - plus a one-paragraph WCAG 3.0 horizon note. The memo, like the contrast report, is built to be acted on: each finding names the criterion (2.4.11, 2.5.7, 2.5.8, 2.3.3), the specific element and frame, the failure as observed in operation ("tabbing to the Save button scrolls it behind the sticky header; focus is invisible"), and the fix ("ensure scroll-into-view offsets for the sticky header height, or make the header non-sticky on keyboard focus"). Because these failures are operational, the memo's findings read as behaviors, not measurements, which is what distinguishes this audit from the contrast one.

The horizon note is the second half: a single, disciplined paragraph stating that WCAG 3.0 is a Working Draft (not a Recommendation) as of 2026, summarizing the direction (graduated scoring, broader scope, outcome focus), and connecting it to the present work (the judgment-based criteria audited here are where the standard is heading). The note demonstrates that you are tracking the field without overclaiming, which is exactly the posture a design lead wants from whoever owns accessibility. Together, the memo and the horizon note are a findings document that fixes today's failures and shows you know where tomorrow's requirements are forming.

Why This Audit Cannot Be Fully Automated

The contrast lesson could honestly promise a three-minute, tool-driven audit. This one cannot, and the reason is instructive. Contrast is a property of two colors, fully observable and computable. Focus-not-obscured, dragging-alternatives, true target size, and motion-safety are properties of interaction, observable only by operating the interface as the affected user, and judgment-laden in ways a static check cannot resolve. A tool can flag a likely target-size failure or detect the absence of a prefers-reduced-motion media query, and those automated flags are genuinely useful as a first pass, but the tool cannot tab through your flow and tell you the focused element vanished behind the header in a way that actually strands the user, nor judge whether a drag alternative is adequate, nor feel whether a motion is vestibular-safe.

This is the generation-versus-understanding gap at its sharpest. The model generated the interface and cannot operate it as a disabled user; a static tool can measure but cannot operate; only the designer can operate the interface the way the affected user does and judge whether it actually works. That irreducible human step is not a limitation of current tools that will be patched away soon; it is the nature of auditing interaction rather than appearance. The designer who can do it - tab through, try to reorder without dragging, measure the real target, toggle reduced motion - is supplying exactly the understanding the model and the static tool both lack, and that is the durable, judgment-heavy core of accessibility work that does not commoditize.

Putting It to Work This Week

Take a real AI-generated screen and a real generated transition, and operate them as the affected users. Tab through and watch focus against the sticky content (2.4.11). Try to perform every drag interaction without dragging (2.5.7). Measure the actual rendered hit area of every icon button (2.5.8). Toggle prefers-reduced-motion and re-trigger every animation, including the generated transition (2.3.3). Write the findings as observed behaviors with criterion, element, and fix. Then write the one-paragraph horizon note: WCAG 3.0 is a Working Draft, not a Recommendation, in 2026; here is the direction; here is why the judgment-based auditing you just did is where it is heading. You leave with a memo that fixes today's failures and a note that proves you can see tomorrow's, without confusing the two.

Key Takeaways

• AI-generated UI breaks a predictable cluster of WCAG 2.2 criteria because the model renders the resting visual state for a sighted pointer user and never models keyboard, non-dragging, small-target, or motion-sensitive use: 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size Minimum (24x24 CSS pixels), and 2.3.3 Animation from Interactions.
• These criteria are found by operating the interface as the affected user, not by looking at the static mock: tab through and watch focus against sticky content, try every drag without dragging, measure the real rendered hit area, and toggle prefers-reduced-motion and re-trigger every animation.
• A Runway-generated transition is often a 2.3.3 problem: it triggers on interaction, has no reduced-motion alternative, and may exceed safe motion bounds. The fix is to gate it behind prefers-reduced-motion with a calm fallback and keep even the full version safe - the transition can stay, it just cannot ignore the preference.
• WCAG 3.0 is a W3C Working Draft, not a Recommendation, as of 2026; you audit against 2.2 (binding) and read 3.0 as a forward signal. Its direction - graduated scoring, broader scope, outcome focus - formalizes exactly the judgment-based questions this audit asks, so the skill is future-proof.
• The artifact is an a11y findings memo (focus, target size, dragging, motion - each with criterion, element, observed behavior, and fix) plus a one-paragraph WCAG 3.0 horizon note that states the draft status plainly and frames 3.0 as preparation, not current compliance.
• This audit cannot be fully automated because focus-obscuring, drag-alternatives, true target size, and motion-safety are properties of interaction observable only by operating the interface as the affected user; the irreducible human step is the durable, judgment-heavy core of accessibility work.