The Accessibility Gap: How AI Assistants Build Inaccessible Apps (and How to Fix It)

The Accessibility Gap

You built an app with Cursor, deployed it, and received an email from a user who uses a screen reader: "I cannot navigate your app. The buttons do not have labels, the form fields do not have descriptions, and I cannot tab through the page." What happened? Your app works for sighted mouse users, but it is inaccessible to screen reader users and keyboard users. This is the accessibility gap, and it is one of the most common failures in AI-generated apps. AI assistants build apps for the "average" user (sighted, mouse-using, on a desktop), which means they miss the accessibility requirements that make apps usable by everyone. Here are the 7 reasons AI-generated apps are inaccessible, and the production checklist to fix them.

The direct answer is that accessibility (a11y) is the practice of making apps usable by everyone, including users with disabilities (visual, motor, cognitive, auditory). AI assistants generate code that works for sighted mouse users but misses the accessibility requirements: missing alt text, missing ARIA labels, missing keyboard navigation, poor color contrast, missing focus management, missing form labels, and missing semantic HTML. The result is apps that are inaccessible to screen reader users, keyboard users, and users with other disabilities, which excludes a significant fraction of potential users and exposes the app to legal liability (under the ADA, WCAG, and other accessibility laws). For more on production compliance, see our article on the cookie consent trap.

Reason 1: Missing Alt Text

The most common reason AI-generated apps are inaccessible is missing alt text on images. AI assistants often add tags without the alt attribute, which means screen reader users cannot understand what the image shows. The fix is to add descriptive alt text to every image. For decorative images (e.g., a background pattern), use alt="" (empty alt text) to tell the screen reader to skip it. For informative images (e.g., a chart, a logo), write a concise description. For more on image handling, see our article on the file upload trap.

Reason 2: Missing ARIA Labels

The second reason is missing ARIA labels on interactive elements. AI assistants often use

and with onClick handlers instead of semantic HTML (



// Good (icon button with ARIA label)


// Bad (div with onClick)
Save

Fix 3: Ensure keyboard navigation

// Good (button is keyboard-accessible by default)


// For custom interactive elements, add keyboard handlers
 {
    if (e.key === 'Enter' || e.key === ' ') {
      e.preventDefault();
      handleClick();
    }
  }}
>
  Custom button

Fix 4: Verify color contrast

Use the WebAIM Contrast Checker to verify all text/background combinations meet WCAG AA (4.5:1 for normal text, 3:1 for large text).

Fix 5: Implement focus management

import { useEffect, useRef } from 'react';

function Modal({ isOpen, onClose, children }) {
  const modalRef = useRef(null);
  
  useEffect(() => {
    if (isOpen) {
      modalRef.current?.focus();
    }
  }, [isOpen]);
  
  if (!isOpen) return null;
  
  return (
    
       e.stopPropagation()}
      >
        {children}
        
      
    
  );
}

Fix 6: Add labels to all form fields

// Good (label associated with input)
Email


// Bad (placeholder as label)

Fix 7: Use semantic HTML for page structure

// Good

  ...


  ...

...

// Bad

  ...


  ...

...

Step 8: Test with a screen reader

Test your app with a screen reader (NVDA on Windows, VoiceOver on macOS, TalkBack on Android) to verify it is usable. For more on testing, see our article on the testing void.

Step 9: Run deployxa doctor

Run deployxa doctor to verify your app's health. The 14-point readiness engine checks SSL, DNS, environment variables, health endpoints, and container status.

Common Pitfalls and Troubleshooting

The first pitfall is testing only with a mouse. Many developers test only with a mouse, which means keyboard accessibility issues slip through. The fix is to test with a keyboard (Tab, Enter, Space, Escape) before deploying. The second pitfall is ignoring screen readers. Even if your app is keyboard-accessible, it might not be screen-reader-accessible (e.g., missing ARIA labels, missing alt text). The fix is to test with a screen reader before deploying. The third pitfall is overusing ARIA. ARIA is powerful, but it is not a replacement for semantic HTML. The fix is to use semantic HTML whenever possible and to use ARIA only when semantic HTML is not enough. The fourth pitfall is ignoring color contrast. Low contrast looks fine to a sighted developer but is unreadable to users with low vision. The fix is to use a contrast checker and to meet WCAG AA requirements. The fifth pitfall is not testing focus management. When the UI changes (e.g., a modal opens, a page navigates), focus should move to the appropriate element. The fix is to test focus management after every UI change.

Advanced Accessibility Patterns

Beyond the 7 fixes, accessibility benefits from several advanced patterns. The first is ARIA live regions. For dynamic content (e.g., a notification that appears after an action), use ARIA live regions (aria-live="polite" or aria-live="assertive") to announce the content to screen reader users, which ensures they are aware of the update. The second is skip links. Add a "skip to main content" link at the top of the page, which lets keyboard users skip the navigation and go directly to the main content, which saves time on pages with long navigation. The third is reduced motion. Respect the user's motion preference (via prefers-reduced-motion), which means users who are sensitive to motion can disable animations. The fourth is high contrast mode. Support high contrast mode (via prefers-contrast: high), which means users with low vision can use a high contrast theme. The fifth is cognitive accessibility. Use clear, simple language; break content into short sections; and provide summaries, which makes your app easier to understand for users with cognitive disabilities. For more on accessibility, see our articles on why AI apps break on mobile and the cookie consent trap.

When Accessibility Is Not a Priority

Accessibility is not always a priority. For internal tools (e.g., admin dashboards) that are only used by a specific team, accessibility might be less important than functionality. For prototypes and MVPs, shipping quickly is more important than accessibility, and accessibility can be added later. For hobby projects, accessibility might not be worth the effort. For these apps, focusing on functionality is more important than accessibility. The key is to match the accessibility to the app's needs: for public apps with real users, accessibility is essential (and often legally required); for internal tools and prototypes, accessibility can be deferred. For more on accessibility, see our articles on the performance regression trap and why AI-generated apps have no SEO.

Conclusion: Accessibility Is for Everyone

The accessibility gap is not a sign that your AI assistant did a bad job. It is a sign that AI assistants build apps for the "average" user, and accessibility requires additional work. By applying the 7-fix production checklist, you can make your app usable by everyone, including users with disabilities. Stop shipping inaccessible apps and start building for everyone.

Ready to ship an accessible app? Drag your project to Deployxa Drop for an instant live preview, or install the CLI with npm i -g @deployxa/cli and deploy from your terminal. For more on AI coding patterns, see our articles on the cookie consent trap and the performance regression trap. Learn about the state management mess and the testing void in our companion articles. Explore our free developer tools to speed up your workflow.