Web Accessibility Basics: Making Your App Usable by Everyone

Millions of people use the web differently from the way you do: with a screen reader that reads the page aloud, with only a keyboard, with the page zoomed to 200%, with captions, or with colour vision differences. Accessibility (often written a11y) means building your app so they can use it too.

It's also the law in more places each year — the European Accessibility Act has applied to many consumer-facing digital products and services sold in the EU since June 2025 — and it tends to make apps better for everyone.

The standard: WCAG

The Web Content Accessibility Guidelines (WCAG) are the international standard. The current version is WCAG 2.2, and "Level AA" is what most laws and contracts point to. You don't need to read all of it; the basics below cover the most common problems.

The common failures in AI-built apps

1. Buttons that aren't buttons

AI tools sometimes produce clickable <div>s:

<!-- ❌ Can't be reached with the keyboard; screen readers don't announce it as a button -->
<div class="btn" onclick="save()">Save</div>

<!-- ✅ Works with keyboard, screen readers, and everything else -->
<button onclick="save()">Save</button>

Use real <button> elements for actions and real <a href> links for navigation. They come with keyboard support and correct announcements for free. (HTML, CSS, and JavaScript Explained.)

2. Form fields without labels

A placeholder isn't a label — it disappears when you type, and screen readers may not announce it.

<!-- ❌ -->
<input placeholder="Email">

<!-- ✅ -->
<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

Error messages should say what's wrong and be connected to the field, not just turn the border red. (Form Validation Explained.)

3. Images without alt text

Every meaningful image needs an alt description: alt="Bar chart of monthly sales, peaking in July". Decorative images get an empty alt="" so screen readers skip them.

4. Icon-only buttons with no name

A button containing only a trash-can icon is announced as just "button." Give it a name:

<button aria-label="Delete plant">🗑️</button>

5. Poor colour contrast

Light grey text on white looks elegant and is unreadable for many people. WCAG AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Browser DevTools show the contrast ratio when you inspect text.

And don't rely on colour alone: "fields in red are required" fails people who can't distinguish red. Add text or an icon.

6. Invisible keyboard focus

Press Tab through your app. Can you see where you are at every step? Many designs remove the focus outline (outline: none) because it "looks ugly," which makes keyboard use impossible. Keep a visible focus style.

7. Keyboard traps and unreachable elements

Pop-ups that can't be closed with Esc, menus that only open on hover, custom dropdowns that ignore arrow keys. If you can't do it with the keyboard, some of your users can't do it at all.

8. Headings used for size, not structure

Screen reader users navigate by headings. Use one <h1> per page, then <h2>, <h3> in order — chosen for structure, not for how big the text looks.

9. Missing page language and titles

<html lang="en"> tells screen readers which language to speak. A unique <title> on each page tells everyone where they are.

A ten-minute test

Keyboard only. Unplug the mouse (or don't touch it). Tab through your main flow — sign up, the core action, checkout. Can you reach and use everything? Can you see where focus is?
Zoom to 200%. Does anything overlap, get cut off, or require scrolling sideways? (Responsive Design Basics.)
Run Lighthouse in Chrome DevTools → Accessibility. Fix what it flags. (Browser Developer Tools for Beginners.)
Try a screen reader for a few minutes: VoiceOver on Mac and iPhone (Cmd + F5), Narrator on Windows (Ctrl + Win + Enter), or TalkBack on Android. Listen to your sign-up form.

Automated tools like Lighthouse and axe catch a portion of issues. The keyboard and screen reader tests catch many of the rest.

Asking your AI tool to fix it

AI tools are good at accessibility fixes when asked specifically:

Audit the sign-up and checkout pages for accessibility against WCAG 2.2 AA. Replace clickable divs with buttons, add labels to every form field, add alt text to images, give icon-only buttons accessible names, make sure focus is always visible, and check colour contrast. List every change.

Then do the keyboard test yourself — it's the one check that proves it worked.

Add a line to your CLAUDE.md so new code starts accessible: "Use semantic HTML; every input has a label; every interactive element works with the keyboard." (How to Write a CLAUDE.md.)

Checklist

Real buttons and links, not clickable divs
Every form field has a visible label
Images have meaningful alt text (or alt="" if decorative)
Icon-only buttons have accessible names
Text contrast at least 4.5:1
Visible focus on every interactive element
Everything works with the keyboard; pop-ups close with Esc
Headings in a logical order; lang set; unique page titles

EasySpawn runs your app on a real address from a persistent workspace, so you can test with real screen readers and devices — and have Claude Code fix what you find in the same place. See how it works or join the waitlist.