AI code generators are fast. They're also consistently terrible at accessibility. You ship an app built by Claude or Cursor that looks perfect on your monitor, then a user on a screen reader bounces off within seconds. The AI never learned accessibility rules because the training data was full of inaccessible code, and it has no visual impairment to make accessibility real.

Photo by Sanket Mishra from Pexels

Key takeaway: Key Takeaway: AI-generated code consistently fails accessibility tests because models lack incentive to include accessibility rules and have limited training data from accessible code. The four most critical failures—screen reader incompatibility, missing ARIA labels, broken keyboard navigation, and low color contrast—can be caught and fixed before launch by following a structured testing workflow: semantic HTML first, keyboard-only navigation testing, automated tool scans, screen reader verification, and real user testing with disabled testers.
TL;DR:
  • AI-generated code skips accessibility because the model has no incentive to include it and limited accessibility-focused training data.
  • Screen reader incompatibility, missing ARIA labels, poor keyboard navigation, and color contrast failures are the four most common issues.
  • Inspect and test your app manually (text at 200%, keyboard-only, screen reader) before launch, not after.
  • Use a checklist, automated tools (axe, Lighthouse), and involve actual disabled users in testing.

AI-generated apps inherit a blind spot. The model doesn't see accessibility as a requirement, it sees it as optional polish that isn't baked into the fastest code path. When you ask Claude to build a React component, it returns working JSX. When you ask it to build an accessible React component, you get the same JSX most of the time, because accessibility isn't visible in the rendered output. It's a contract between the code and assistive technology that the AI has never negotiated.

This means accessibility failures aren't a bug in the AI. They're a feature of how these models were trained. Your job is to close the gap by building accessibility into your workflow the same way you'd build in testing or security.

Why this matters now

0 in 7
Users worldwide have disabilities

The scale of the problem is larger than most founders realize. One in seven people globally experience some form of disability that affects their ability to use digital products. That's not a niche market segment, it's one-seventh of your potential user base. Add legal liability (WCAG lawsuits are increasing), and accessibility goes from nice-to-have to necessary.

AI-built apps amplify the problem because they're shipped faster, tested less rigorously, and usually by people who don't know what to look for. A human developer writing accessibility-ignorant code is a choice. An AI writing it is a systemic failure. The difference is you can fix the system.

Common mistakes and misconceptions

Mistake 1: "We'll fix accessibility later."

Accessibility baked into the design and code is cheaper to build than retrofitting it. Adding ARIA labels after shipping is possible but fragile. Rebuilding a color contrast system because you picked the wrong palette on launch is painful. Prevention beats remediation.

Mistake 2: "Accessibility is only for screen reader users."

Wrong. Accessibility helps people with motor disabilities (keyboard navigation), cognitive disabilities (clear labels and structure), low vision (color contrast and text scaling), color blindness, hearing impairments, and aging users. You're not building for a disability type, you're building for humans with varied needs.

Mistake 3: "Automated testing catches accessibility issues."

Automated tools (axe, Lighthouse) catch maybe 30% of real accessibility problems. They find missing alt text and low contrast ratios. They miss logical tab order, heading hierarchy that makes sense to humans, and whether a screen reader user can actually understand what they're reading. Automation is a safety net, not a substitute for real testing.

Mistake 4: "The AI will handle it if I ask nicely."

Asking Claude to "make it accessible" in a prompt is like asking it to "make it secure." The model will add some ARIA attributes and call it a day. You need to specify exactly what you want: semantic HTML, keyboard support, ARIA roles where needed, contrast ratios. Even then, you must verify the output.

coding workspace
Photo by Jakub Zerdzicki from Pexels

Step-by-step approach

1. Start with semantic HTML

The foundation of accessible code is semantic HTML. Don't ask the AI to build custom components when native HTML elements exist. A button should be . The arrow alone tells you nothing. A screen reader user hears "arrow button" and has no idea what it does. Correct: .

Fix: Review every ARIA attribute. If you can't explain what it does, it's wrong.

2. Keyboard navigation broken

A custom dropdown component looks perfect in the browser. Tab doesn't open it. Arrow keys don't work. The AI built the visual component but didn't wire up keyboard events.

Fix: Test keyboard-only before launch. If Tab doesn't reach it or arrow keys don't work, it's broken.

3. Color contrast too low

