Last week, I watched a colleague generate a beautiful React component with Claude in under 30 seconds. The design was pixel-perfect, the interactions were smooth, and the code was clean. Then I ran it through an accessibility checker and found 12 critical violations.

This moment crystallized something I’d been noticing for months: AI tools are incredibly good at making things look right, but they consistently miss the mark on making things work for everyone. It’s not malicious—it’s just not what they’ve been optimized for.

After spending the last few months developing a more systematic approach to accessible AI-generated code, I want to share what I’ve learned about bridging this gap.

The Accessibility Blind Spots in AI Code Generation

AI models have gotten scary good at understanding visual design patterns and implementing complex functionality. But when it comes to accessibility, they’re operating with some fundamental blind spots.

The most common issues I see in AI-generated frontend code fall into a few categories:

Missing semantic structure. AI loves divs and spans, but rarely reaches for proper heading hierarchies, landmarks, or semantic HTML elements without explicit prompting.

Keyboard navigation gaps. Focus management, tab order, and keyboard event handling are often completely absent from generated components.

Screen reader unfriendly patterns. Missing alt text, empty aria-labels, and missing form associations are the norm rather than the exception.

Here’s a typical AI-generated button component I got recently:

const CustomButton = ({ children, onClick, variant = 'primary' }) => {
  return (
    <div 
      className={`btn btn-${variant}`}
      onClick={onClick}
    >
      {children}
    </div>
  );
};

It looks fine and probably works fine if you’re using a mouse. But it’s completely unusable for keyboard users and provides no semantic meaning to screen readers.

Prompting for Accessible Code from the Start

The most effective strategy I’ve found is being incredibly explicit about accessibility requirements in my initial prompts. AI models can generate accessible code—they just need clear guidance.

Instead of asking for “a modal component,” I now prompt like this:

Create a React modal component that follows WCAG 2.1 AA guidelines. Include proper focus management (trap focus inside modal, return focus on close), keyboard support (ESC to close), semantic HTML with role=“dialog”, aria-labelledby for the title, and aria-describedby for the content. The backdrop should not be clickable by keyboard users.

This approach has dramatically improved the quality of generated code. Here’s what I got with this more detailed prompt:

const Modal = ({ isOpen, onClose, title, children }) => {
  const modalRef = useRef(null);
  const previousFocusRef = useRef(null);

  useEffect(() => {
    if (isOpen) {
      previousFocusRef.current = document.activeElement;
      modalRef.current?.focus();
    } else {
      previousFocusRef.current?.focus();
    }
  }, [isOpen]);

  const handleKeyDown = (e) => {
    if (e.key === 'Escape') {
      onClose();
    }
  };

  if (!isOpen) return null;

  return (
    <div className="modal-backdrop" onClick={onClose}>
      <div
        ref={modalRef}
        role="dialog"
        aria-labelledby="modal-title"
        aria-describedby="modal-description"
        className="modal-content"
        onClick={(e) => e.stopPropagation()}
        onKeyDown={handleKeyDown}
        tabIndex={-1}
      >
        <h2 id="modal-title">{title}</h2>
        <div id="modal-description">
          {children}
        </div>
        <button onClick={onClose} aria-label="Close modal">
          ×
        </button>
      </div>
    </div>
  );
};

Much better! It’s not perfect (I’d still want to add proper focus trapping), but it’s a solid foundation.

My Systematic Accessibility Audit Process

Even with better prompting, I’ve learned that generated code needs systematic review. I’ve developed a checklist that I run through for every AI-generated component:

Semantic HTML Check

  • Are we using the right HTML elements? (buttons for actions, links for navigation, proper headings)
  • Is the heading hierarchy logical?
  • Are form elements properly associated with labels?

Keyboard Navigation Audit

  • Can you reach all interactive elements with Tab?
  • Is the tab order logical?
  • Do custom components handle Enter and Space appropriately?
  • Is focus visible and well-managed?

Screen Reader Compatibility

  • Does the component make sense when read aloud?
  • Are images and icons properly described?
  • Are dynamic content changes announced?
  • Do form errors get announced appropriately?

I actually built a small CLI tool that runs automated accessibility tests on components and flags the most common issues. It’s not a replacement for manual testing, but it catches the obvious stuff:

# My simple accessibility checker
npx a11y-audit ./src/components/Button.jsx

# Outputs:
# ❌ Interactive element missing keyboard support
# ❌ Missing aria-label or accessible name
# ✅ Color contrast meets WCAG AA standards

Building Accessibility into Your AI Workflow

The key insight I’ve had is that accessibility can’t be an afterthought in AI-assisted development—it has to be baked into the workflow from the beginning.

I now maintain a collection of accessibility-focused prompt templates for common UI patterns. When I need a form component, I have a template that includes validation, error announcement, and proper labeling requirements. For data tables, I have prompts that specify header associations and sorting announcements.

I’ve also started building up a library of accessible component examples that I can reference in prompts. Something like: “Create a dropdown menu similar to this accessible example [paste code], but adapted for a navigation menu.”

The results have been encouraging. My AI-generated components now pass basic accessibility audits about 80% of the time, compared to maybe 20% before I started being more intentional about it.

The Path Forward

We’re still in the early days of AI-assisted development, and I’m optimistic that accessibility will become more of a default consideration as these tools evolve. But for now, it’s on us as developers to bridge this gap.

The investment in learning to prompt for accessible code and building systematic review processes pays dividends beyond just compliance—it makes our applications genuinely better for everyone.

Start small: pick one accessibility requirement (maybe alt text for images) and make sure you include it in every relevant prompt this week. Build the habit of thinking about accessibility upfront, and gradually expand your checklist.

The future of AI-assisted development should be inclusive by default. Until we get there, we can make sure our own AI-generated code leads the way.