How Do You Build Accessible Applications When AI Is Designing the Interface?

You hand AI your design system and a Figma frame. It generates a beautiful React component with semantic HTML, ARIA labels, proper heading hierarchy, and color contrast that passes WCAG AA. Your accessibility linter is happy. A real blind user with a screen reader opens your app and has no idea how to use it.

This is the accessibility paradox of AI-designed interfaces: they can be technically correct while functionally broken for the people they’re supposed to help.

The problem isn’t that AI doesn’t understand accessibility. It’s that accessibility isn’t a checklist. It’s a practice shaped by conversations with people who actually need it. And AI, by definition, can’t have those conversations.

What AI Gets Right (And What It Misses)

AI is excellent at mechanical accessibility:

• Proper semantic HTML (<button> vs. <div>; <nav> vs. generic containers)
• ARIA attributes in the right places (aria-label, aria-describedby, aria-live)
• Color contrast that meets WCAG AA standards
• Focus management and tab order
• Form labels and error messages

AI fails at contextual accessibility:

• Understanding what a component means to different users
• Designing experiences that work for people with cognitive disabilities
• Creating meaningful alt text for images (it generates technically correct text that’s useless)
• Building interfaces for people with motor impairments who need alternative input methods
• Making voice control and voice-to-text work reliably
• Considering cultural and linguistic accessibility

Here’s a concrete example:

AI generates a modal for confirming a destructive action:

export function DeleteConfirmation({ onConfirm, onCancel, itemName }) {
  return (
    <div role="alertdialog" aria-labelledby="dialog-title">
      <h2 id="dialog-title">Confirm Deletion</h2>
      <p>Are you sure you want to delete {itemName}?</p>
      <button onClick={onCancel}>Cancel</button>
      <button onClick={onConfirm} className="destructive">Delete</button>
    </div>
  );
}

Technically, this is accessible:

• role="alertdialog" tells screen readers what this is
• aria-labelledby connects the dialog to its title
• Buttons are semantic <button> elements
• Focus is managed properly
• Color contrast is probably fine

Functionally, a screen reader user might experience:

• No indication that the destructive button is genuinely destructive
• No extra confirmation step (some users need friction to prevent accidents)
• Button order might be wrong for how they navigate
• No explanation of what the user is about to lose

A better accessible design would be:

export function DeleteConfirmation({ onConfirm, onCancel, itemName }) {
  return (
    <div role="alertdialog" aria-labelledby="dialog-title">
      <h2 id="dialog-title">Delete {itemName}?</h2>
      <p>
        This action cannot be undone. All data associated with {itemName} will be permanently deleted.
      </p>
      <button onClick={onCancel} autoFocus>
        Keep {itemName}
      </button>
      <button
        onClick={onConfirm}
        className="destructive"
        aria-label={`Permanently delete ${itemName}`}
      >
        Delete {itemName}
      </button>
    </div>
  );
}

Differences:

• Specific phrasing (“Keep X” vs. “Cancel”)
• Explicit consequences (“cannot be undone”)
• Cancel button gets focus by default (safe action first)
• Aria-label on delete button makes intent clear to screen readers
• Button text refers to the item being deleted (context)

The second version is only 5% more code but 10x more accessible. AI doesn’t know to make these changes because they’re not mechanical. They’re judgment-based decisions about user safety and clarity.

Three Accessibility Fails in AI-Generated UIs

Fail 1: Meaningless Alternative Text

AI sees an image and generates alt text:

<img
  src="/product-detail.png"
  alt="Product detail view showing shoes with color options"
/>

This passes the “has alt text” test but fails screen reader users. A better alt text depends on context:

• On a product page: “Black leather dress shoes with brown color option”
• In a search result: “Shoes in black and brown”
• In an analytics dashboard: “Product page views increased 23% this month”

Same image, different alt text for different contexts. Only a human who understands the context and the user can write this correctly.

Fail 2: ARIA Overload

AI tends to be conservative, adding ARIA attributes everywhere:

<div role="button" aria-label="Menu" tabIndex={0} onClick={handleClick}>
  ☰
</div>

This is technically accessible but:

• It’s a div styled as a button instead of a button
• It requires JavaScript for keyboard interaction
• It’s harder to maintain than a real button

Better:

<button aria-label="Menu">☰</button>

One line. No role, no tabIndex, no JavaScript needed for basic functionality. It works for keyboard and screen reader users because it’s actually a button.

AI generates the first version because it’s trying to handle all edge cases. A human knows the simpler solution is the more accessible one.

Fail 3: Information Only in Design

A common pattern AI generates:

<div>
  <span className={required ? "text-red-600" : ""}>
    Email
  </span>
  <input type="email" />
</div>

For a sighted user, the red text indicates a required field. For a screen reader user, the field just has a label. They don’t know it’s required.

Better:

<div>
  <label htmlFor="email">
    Email <span aria-label="required">*</span>
  </label>
  <input id="email" type="email" required aria-required="true" />
</div>

Now the requirement is available to everyone: visually (red asterisk), structurally (required attribute), and to screen readers (aria-required).

How to Retrofit AI-Generated UIs for Real Accessibility

You can’t expect AI to generate accessible interfaces by accident. You need a process:

Step 1: Set Accessibility Constraints Upfront

Tell the AI what accessibility standards you’re targeting:

