Gate Every Handoff with an Artifact-Side A11y Review

Workflow area: Accessibility & Design QA · Tier: Core · Hands-on time: ~35 minutes

Most accessibility review happens too late — on the built product, where every finding is a ticket, a re-test and an argument about priority. The artifact-side gate moves the pass upstream to the Figma file, where you still own every pixel. The division of labor matters: contrast and target sizes are math, so deterministic tools decide them; focus order, alt text and semantic structure are judgment, so AI drafts and you verify against WCAG. An LLM eyeballing "does this look accessible?" is neither — never let it be the checker for anything a checker can compute.

When to use — and when not to

• Use it on every handoff, as a named gatethe value is the ritual: no file leaves design without the pass, so a11y debt stops accumulating silently.
• Use it when AI generated any of the UIprompt-born screens fail contrast and structure at a higher rate than hand-built ones; they get the gate with zero exemptions.
• Use it to build the annotation habitfocus order, heading levels and alt text written on the frame become the spec engineering builds from, instead of guesses they make later.
• Skip nothing because "the design system handles it"the system guarantees token contrast, not your token combinations, your text over images, or your focus order.
• Don't confuse this gate with product-level testingscreen-reader passes, keyboard walkthroughs and assistive-tech testing on the build still happen; this gate reduces what they find, it doesn't replace them.

The recipe

1. 1.

   Run the deterministic checks first — no AI involved. In Figma, run Stark or axe for Designs across the flow: text and UI-component contrast (WCAG 1.4.3 / 1.4.11), touch-target sizes (24×24 CSS px minimum under WCAG 2.2's 2.5.8; 44pt against Apple's HIG), and text-resize risk on fixed-height containers. These are computations. Record every failure with its frame and layer. This list is fact, not opinion.

2. 2.

   Annotate focus order and semantics — AI drafts, you decide. Screenshot each screen and ask a vision model for a draft:

   Copy

   Here is a screenshot of one screen from [FLOW]. Draft accessibility
   annotations for engineering handoff:
   
   1. FOCUS ORDER: propose a numbered keyboard focus sequence for all
      interactive elements. Flag anything whose visual position would
      make the DOM order ambiguous.
   2. HEADING STRUCTURE: propose heading levels (h1–h4) for the text
      that is structurally a heading; flag styled-as-heading text that
      is not one.
   3. LANDMARKS/ROLES: nav, main, dialog, alert — what applies here?
   4. STATES: which elements need visible focus, and which convey
      meaning by color alone (WCAG 1.4.1 risk)?
   
   Number your proposals so I can accept/reject each individually.
   Do not evaluate color contrast — that is already measured.
   

   Walk the proposed focus order with your own tab-key logic; the model often orders by visual layout when the interaction logic demands otherwise (e.g., a dialog's confirm before its dismiss). Correct it, then annotate the frame — numbered focus badges, heading levels, roles — using your annotation kit of choice.

3. 3.

   Draft alt text with context, verify by hand. For every meaningful image, feed the model the image plus its purpose in the flow — alt text describes function, not pixels:

   Copy

   Write alt text for this image. Context: it appears on [SCREEN],
   its purpose is [WHY IT'S THERE]. Rules: under 125 characters,
   function over appearance, no "image of", and return "decorative —
   empty alt" if it adds no information a user needs.
   

   Then verify each one yourself: does it say what a user who can't see the image needs on this screen? Mark genuinely decorative images as such — empty alt is a decision, not an omission.

4. 4.

   Compile the findings table, mapped to WCAG. Merge the deterministic failures and your accepted annotations into one table: finding, frame/layer, WCAG criterion, severity, fix. Have the model format and map the criteria numbers, then spot-check the mappings — models misattribute criteria numbers often enough that an unchecked mapping is a liability in any audit conversation.

5. 5.

   Fix in the file, then gate. Contrast and target failures get fixed now, in Figma — that is the entire point of artifact-side. The annotated file plus the findings table ships as the handoff; anything deferred is logged with an owner, not silently dropped. The gate passes when the table is empty or every open row has a name on it.

Make it yours

• Stark as the standing toolchain: its contrast, touch-target, focus-order annotation and vision-simulation tools cover steps 1–2 inside Figma; use AI only for the drafting layers (alt text, semantic proposals) Stark doesn't write.
• Claude Project as your WCAG desk reference: load the WCAG 2.2 quick reference and your org's a11y standard into a Project; ask "which criteria apply to an autocomplete input?" while annotating — verify against the spec text it cites, which is why you loaded it.
• Team severity rubric: pre-agree what blocks handoff (any AA contrast failure, missing focus order on interactive flows) versus what ships with a logged owner — the gate works when its pass/fail line isn't renegotiated per deadline.

Quality check

• Deterministic checks came from tools, not the modelif an LLM "measured" any contrast ratio, re-run it in Stark or axe; models estimate, plugins compute.
• Focus order reflects interaction logicyou tabbed through it mentally (or in a prototype) and corrected the model's visual-order bias.
• Alt text is functional and verifiedevery string read by a human against the screen's purpose; decorative images explicitly marked, not skipped.
• WCAG mappings were spot-checkedcriterion numbers verified against the spec, because a wrong citation undermines the whole table's credibility.
• The gate has teethfindings either got fixed in the file or carry a named owner; a review that only produces a document is a rehearsal, not a gate.