An AI-generated screen passes through two transformations before a user touches it, and each one quietly breaks accessibility in its own way. First a tool like Galileo or Figma Make generates the design, and that design ships accessibility defects the generator could not see. Then a tool like v0, Anima, or Locofy converts the design to code, and the code drifts from the design in specific, repeatable ways - the focus ring vanishes, the target size shrinks, ARIA labels get invented that describe components that do not exist. This lesson runs the full gauntlet: a six-point accessibility review of the generated screen, a per-screen remediation cost so the work is quantified rather than hand-waved, and a design-to-code QA diff that catches the drift before handoff, while it is still cheap to fix. You walk away with an accessibility audit report and a design-to-code QA diff - the two artifacts that let a senior IC sign off on a generated-then-coded screen and mean it.

Two Transformations, Two Distinct Failure Points

The mistake teams make is treating "is this generated screen accessible?" as one question. It is two, because the screen goes through two transformations and fails differently at each. The first transformation is generation: a text or image prompt becomes a design in Galileo or Figma Make. The accessibility failures here are the ones from the L1 lesson scaled up - the generator produced something that looks right and has defects it could not perceive, like a faint focus state, a too-small icon button, or a decorative image with no alt-text plan. These are design-level failures, present in the Figma file before any code exists.

The second transformation is design-to-code: the design becomes a React component or a coded screen via v0, Anima, or Locofy. This transformation introduces a new class of failure, drift, where the code does not faithfully reproduce the design. Even if the design was accessible, the code can quietly not be, because the conversion tool made choices the design did not specify or dropped properties it did not understand. The same screen can be accessible in Figma and inaccessible in the browser, and a team that audited only the design ships the inaccessible code believing it checked.

So the audit has two parts that must both run. The six-point review catches the design-level failures in the generated screen. The design-to-code QA diff catches the drift introduced by the conversion. Run only the first and you certify a design whose code is broken; run only the second and you certify faithful code reproduction of a design that was inaccessible to begin with. Both transformations, both audits, or the sign-off is a fiction.

The Six-Point Accessibility Review

The first artifact is an accessibility audit of the generated screen across six points, chosen because they are the six most-broken-by-generators dimensions of screen accessibility. Each is checkable, each has a named standard, and together they cover the failures a generated screen reliably hides.

The Six Points, Each With Its Standard

1. Contrast. Every text-background and meaningful non-text pairing against 4.5:1 / 3:1 (1.4.3, 1.4.11). Generators produce light-gray secondary text that fails, constantly.
2. Focus. Every interactive element has a visible focus indicator meeting 2.4.11's 3:1 minimum. The single most-dropped property, because focus is invisible in a static mock.
3. Target size. Every interactive target at least 24 by 24 CSS pixels (2.5.8). Generated icon buttons are routinely too small.
4. Alt-text. Every meaningful image has an accessible-text plan, and every decorative image is correctly marked decorative. Generators produce images with no alt strategy and no decorative/meaningful distinction.
5. Motion. Any animation is auditable against 2.3.3 and has a prefers-reduced-motion path (the previous lesson's discipline applied per screen).
6. Keyboard order. The interactive elements are reachable and operable by keyboard in an order that matches the visual and logical flow. A structural property generators ignore entirely.

The six points are deliberately the full set a generated screen breaks - color, focus, size, images, motion, and structure - so that "passed the six-point review" means something specific and complete rather than "looked okay." AI helps run the first five (the perceivable, value-based checks) the way it helps with contrast and motion elsewhere; keyboard order, being structural, leans more on your manual check, which is exactly why it is the point most often missing from a casual audit.

Quantifying the Per-Screen Remediation Cost

A finding that says "this screen has accessibility problems" is not actionable to anyone making decisions about throughput. A finding that says "this screen needs 90 minutes of remediation: 20 for contrast token swaps, 15 for focus states, 10 for target sizes, 30 for alt-text and the decorative/meaningful pass, 15 for keyboard order" is a number a team can plan around. Quantifying the remediation cost per screen is what turns the audit from a quality gesture into an input for real decisions, and it is a distinctly L3 move because it treats accessibility as an engineering cost to be measured and managed, not a virtue to be invoked.

The number matters most when it is multiplied. If a generated screen costs 90 minutes to remediate and a team is generating forty screens a sprint, that is sixty hours of remediation the "AI made it instant" narrative conveniently omitted. Surfacing that number is how a senior IC corrects the false economics of generation - the generation was fast, but the total cost is generation plus remediation, and only the remediation-inclusive number is honest. The per-screen cost also tells you which generated screens are worth keeping (low remediation cost) versus which are faster to rebuild (remediation cost approaching from-scratch cost), which is a real decision the number makes for you. Measuring the cost is the difference between a team that thinks generation is free and a team that knows what it actually costs.

"This screen has a11y problems" is a vibe. "This screen costs 90 minutes to remediate, times 40 screens a sprint, equals 60 hours the generation narrative forgot" is a fact that changes decisions. Quantifying remediation is how you make accessibility legible to people who plan throughput.

The Design-to-Code Drift, Named Precisely

Now the second transformation and its distinct failures. When v0, Anima, or Locofy converts the design to code, the drift is not random - it clusters into named patterns, and knowing them is what makes the QA diff fast. Three patterns dominate.

The focus ring goes missing. Design-to-code tools frequently generate components without a proper focus style, or they apply a CSS reset that strips the browser's default focus outline and replace it with nothing. The design specified a focus state (or assumed the system's); the code ships an element you cannot see when you tab to it. This is the highest-frequency, highest-impact drift, because it is invisible until keyboard testing and it locks out keyboard users completely.