Generate a product filter component with:
- WCAG 2.1 Level AA compliance
- Full keyboard navigation support
- Screen reader tested with NVDA
- No JavaScript required for basic functionality
- Color contrast minimum 7:1
- Mobile touch target minimum 48x48px

Better constraints = better generation. But even with constraints, you’ll find issues.

Step 2: Structured Review Process

Create a checklist that goes beyond automated testing:

Automated checks (run on every build):

• WCAG contrast checking (axe, Lighthouse)
• HTML validity (no duplicate IDs, proper nesting)
• ARIA usage (no invalid role/attribute combinations)

Manual checks (before release):

• Keyboard navigation: Can you use Tab, Shift+Tab, Enter, Space, Escape to control everything?
• Screen reader testing: Does a real screen reader (NVDA, JAWS, VoiceOver) make sense of the interface?
• Cognitive accessibility: Is the interface confusing? Too many steps? Unclear labels?
• Motor accessibility: Are buttons large enough? Are target areas spacious?
• Color accessibility: Does the interface work in grayscale? For colorblind users?

Real user testing (before major releases):

• Test with actual users who have disabilities
• Not “people pretending to use a screen reader” but people who actually rely on assistive technology
• Ask them: Can you accomplish this task? Was it confusing? What would make it easier?

Step 3: Document Accessibility Decisions

When you fix an AI-generated interface for accessibility, document why:

// Changed from generic div with role="button" to semantic <button> element
// because screen reader users need semantic buttons for proper announcements
// and keyboard users need enter/space support by default.
// See: WCAG 2.1 4.1.2 Name, Role, Value
<button onClick={handleDelete} aria-label="Delete item">
  Delete
</button>

This documents the decision for your team and future you. It also prevents someone from “simplifying” it back to a div later.

Step 4: Continuous Improvement

Accessibility isn’t a box you check once. After launch:

• Monitor which assistive technology users have trouble with (through support channels, analytics if possible)
• Test new features with people who have disabilities before shipping
• Update your accessibility constraints based on what you learn
• Share learnings with your AI generation prompts (this shapes better future generations)

Building for Motor and Cognitive Accessibility

These are areas where AI most commonly falls short because they’re least about code:

Motor Accessibility AI generates buttons that are 32px × 32px. WCAG recommends 48px × 48px for touch targets. AI doesn’t know about this because it’s a design decision, not code.

Better: Include motor accessibility in your design system tokens:

/* Your design tokens */
--button-height: 44px;  /* Mobile touch target */
--button-min-width: 44px;
--form-input-height: 44px;

Now when AI generates components using your tokens, they’re accessible by default.

Cognitive Accessibility A form that’s technically correct but confusing:

<form>
  <fieldset>
    <legend>Account settings</legend>
    <input type="checkbox" aria-label="Newsletter opt-in preference" />
    <input type="checkbox" aria-label="Analytics sharing consent" />
    <input type="checkbox" aria-label="Third-party integration data sync" />
  </fieldset>
</form>

Clear labels, proper structure, keyboard accessible. But the checkboxes are cryptic and no one understands them.

Better: Make the language as clear as possible:

<form>
  <fieldset>
    <legend>Email and Sharing Preferences</legend>

    <div className="preference-group">
      <label>
        <input type="checkbox" name="newsletter" />
        Send me the weekly newsletter (one email per week)
      </label>
    </div>

    <div className="preference-group">
      <label>
        <input type="checkbox" name="analytics" />
        Help us improve by sharing how you use the app
      </label>
    </div>
  </fieldset>
</form>

The code is nearly identical. The difference is in the clarity of the labels, the grouping structure, and the explanations.

Red Flags in AI-Generated UIs

When reviewing AI-generated components, watch for:

1. Generic ARIA labels (“Button”, “Menu”, “Navigation”). These don’t tell screen reader users what the element does.
2. Color as sole indicator. If information is only conveyed through color, it’s not accessible.
3. Images without alt text or with placeholder alt. “Image 1”, “Graphic”, “Icon” are useless.
4. Keyboard traps. Focus enters a modal/menu but can’t escape without a mouse.
5. No visible focus indicators. You can’t see where the keyboard focus is.
6. Unlabeled form inputs. Inputs without labels or labels that aren’t connected via htmlFor.
7. Text too small. Looks fine in design, but less than 14px is hard to read.
8. Insufficient spacing between clickables. Touch targets that are too close together.

These aren’t subtle bugs. They’re fundamental usability breaks for significant populations of users.

The Economics of Accessible AI-Generated UIs

Here’s the honest version: Making AI-generated UIs accessible requires human review and iteration. It’s not free. But it’s cheaper than either:

1. Building it wrong and fixing it later (retrofitting is harder)
2. Excluding 15% of your potential users (that’s the percentage of people with disabilities)

The math: 5% additional engineering time for accessibility review = access for 15% more users. That’s a good trade in almost any business model.

The teams that get this right:

1. Set accessibility constraints upfront (shapes AI generation)
2. Have one person with deep accessibility knowledge review AI output
3. Test with real assistive technology before shipping
4. Document accessibility decisions as they’re made
5. Iterate based on real user feedback

You can’t delegate accessibility to AI. But you can use AI to generate scaffolding that accessibility experts review and harden.

That’s the sustainable model.