Accessibility in AI-Generated Code: Missing Alt Text and ARIA Labels

The Scale of the Accessibility Problem in AI-Generated Code

Accessibility is the category most consistently skipped by AI coding tools. When Bolt, Lovable, v0, or Cursor generate a UI component, they optimise for visual appearance and functional correctness - the two dimensions the developer can immediately evaluate. Accessibility attributes are invisible during development and don't cause build failures, so they land at the bottom of the priority stack.

The numbers are stark. According to WebAIM's 2024 Million report, 96.3% of home pages have detectable WCAG failures, with missing alternative text on images and empty or missing button labels being the #1 and #2 most common failures respectively. For AI-generated applications, those figures are likely higher because the tools have no automatic WCAG validation in their output pipeline.

The legal exposure is real. In the United States, web accessibility lawsuits under the ADA have exceeded 4,000 per year since 2022, according to UsableNet's annual ADA digital accessibility lawsuit report. The majority involve precisely the failures that AI tools generate: missing alt text, unlabelled form controls, and keyboard-inaccessible interactive elements.

Missing Alt Text: What WCAG Requires

WCAG 2.1 Success Criterion 1.1.1 (Level A) requires that every non-text content element - primarily images - has a text alternative. For images that convey information, the alt text must convey the same information. For decorative images, the alt attribute should be set to an empty string (alt=""), which signals to screen readers to skip the image entirely.

AI tools produce three distinct failure patterns:

// ❌ BAD - No alt attribute at all (WCAG 1.1.1 failure)


// ❌ BAD - Filename as alt text (meaningless to screen reader users)


// ❌ BAD - Generic filler text

When an alt attribute is missing entirely, most screen readers announce the filename - so users hear "product dot jpg" instead of any meaningful description. Generic values like "image" or "photo" are no better: they tell the user that content exists but nothing about what it is.

// ✅ GOOD - Descriptive alt text that conveys meaning


// ✅ GOOD - Empty alt for purely decorative images


// ✅ GOOD - Dynamic alt text from data
{products.map(product => (
  
))}

Missing ARIA Labels on Buttons and Interactive Elements

WCAG 2.1 Success Criterion 4.1.2 (Level A) requires that all user interface components have names that can be programmatically determined. A button with only an icon and no text has no accessible name unless you provide one via aria-label or aria-labelledby.

AI tools generate icon buttons constantly - close buttons, menu toggles, social share buttons - and almost never include accessible labels:

// ❌ BAD - Icon-only button with no accessible name

  


// ❌ BAD - Generic label that adds no context

  


// ❌ BAD - aria-label on non-interactive element instead of the button

  

Screen readers announce the first example as "button" - giving keyboard users and screen reader users no indication of what the button does. In a modal with three icon buttons (close, minimize, expand), all three are announced identically as "button".

// ✅ GOOD - aria-label on the interactive element

  


// ✅ GOOD - Visible text that also serves as the accessible name

  
  Open menu


// ✅ GOOD - aria-labelledby referencing visible text

  
  Delete item

Note the aria-hidden="true" on the icon in the good examples. SVG icons should be hidden from the accessibility tree when a separate text label exists, otherwise screen readers announce both the label and any title embedded in the SVG.

WCAG Failure Reference for Common AI-Generated Patterns

How to Audit Your AI-Generated App for Accessibility

Manual review catches the obvious cases, but a systematic approach is more reliable:

1. Run axe DevTools or Lighthouse accessibility audit: Both tools run in Chrome DevTools and automatically flag missing alt text, missing form labels, and insufficient color contrast. Lighthouse's accessibility score directly reflects WCAG Level A and AA conformance.
2. Navigate with a keyboard only: Tab through every interactive element on each page. If you can't reach a control with Tab, or if focus disappears into an unlabelled region, you have a keyboard accessibility failure.
3. Test with a screen reader: VoiceOver (macOS/iOS), NVDA (Windows, free), or TalkBack (Android) will reveal every missing label. Navigate through your app with the screen on and rely entirely on what's announced.
4. Run automated scanning: Tools like VibeDoctor (vibedoctor.io) automatically scan your codebase for missing alt attributes (FE-005a) and missing aria-labels on buttons (FE-005b) and flag specific file paths and line numbers. Free to sign up.
5. Add ESLint jsx-a11y: The eslint-plugin-jsx-a11y package catches accessibility violations at write-time in your editor. Configure it with the recommended ruleset in your .eslintrc.

Supabase, Vercel, and Next.js Specific Notes

Next.js includes a built-in accessibility check via its ESLint configuration. The eslint-config-next package includes jsx-a11y rules by default, but only the "strict" subset. Projects generated by v0 or Cursor using the Next.js App Router template have these rules available - but AI-generated components are often placed outside the linted directory or the rules are set to "warn" rather than "error", meaning they don't block builds.

When deploying to Vercel, the platform runs your Next.js build but does not run accessibility audits. A site with hundreds of WCAG failures deploys without any warning. Accessibility validation must be added to your CI pipeline explicitly - either via axe-core in your test suite or via a Lighthouse CI GitHub Action.

FAQ