The target size shrinks. The design specified a 44-pixel touch target; the conversion produced a button whose actual clickable area is 20 pixels because the padding got dropped or the icon's hitbox is the icon, not the button. The design passed 2.5.8 and the code fails it, because the tool reproduced the visual size without the interactive size.

ARIA labels get invented. This is the most insidious, because it looks like accessibility work. The conversion tool, trying to be helpful, generates ARIA attributes - aria-label, role, aria-describedby - that were never in the design and do not match the component's actual behavior. An aria-label="Close dialog" on a button that submits a form. A role="navigation" on a div that is not navigation. Invented ARIA is worse than missing ARIA, because it actively lies to assistive technology, telling a screen-reader user the element is something it is not. The tool fabricated accessibility metadata, which is exactly the fabricated-compliance failure this program warns about, now emitted automatically by the conversion step.

The Design-to-Code QA Diff

The second artifact is a diff - a side-by-side comparison of what the design specified against what the code actually produced, focused on the accessibility properties that drift. This is not a general code review; it is a targeted check of exactly the places the conversion is known to break, which is what makes it fast enough to run on every handoff rather than a heroic one-off.

The diff is structured property by property. For each interactive element: design specified focus state X, code produced Y (or nothing) - flag if different. Design specified target size X, code produced clickable area Y - flag if smaller than 24px. Design specified accessible name X (or none), code produced ARIA Z - flag if invented or mismatched. A diff row reads: Element: primary CTA. Design: visible 2px focus ring, token focus-ring, 3.1:1. Code: outline: none with no replacement. Drift: focus indicator removed. Severity: Critical (locks out keyboard users). Fix: restore focus-ring token in the component's focus-visible style.

What makes the diff powerful is that it catches failures that exist only in the gap between design and code - failures no design audit and no isolated code review would catch, because each looks correct on its own side. The design audit confirms the design is accessible; the code, reviewed for function, works; but the accessibility property silently failed to cross the boundary, and only a diff that compares the two sides finds it. AI accelerates the diff by comparing the design's specified properties against the code's actual attributes and flagging mismatches, but you verify the invented-ARIA cases especially carefully, because judging whether an ARIA label is correct requires understanding what the component actually does, which is product knowledge the diff tool does not have.

Why Invented ARIA Is the One to Watch

Of the three drift patterns, invented ARIA deserves special vigilance, because it is the one that fails the test the other two pass: it looks done. A missing focus ring is a visible absence once you tab; a shrunk target is measurable; but invented ARIA is present, plausible, and wrong, and it passes a casual review precisely because the reviewer sees accessibility attributes and assumes accessibility was handled. The conversion tool emitted aria-labels and roles, the code looks accessibility-aware, everyone moves on, and a screen-reader user hits an interface that announces itself incorrectly at every turn.

The detection move is to never trust generated ARIA on sight. Every ARIA attribute the conversion produced is a claim about what the component is and does, and that claim must be verified against the component's actual behavior, not accepted because it exists. The correct posture treats auto-generated ARIA as suspect by default: a button labeled "Close dialog" gets checked - does it close a dialog? - and an invented role gets checked against what the element actually is. Often the right fix is to strip the invented ARIA entirely and let the semantic HTML carry the meaning, because a correctly-coded native button needs no aria-label at all and a fabricated one only adds a way to be wrong. The senior-IC instinct here is that accessibility metadata you did not author is a liability until proven correct, exactly the inverse of the comfortable assumption that any ARIA is better than none.

