What Is Web Accessibility? Making AI-Built Apps Usable by Everyone

Why AI Coders Need to Know This

Here are the numbers that matter:

• 1.3 billion people worldwide live with a significant disability — that's roughly 16% of the global population (World Health Organization, 2023).
• ADA web accessibility lawsuits in the US have increased over 300% since 2018, with over 4,600 filed in 2023 alone.
• The disability market controls over $13 trillion in annual disposable income globally.
• 71% of users with disabilities will leave a website immediately if it isn't accessible (Click-Away Pound Survey).

If you're building with AI and shipping to real users, accessibility isn't a "nice to have" feature you add later. It's table stakes. Every inaccessible button, every missing alt tag, every keyboard trap is a user you've locked out of your product — and potentially a legal liability.

The good news? AI tools like Claude, ChatGPT, and Cursor actually know quite a bit about accessibility. The problem is they don't always apply that knowledge unless you ask. And when they do apply it, they make some predictable mistakes that are easy to catch once you know what to look for.

Understanding the basics covered here means you can review what AI generates, catch the gaps, and prompt it to fix them — in plain English, no CS degree required.

Real Scenario

You asked AI to build a signup form for your SaaS app. It looks clean. Modern design, nice colors, smooth animations. You ship it. A week later, someone emails you: "I can't use your signup form. My screen reader can't figure out what the fields are, and I can't even get to the submit button with my keyboard."

You open the code. The "button" is a styled <div> with an onclick handler. The form inputs have placeholder text but no actual <label> elements. And the entire form is inside a series of nested <div> tags with no semantic meaning whatsoever.

The form works — for people who can see the screen and use a mouse. For everyone else, it's a wall.

The problem isn't that AI can't do better. It's that the prompt said "clean" and "good UX" — which AI interprets as visual design. Accessibility is a different dimension that needs to be explicitly requested. Here's the fix:

What AI Generated (The Accessible Version)

When you prompt AI with accessibility in mind, here's the kind of code it produces — and why each piece matters:

<form action="/signup" method="POST" aria-labelledby="signup-heading">
  <h2 id="signup-heading">Create Your Account</h2>

  <div class="form-group">
    <label for="email">Email Address</label>
    <input
      type="email"
      id="email"
      name="email"
      required
      autocomplete="email"
      aria-describedby="email-hint"
    >
    <span id="email-hint" class="hint">
      We'll never share your email.
    </span>
  </div>

  <div class="form-group">
    <label for="password">Password</label>
    <input
      type="password"
      id="password"
      name="password"
      required
      minlength="8"
      autocomplete="new-password"
      aria-describedby="password-hint"
    >
    <span id="password-hint" class="hint">
      At least 8 characters.
    </span>
  </div>

  <button type="submit">Create Account</button>
</form>

Here's what makes this accessible:

• Semantic HTML: A real <form>, real <label> elements, a real <button>. Screen readers understand these natively — no extra work needed.
• Label-input linking: The for="email" on the label matches the id="email" on the input. Screen readers announce "Email Address" when the user tabs to that field.
• ARIA attributes: aria-labelledby tells the screen reader what the form is about. aria-describedby connects each hint to its input — so users hear "At least 8 characters" after the password label.
• Keyboard navigation: Real form elements are automatically focusable with the Tab key. A real <button> can be activated with Enter or Space. No JavaScript hacks needed.
• Autocomplete attributes: Helps password managers and assistive technologies fill in the right values.

The Accessibility Checklist (WCAG in Plain English)

WCAG stands for Web Content Accessibility Guidelines — the international standard published by the W3C. It's dense and technical, but you don't need to read the whole spec. Here's what actually matters, translated into things you can check:

That's six items. If every page you ship passes all six, you're ahead of the vast majority of websites on the internet. A 2024 WebAIM study found that 95.9% of the top million websites had detectable accessibility failures on their homepage.

What AI Gets Wrong

AI tools are trained on the entire internet — and the internet is overwhelmingly inaccessible. That means AI has learned a lot of bad habits. Here are the three most common mistakes:

