Bake Accessibility into Every Generation Prompt

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

Generative UI tools have a default aesthetic, and it is quietly inaccessible: light-gray placeholder text, icon buttons with no labels, meaning carried by color, headings chosen for size rather than structure. Prompt "a clean settings screen" and you inherit all of it. The fix is upstream: accessibility requirements belong in the prompt, stated as constraints the generator must satisfy, and packaged as templates so nobody on the team pastes them from memory. Prevention is cheaper than review — and it compounds, because every generated draft across every designer starts from the same floor.

When to use — and when not to

• Use it the week your team adopts any generation toolFigma Make, First Draft, v0, Lovable: the constraint block should exist before the hundredth prompt, not after the hundredth retrofit.
• Use it when pb-31 keeps catching the same failuresrecurring gate findings on generated screens are a prompt defect; fix the template, not just the frames.
• Use it for prompt templates shared across a teamindividual prompt hygiene decays; a shared template with a11y baked in survives personnel and deadlines.
• Skip treating it as the whole a11y storyprompts raise the starting floor; the pb-31 artifact gate and product-level assistive-tech testing still run. Prevention narrows the gate's findings, it never replaces the gate.
• Skip constraints your tool can't honorif the generator ignores focus-order instructions, don't carry dead weight in the prompt; move that check to review and say so in the template.

The recipe

1. 1.

   Turn your gate findings into a constraint inventory. Pull the last few pb-31 findings tables (or run one AI-generated screen through the gate now) and list what generated UI actually gets wrong in your stack: contrast on secondary text, unlabeled icon buttons, color-only status, fake headings, missing focus states, motion with no reduced variant. This local evidence beats any generic checklist — you are encoding your failure modes.

2. 2.

   Write the a11y constraint block. One reusable block, versioned, owned by someone:

   Copy

   ACCESSIBILITY CONSTRAINTS (non-negotiable in all generated output)
   1. Contrast: body text ≥ 4.5:1 against its background; large text
      and UI component boundaries ≥ 3:1. Use only these token pairs:
      [YOUR CONTRAST-SAFE TOKEN PAIRS].
   2. Touch targets: interactive elements ≥ 44×44 px, ≥ 8 px apart.
   3. Labels: every input has a visible label (no placeholder-as-label);
      every icon-only button has a text label or explicit aria-label.
   4. Structure: one h1 per screen; headings nest without skipping;
      text styled as a heading IS a heading.
   5. Color: never the only carrier of meaning — pair status color
      with icon or text.
   6. Focus: all interactive elements get a visible focus state.
   7. Motion: any animation over 200 ms gets a reduced-motion variant;
      nothing flashes more than 3 times per second.
   8. If any instruction above conflicts with the design request,
      flag the conflict in output — do not silently drop a constraint.
   

3. 3.

   Fuse it into the team's prompt templates. Constraints live with the request, not in a separate document nobody pastes:

   Copy

   Generate a [SCREEN TYPE] for [PRODUCT] using our design system
   components: [LIBRARY/CONTEXT].
   
   DESIGN INTENT: [what the screen does, tone, layout notes]
   
   [PASTE ACCESSIBILITY CONSTRAINT BLOCK v1.3]
   
   After generating, append a COMPLIANCE NOTE: list each constraint
   number with met / not-met / not-applicable and one line of evidence.
   

   The compliance note matters: it forces the generator to attest per constraint, and gives your review a diff-able starting point. Sample output tail:

   Copy

   COMPLIANCE NOTE
   1. Contrast — met: text/surface pairs from approved token list.
   3. Labels — met: search icon button labeled "Search".
   7. Motion — N/A: no animation on this screen.
   

4. 4.

   Verify the attestation — the note is a claim, not a fact. Run the generated frame through the deterministic tools from pb-31 (Stark contrast and target checks take two minutes). Generators over-report compliance; the point of the note is that it tells you exactly where to look, not that you believe it.

5. 5.

   Close the loop monthly. Every gate finding on a generated screen gets triaged: was the constraint missing, ignored, or impossible for this tool? Missing → add it to the block and bump the version. Ignored → strengthen the wording or move that check to review. Impossible → document it as a known review item. The block is a living artifact; its changelog is your evidence that prevention is working.

Make it yours

• Figma Make with the block pinned: keep the constraint block as the standing preamble in your Make prompts; because Make consumes your design system context, list the contrast-safe token pairs by name so generation binds to real tokens, not hex approximations.
• Claude Project as the template library: store the constraint block, the prompt templates and the changelog in one shared Project — designers copy from one canonical place, and the Project answers "why is rule 4 worded like that?" with the gate finding that caused it.
• Stark as the two-minute verifier: standardize the post-generation check to exactly two Stark passes (contrast, targets) so verification is cheap enough that nobody skips it.

Quality check

• The block encodes your failures, not a generic listevery rule traces to a real finding from your stack; rules without local evidence are candidates for cutting.
• Templates carry the block by defaultif compliance depends on individuals remembering to paste, you built a suggestion, not a system.
• Compliance notes get verified, not fileddeterministic tools confirmed the generator's attestation on every screen that ships onward.
• The block is versioned with an owneran unowned prompt fragment forks per designer within a month.
• Gate findings on generated screens are trending downthat trend is the metric; if it's flat, the loop in step 5 isn't actually running.