Running the Full Gauntlet Before Handoff

Here is the workflow end to end, on a real generated-then-coded screen. The sequence matters, because catching a failure earlier is always cheaper than catching it later.

Stage one, six-point review on the design. Run the generated Figma screen through contrast, focus, target size, alt-text, motion, and keyboard order, with AI assisting on the perceivable checks and you owning keyboard order. Produce the audit report with findings and per-point remediation cost.

Stage two, remediate the design or decide to rebuild. Using the quantified cost, either fix the design-level failures or, if the remediation cost approaches rebuild cost, rebuild the screen properly. Do this before conversion, so the code is generated from an accessible design rather than an inaccessible one.

Stage three, convert and run the QA diff. After v0, Anima, or Locofy produces the code, run the design-to-code QA diff on the three drift patterns - focus ring, target size, invented ARIA - plus a keyboard pass on the actual rendered output. Flag every property that did not survive the conversion.

Stage four, fix the drift and sign off. Restore the dropped focus states, fix the shrunk targets, strip or correct the invented ARIA, and verify by keyboard-testing the live component. Only now does the screen get handed off, with both artifacts attached: the accessibility audit (the design was accessible) and the QA diff (the code faithfully carried it). The sign-off means something because both transformations were checked.

Why the Diff Is the L3 Skill

The six-point review is a scaled-up L2 audit; the design-to-code QA diff is the genuinely new L3 capability, and it exists because the L3 designer operates across the design-to-code boundary that L2 stopped at. At L2 you audit the design and hand it off; at L3 you own the handoff itself, which means you own the drift, which means you are the person who catches that the accessible design became inaccessible code before it reaches a user or an engineer's pull request. This is the design-engineer-adjacent skill the 2026 market pays for: not just designing accessibly, but verifying that accessibility survived the trip into code, which is a place no one was watching when design ended at the Figma file.

And it is the skill that matters precisely because design-to-code tools are getting more capable and more trusted. As v0 and Anima and Locofy produce more convincing code, the temptation to trust the conversion grows, and the drift becomes more dangerous because it hides inside output that looks production-ready. The QA diff is the discipline that keeps trust calibrated: you let the tool do the conversion, which it does well and fast, and you verify the specific properties it is known to break, which it does badly and silently. That is the same delegate-and-verify pattern that runs through the entire program, applied to the one boundary where accessibility most reliably leaks out - and owning that boundary, with both artifacts in hand, is what lets a senior IC put their name on a generated, coded screen and defend it to anyone who asks whether the AI did it right.

Key Takeaways

• An AI-generated screen passes through two transformations - generation (Galileo, Figma Make) and design-to-code (v0, Anima, Locofy) - and fails differently at each. Audit only the design and you certify code that is broken; audit only the code and you certify faithful reproduction of an inaccessible design. Both transformations, both audits.
• The six-point review covers the full set of dimensions a generated screen reliably breaks: contrast (1.4.3/1.4.11), focus (2.4.11), target size (2.5.8), alt-text, motion (2.3.3 + reduced-motion), and keyboard order. AI helps with the first five perceivable checks; keyboard order is structural and leans on your manual pass, which is why it is the point most often missing.
• Quantify the per-screen remediation cost (e.g., 90 minutes broken down by point) because it turns the audit into a decision input: it corrects the false "generation is instant" economics when multiplied across a sprint, and it tells you which screens to keep versus rebuild.
• Design-to-code drift clusters into three named patterns: the focus ring goes missing (highest-impact, invisible until keyboard testing), the target size shrinks (visual size reproduced without interactive size), and ARIA labels get invented (the most insidious, because fabricated metadata actively lies to assistive technology).
• The QA diff compares the design's specified accessibility properties against the code's actual attributes, property by property, catching failures that exist only in the gap between the two - failures no design audit or isolated code review would find. It is targeted at the known drift points, which is what makes it fast enough to run every handoff.
• Invented ARIA is the drift to watch because it looks done: it passes casual review precisely because the reviewer sees accessibility attributes and assumes accessibility was handled. Treat all auto-generated ARIA as suspect until verified against the component's actual behavior, and often strip it so semantic HTML carries the meaning.
• The QA diff is the genuinely new L3 skill, because the L3 designer owns the design-to-code boundary L2 stopped at. As conversion tools get more convincing, the drift hides inside production-looking output, so the delegate-and-verify discipline - let the tool convert, verify the properties it is known to break - is what keeps a senior IC's sign-off honest.