Mistake 1: Div Soup Instead of Semantic HTML

This is the biggest one. AI loves wrapping everything in <div> elements with class names, because that's what most of the training data looks like. The result? A page that looks fine visually but is meaningless to a screen reader.

<!-- ❌ What AI often generates -->
<div class="nav-bar">
  <div class="nav-item"><a href="/">Home</a></div>
  <div class="nav-item"><a href="/about">About</a></div>
</div>
<div class="main-content">
  <div class="header">Welcome</div>
  <div class="card">
    <div class="card-action" onclick="signup()">Sign Up</div>
  </div>
</div>

<!-- ✅ What it should generate -->
<nav aria-label="Main navigation">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>
<main>
  <h1>Welcome</h1>
  <section class="card">
    <button onclick="signup()">Sign Up</button>
  </section>
</main>

The visual result is identical. The accessibility difference is massive. A screen reader user can jump directly to <nav> or <main>. They can hear "Sign Up, button" instead of just... nothing.

Mistake 2: Missing or Useless Alt Text

AI frequently generates images with no alt attribute at all, or with alt text that's useless:

<!-- ❌ No alt text -->
<img src="/images/dashboard.png">

<!-- ❌ Useless alt text -->
<img src="/images/dashboard.png" alt="image">
<img src="/images/dashboard.png" alt="dashboard.png">

<!-- ✅ Descriptive alt text -->
<img src="/images/dashboard.png"
  alt="Analytics dashboard showing monthly revenue chart and user growth metrics">

Good alt text describes what the image communicates, not just what it is. "Photo of a graph" is useless. "Monthly revenue trending upward from $10K to $45K over six months" tells the user what they'd get from seeing it.

Mistake 3: Poor Color Contrast

AI tools tend to generate trendy, low-contrast color schemes — light gray text on white backgrounds, or pastel buttons that look sleek but are barely readable for anyone with mild vision impairment. This is the most common WCAG failure across the entire web.

/* ❌ Fails WCAG AA — contrast ratio 2.5:1 */
.subtitle {
  color: #999999;
  background: #ffffff;
}

/* ✅ Passes WCAG AA — contrast ratio 7:1 */
.subtitle {
  color: #595959;
  background: #ffffff;
}

The fix is usually trivial — just darken the text color. But you won't catch it unless you check. AI optimizes for what looks good on a Retina display in a well-lit room. Your users might be reading on a cheap phone screen in direct sunlight.

Testing Accessibility

You don't need expensive tools or certification. Three free methods will catch the vast majority of issues:

1. Lighthouse Audit (Built Into Chrome)

Open your site in Chrome. Press F12 to open DevTools. Click the "Lighthouse" tab. Check "Accessibility" and run the audit. You'll get a score out of 100 plus a list of specific issues, each linked to documentation explaining what's wrong and how to fix it.

Aim for 90+ on every page. A perfect 100 is possible and not that hard for a simple site.

2. axe DevTools Extension

Install the axe DevTools extension for Chrome or Firefox. It runs a deeper analysis than Lighthouse and categorizes issues by severity. It's free for basic use and catches problems Lighthouse sometimes misses — especially around ARIA misuse and focus order.

3. The Keyboard Test (Most Important)

Put your mouse in a drawer. Seriously. Now try to use your entire site with only these keys:

• Tab — move to the next interactive element
• Shift + Tab — move to the previous element
• Enter — activate a link or button
• Space — activate a button or toggle a checkbox
• Escape — close modals and popups
• Arrow keys — navigate within menus, tabs, and radio groups

Can you reach every link, button, and form field? Can you see where the focus is on the screen (a visible outline or highlight)? Can you open and close every modal? If the answer to any of these is "no," you have a keyboard accessibility problem — and that means screen reader users are locked out too.

What to Learn Next

Accessibility builds on the fundamentals. Now that you know what to check, these guides will deepen your understanding of the building blocks:

Frequently Asked Questions