The AI picks a light gray text on white background because it looks elegant. It fails the WCAG AAA contrast ratio (7:1). Even AA (4.5:1) is hard to read for many people.

Fix: Run a contrast checker. Aim for 4.5:1 minimum for normal text, 3:1 for large text. Make it a build step, fail the deploy if contrast is too low.

4. Heading hierarchy is broken

The AI uses

, then

, skipping

. A screen reader user navigates by headings and gets confused. Headings aren't decorative, they're the outline of your content.

Fix: Check your heading structure. Always go h1 > h2 > h3, never skip levels. One h1 per page.

accessibility checklist
Photo by Jan van der Wolf from Pexels

Integrating accessibility into your workflow

The best time to catch accessibility failures is before they ship. Build accessibility checks into your pull request process. Use axe or similar tools as a pre-commit hook. Fail the build if contrast ratios are below 4.5:1. Make it hard to ship inaccessible code.

When you generate new features with AI:
  1. Prompt for semantic HTML and keyboard support explicitly.
  2. Run automated checks before review.
  3. Manual testing (keyboard, screen reader) before merge.
  4. Deploy with confidence, knowing you've actually tested it.
This adds maybe 30 minutes per feature the first few times. After that, it becomes muscle memory and moves faster.
Pre-Launch Accessibility Checklist Status
✓
Semantic HTML structure
✓
Color contrast (4.5:1+)
✓
Keyboard navigation
✓
Heading hierarchy
✓
ARIA labels & roles
✓
Automated tool scan
⧗
Screen reader test
⧗
User testing with disabled tester

This dashboard shows the typical pre-launch checklist. Early items (semantic HTML, color contrast, keyboard navigation) are your responsibility and the AI's responsibility. Later items (screen reader testing, user testing) require human involvement. The shift from automated to manual testing is where you catch 60+ percent of real accessibility problems.

|

AI-Generated App Accessibility Verification

Your progress is saved automatically in your browser.

FAQ

Frequently Asked Questions

Anyone shipping AI-generated apps who wants them to work for the one-in-seven people with disabilities. This applies whether you're a solo founder using Cursor to build an MVP or a small team using Claude to rapidly prototype features. If your app doesn't need to be accessible to everyone, you can skip this. If it does, this guide shows you the fastest path to catch and fix accessibility failures.
For a new AI-generated feature, maybe 30-45 minutes the first time: prompt for accessibility, run automated checks (5 min), keyboard test (10 min), screen reader spot check (15 min). After a few features, it becomes routine and drops to 20 minutes. If you have existing inaccessible code to retrofit, budget days or weeks depending on app size. Prevention beats remediation.
Start with keyboard navigation. Close your mouse and Tab through your app. If every interactive element is reachable and tab order makes sense, you've fixed 40% of common problems. Then run Lighthouse and fix the contrast and ARIA issues it flags. Finally, do a screen reader test or hire someone to do it. This order goes from fastest feedback loop to slower but more thorough testing.
No. Automated tools catch about 30% of real accessibility problems. The other 70% require human testing with actual assistive technology or disabled users. A tool won't tell you if your heading hierarchy confuses screen reader users or if your form instructions are unclear. Skip manual testing and you're shipping half-tested code.
Be specific in your prompt: "Use semantic HTML form elements (not divs). Include visible labels with htmlFor attributes. Make it keyboard accessible, Tab between fields, Enter to submit. Add ARIA labels only where HTML semantic meaning isn't enough. Test keyboard navigation and screen reader compatibility."

Don't just ask for "accessible code", the AI interprets that weakly. Specify exactly what you want: semantic elements, keyboard support, ARIA where needed.


WCAG AA (Web Content Accessibility Guidelines level AA) is the legal standard in many jurisdictions and a good target. But compliance doesn't guarantee usability. Your app can be technically WCAG AA compliant and still be painful to use. Real user testing catches usability issues that checkboxes miss. Aim for compliance as a baseline, usability as the goal.

The gap between fast and accessible narrows every time you build accessibility into your workflow instead of bolting it on afterward. AI makes shipping speed possible. Your job is to make sure that speed doesn't come at the cost of excluding 14% of the world. Test early, test often, and involve actual disabled users before launch. That's the difference between an app that works for everyone and one that works for most people.

Additional Resources

What does your current accessibility testing workflow look like, and where do you think AI-generated code is most likely to fail it?