Accessibility Auditing with AI
Accessibility isn't a checkbox — it's a design skill. Over a billion people worldwide live with disabilities, and accessible design benefits everyone (think captions in noisy environments or high-contrast mode in sunlight). AI can help you identify accessibility issues earlier, generate compliant alternatives faster, and build accessibility thinking into your regular workflow.
What You'll Learn
- How to use AI to audit designs for WCAG compliance
- Prompts for checking color contrast, keyboard navigation, and screen reader compatibility
- How to generate accessible alternatives for common design patterns
- Methods for integrating accessibility into your design process with AI
Why UX Designers Should Lead Accessibility
Accessibility is often treated as a developer's job — "add ARIA labels and check the contrast ratio." But most accessibility problems originate in design decisions:
- A color palette that doesn't meet contrast ratios
- Interactive elements too small for motor-impaired users
- A flow that only works with a mouse, not a keyboard
- Content hierarchy that doesn't make sense when read linearly by a screen reader
Catching these issues in design is 10x cheaper than fixing them in code. AI helps you catch them before the design even reaches a developer.
WCAG Compliance Audit with AI
Prompt: Full Design Accessibility Audit
I'm auditing the accessibility of [screen/feature] in [product].
Here's a description of the design:
[describe layout, colors, interactive elements, content hierarchy,
and user flow]
Audit this design against WCAG 2.1 AA standards:
1. PERCEIVABLE
- Color contrast: Flag any text/background combinations that
likely fail the 4.5:1 ratio (normal text) or 3:1 ratio
(large text/UI components)
- Non-text content: Do all meaningful images, icons, and
charts have text alternatives?
- Content structure: Is the heading hierarchy logical
(h1 → h2 → h3, no skipped levels)?
- Sensory cues: Is information conveyed through color alone?
(e.g., red = error without an icon or text label)
2. OPERABLE
- Keyboard navigation: Can every interactive element be
reached and activated with keyboard alone?
- Focus order: Does tab order follow a logical reading sequence?
- Touch targets: Are all interactive elements at least 44x44px?
- Time limits: Are there any timed interactions without
the ability to extend?
3. UNDERSTANDABLE
- Labels: Are form inputs clearly labeled (not just
placeholder text)?
- Error identification: Are errors described in text (not
just color)?
- Consistent navigation: Is the navigation pattern consistent
with other screens?
4. ROBUST
- Semantic structure: Does the design map to appropriate HTML
elements? (e.g., will this be a button, a link, or a div?)
- ARIA needs: Which components will need ARIA attributes?
For each issue found, provide:
- The specific WCAG criterion violated (e.g., 1.4.3 Contrast)
- Severity: Critical / Major / Minor
- A specific fix recommendation
Color Accessibility Analysis
Color is the most common accessibility failure point. AI can help you evaluate and fix your color system.
Prompt: Color Palette Accessibility Check
Here is our product's color palette:
Primary: [hex code]
Secondary: [hex code]
Background: [hex code]
Surface: [hex code]
Text primary: [hex code]
Text secondary: [hex code]
Error: [hex code]
Success: [hex code]
Warning: [hex code]
Evaluate all likely color combinations for:
1. TEXT ON BACKGROUNDS: Which text/background combinations pass
WCAG AA (4.5:1) and AAA (7:1)?
2. UI COMPONENTS: Which color combinations for buttons, inputs,
and icons pass the 3:1 non-text contrast ratio?
3. ADJACENT COLORS: Are any adjacent UI elements too similar
for users with color vision deficiencies?
4. STATUS COLORS: Do our error/success/warning colors work for
all types of color blindness (protanopia, deuteranopia,
tritanopia)? Suggest alternatives if not.
Present results in a matrix showing pass/fail for each combination.
For any failing combination, suggest the nearest accessible
alternative that stays within our brand aesthetic.
Keyboard Navigation Review
Prompt: Keyboard Flow Analysis
I'm designing [feature] with these interactive elements:
[list all clickable, tappable, or interactive elements on the
screen in visual order]
Map the keyboard navigation flow:
1. TAB ORDER: What order should Tab key cycle through these
elements? Note any groupings (e.g., radio buttons should
be one tab stop with arrow keys inside).
2. KEYBOARD SHORTCUTS: Are there interactions that need
keyboard shortcuts beyond Tab/Enter/Space? (e.g., Escape
to close modal, arrow keys for dropdown navigation)
3. FOCUS MANAGEMENT: When a modal opens, where should focus go?
When it closes, where should focus return? When a toast
notification appears, should it steal focus?
4. SKIP LINKS: Are there repeated navigation blocks that need
a "skip to content" link?
5. TRAP PREVENTION: Are there any interactions where keyboard
users could get trapped (e.g., a custom dropdown that
captures focus and has no escape)?
For each concern, describe the expected behavior and provide the
ARIA or HTML pattern needed to implement it correctly.
Writing Accessible Alternative Text
Alt text is deceptively hard to write well. AI can help generate alternatives that are genuinely useful for screen reader users.
Prompt: Alt Text Generation
I need alt text for these images/icons in our product:
1. [describe image and its context on the page]
2. [describe image and its context on the page]
3. [describe image and its context on the page]
For each, provide:
- INFORMATIVE ALT: If the image conveys information (what would
the user miss without seeing it?)
- DECORATIVE ALT: If the image is purely decorative (alt="")
- FUNCTIONAL ALT: If the image is inside a link or button (what
does clicking it do?)
Also flag any images that should NOT have alt text (decorative)
and any that need a longer description via aria-describedby.
Rules:
- Don't start with "Image of..." or "Picture of..." — screen
readers already announce "image"
- Be specific and contextual, not generic ("Bar chart showing
revenue growing 23% in Q3" not "chart")
- Keep under 125 characters when possible
Building Accessibility into Your Design Process
Rather than auditing accessibility at the end, integrate it into your design workflow.
Prompt: Accessibility Design Checklist
I'm starting the design phase for [feature]. Create a customized
accessibility checklist I can reference throughout design:
Feature description: [describe the feature]
Key interactions: [list the main things users do]
Content types: [text, images, video, data tables, forms, etc.]
Generate a checklist organized by design phase:
1. WIREFRAMING PHASE:
- [ ] Structural checks (heading hierarchy, landmark regions)
- [ ] Navigation checks (tab order, keyboard alternatives)
- [ ] Content checks (reading order, skip links)
2. VISUAL DESIGN PHASE:
- [ ] Color checks (contrast, color independence)
- [ ] Typography checks (minimum sizes, line height)
- [ ] Spacing checks (touch targets, whitespace)
3. INTERACTION DESIGN PHASE:
- [ ] State checks (focus indicators, error states)
- [ ] Animation checks (reduced motion, pause ability)
- [ ] Timing checks (no time limits without extension)
4. HANDOFF PHASE:
- [ ] Annotation checks (ARIA roles, live regions, focus management)
- [ ] Documentation (accessibility requirements in specs)
Make each item specific to my feature, not generic.
Key Takeaways
- Most accessibility problems originate in design decisions — catching them before code saves 10x the effort
- Audit designs against all four WCAG principles: Perceivable, Operable, Understandable, and Robust
- Color contrast is the most common failure — evaluate your entire palette matrix, not just individual pairs
- Plan keyboard navigation during design, not after — map tab order, focus management, and trap prevention
- Integrate accessibility as a per-phase checklist rather than a final audit to prevent issues from accumulating

