How to prompt AI for accessibility (a11y)

A lot of teams do not skip accessibility because they do not care. They skip it because it is easy to defer when roadmap pressure gets real.

The goal of this guide is simple: use AI prompts early enough to catch obvious keyboard, screen reader, and form issues before launch-week fire drills.

This is not a replacement for specialists, legal review, or hands-on QA with assistive tech. It is a practical way to improve first-pass quality sooner.

What good looks like before you prompt

Perceivable: content is visible and understandable with alternatives when needed.
Operable: flows work with keyboard, focus, and no pointer assumptions.
Understandable: labels, instructions, and errors are clear and specific.
Robust: semantics support real assistive technology behavior.

In practice, do not ask AI "is this accessible?" Ask it to behave like a careful reviewer trying to break your flow with keyboard and screen reader constraints.

Prompt pattern 1: Keyboard-first pass

Most expensive issues show up in tab order, focus visibility, and overlays that trap users.

Act as an accessibility reviewer. Walk through this UI using only keyboard input (Tab, Shift+Tab, Enter, Space, Escape). 1) List likely tab order from first meaningful element to last. 2) Flag anything unreachable, skipped, or unexpectedly focusable. 3) Identify focus risks in modals, menus, dropdowns, and custom controls. 4) Suggest fixes in plain language first.

Why it works: it forces discussion from visuals into reachability and control.

Prompt pattern 2: Screen reader narration pass

Pretend you are a screen reader user navigating this screen in a sensible order. Describe what would likely be announced for each interactive element (name, role, state). Flag weak announcements: unnamed buttons, duplicate labels, unclear order, missing/low-value alt text, and unlabelled fields. Keep recommendations practical for a product team shipping this sprint.

Why it works: it turns accessibility from an abstract checklist into an announced experience.

Prompt pattern 3: Color and contrast sanity check

AI is good at spotting risky patterns, not certifying exact contrast ratios. Use it for early risk detection, then verify with engineering tools.

Review this design for color-related accessibility risks. 1) Identify where meaning is conveyed by color alone. 2) Flag risky text/background pairs for body text. 3) Suggest safer alternatives that preserve brand feel. 4) List what still requires exact measurement in dev tools.

Prompt pattern 4: Form clarity and error quality

Review these form fields for accessibility and clarity. Check: - labels and helper text quality - specific, non-blaming error messages - non-color-only success/error signaling - grouping/fieldset needs - instructions that appear before failure Rewrite weak error messages into clearer alternatives.

Why it works: forms are where accessibility and UX writing directly impact user success.

Prompt pattern 5: Component accessibility contract

I am defining a design system component: [component]. Produce a concise accessibility contract including: - keyboard behavior across states - required screen reader names/roles/states - focus management rules (especially overlays) - what designers must document - what code review and QA must validate Use ARIA only when native HTML cannot cover the need.

This helps teams move accessibility into the definition of done instead of launch-week cleanup.

What AI is bad at (say it out loud)

Legal compliance guarantees.
Pixel-perfect contrast certification from screenshots.
Replacing user testing with assistive technology.

Use AI to reduce preventable mistakes early. Use real tools and real testing to validate.

Related resources on AI UX Playground

Prompt library for reusable accessibility and UX workflows
How to prompt AI for design system components
How to prompt AI for user research
10 prompting rules for better outputs

Pick one screen this week and run one accessibility prompt before polish. Small habit, large compounding impact.