Accessible by Default: WCAG for AI-Written Interfaces

AI can write a beautiful component in seconds — and an inaccessible one in the same time. The accessibility problems in AI-generated interfaces aren't usually exotic. They're the classics: unlabeled buttons, missing alt text, <div onClick> instead of <button>, and colors that look great in a design mockup and fail contrast checks in a real browser.

The direct answer: your AI-generated UI needs the same WCAG 2.1 AA baseline as anything else — and the fastest way to find what's broken is an automated audit. Here's the baseline, the common AI failures, and how to check your work in minutes.

#The WCAG 2.1 AA baseline, distilled

WCAG 2.1 AA has ~50 checkable criteria, but for a typical AI-built site the practical baseline is:

That's the W3C's WCAG 2.1 spec compressed to one table.

#What AI models get wrong

From scanning a lot of AI-generated sites, the same patterns keep showing up:

1. Icons without names. "Add a search icon" → <svg> with no label. Screen readers announce nothing. Fix: aria-label or a visually-hidden <span>.
2. div pretending to be a button. AI loves onClick on a <div>. It's not keyboard-accessible and not announced. Fix: use <button>, or add role="button", tabindex="0", and key handlers.
3. Decorative images with meaningful alt. Or worse, alt="image" on everything. Fix: alt="" for decoration, real descriptions otherwise.
4. Designer colors that fail contrast. That trendy green-on-white accent? Often 2.5:1. Fix: darken the accent or lighten the background until it passes 4.5:1.
5. No heading structure. Five <div> "headings" instead of <h1>-<h6>. Fix: use real heading tags in order.

None of these are hard to fix. They're hard to notice — which is what automation is for.

#Auditing in minutes

You don't need a manual pass to catch the first 50%. An automated audit runs axe-core (the same engine Deque maintains, used by the axe-core project) against your rendered page and returns violations grouped by impact — critical, serious, moderate, minor — each with the offending element and a fix suggestion.

A typical flow:

1. Audit the page — get the violation list grouped by impact
2. Fix serious + critical first — contrast, labels, and keyboard issues are almost always there on the first run
3. Re-audit — watch the count drop to zero
4. Manual pass — walk the page with Tab, check focus order, run a screen reader over the main flows

That last step matters: automation finds roughly half of WCAG issues. The keyboard walk is where the rest show up.

#Accessibility is part of shipping

Treating accessibility as a post-launch thought is how sites end up inaccessible. The AI workflow makes it easy to fold in:

• Audit every page before you ship it, the same way you'd scan it for security. It's part of the pre-launch checklist.
• Fix at the component level. An accessible Button component means every future page inherits it. Audit components, not just pages.
• Re-audit after AI refactors. The same model that built it will happily remove your aria-label in the next prompt if you don't check.

Accessibility is also a business decision: it's a legal requirement in much of the world (ADA, EAA), a ranking factor, and — same as security — the vibe coding mindset treats it as infrastructure, not a feature: set it up once, verify every time.

#The bottom line

AI won't make your UI inaccessible on purpose — it'll do it by default, the same way it defaults to unoptimized bundles and missing headers. The fix is the same in all three cases: audit what AI produces, fix the findings, and make the audit part of shipping. Ten minutes, every page, forever.