You Built Your Site With an AI App Builder. Here's What You Have to Fix Before Launch.

You described what you wanted, the AI built it, and the preview looks great. That is the promise of tools like Lovable, v0 by Vercel, and Bolt.new, and for the most part they deliver. You can go from an idea to a working website or app in an afternoon without writing a line of code yourself.

But there is a catch that nobody mentions in the demo videos: the AI optimizes for what looks right in the preview pane, not for what works for everyone who visits. A screen reader user, a person navigating with only a keyboard, someone with low vision squinting at light-gray text in the sun — none of them are represented in that preview. So the AI cheerfully ships code that looks perfect and quietly excludes a chunk of your audience.

The frustrating part is that you usually cannot see the problem. You did not write the code, so you cannot read it to check. And the issues do not show up visually, so clicking around with a mouse tells you nothing is wrong.

Here is the good news. AI builders make almost exactly the same five mistakes every single time. Once you know what they are, you can find them in about twenty minutes and fix most of them by sending the AI a follow-up prompt. You do not need to open the code, install developer tools, or learn what any of the acronyms mean. Let’s walk through them.

Why this matters beyond being nice

Before the fixes, one quick reason to care. If your site sells anything, takes bookings, or collects information from people in the European Union, the European Accessibility Act has applied to it since June 2025. In the United States, the Americans with Disabilities Act has been used for years as the basis for thousands of lawsuits against businesses whose websites people with disabilities could not use. Most of these cases are not about exotic edge cases. They are about exactly the five basic problems below.

So this is not a polish-it-later task. The same fixes that make your site usable for more people also reduce a real legal and financial risk. And because AI builders make these mistakes so predictably, fixing them is one of the highest-value twenty minutes you can spend before launch.

Mistake 1: Buttons that the keyboard cannot reach

This is the most common and the most serious. When you ask an AI builder to make something clickable — a “Sign up” button, a card that opens a detail view, a menu item — it often builds that element as a generic clickable box rather than a real button or link.

The difference is invisible with a mouse. Both versions click the same way. But a real button can be reached by pressing the Tab key and activated by pressing Enter or the spacebar. The fake version cannot. It is simply skipped over, as if it were not there. Anyone who navigates with a keyboard instead of a mouse — which includes many people with motor disabilities and most screen reader users — cannot use it at all.

How to check: Open your published site, click once on an empty part of the page, then press the Tab key repeatedly. You should see a visible outline jump from one interactive thing to the next: every link, every button, every form field. Go through your whole page this way. If you reach something you can click with a mouse but Tab refuses to land on it, you have found this bug.

How to fix: Tell your AI builder, in plain words: “Replace every clickable div or span with a real button for actions and a real link for navigation, so they all work with the keyboard.” Then re-test with the Tab key. This single prompt fixes the majority of cases.

Mistake 2: Form fields with no real labels

AI builders love to keep forms looking clean by putting the field name inside the box as faint gray placeholder text — “Email address,” “Your name,” “Message” — with no separate label above it.

It looks tidy, but it creates two problems. The moment someone starts typing, that hint disappears, so anyone who gets distracted or comes back later has no idea what the field was for. And screen readers handle placeholder text unreliably, so a blind user may land on a box with no announced purpose at all. They are left guessing what to type.

How to check: Look at each form on your site. Does every field have a label that stays visible even after you click into it and start typing? If the only description vanishes when you type, that is the bug.

How to fix: Prompt the AI: “Add a visible label to every form field that stays on screen at all times, and use the placeholder only as an optional example.” Persistent, visible labels are better for everyone, not just screen reader users — they cut down on mistakes and confusion across the board.

Mistake 3: Text you can barely read

To look modern and minimal, AI builders reach for light gray text on white backgrounds — for captions, secondary details, placeholder hints, and sometimes even body copy. It reads fine to the designer staring at a bright laptop screen indoors. It becomes nearly invisible to someone with aging eyes, low vision, or anyone using their phone outdoors.

There is an actual standard here. Normal-size text needs enough contrast against its background — a ratio of at least 4.5 to 1 — to meet accessibility guidelines. A lot of trendy gray-on-white falls well short of that line.

How to check: Look at the lightest text on your site — footer notes, captions, form hints, muted subtitles. If you find yourself leaning in or squinting even slightly, it is probably too light. For a precise reading, the free WebAIM Contrast Checker lets you compare two colors.

How to fix: Tell the AI: “Check all text colors for WCAG AA contrast and darken anything that fails so it is comfortably readable, especially captions, placeholder text, and muted labels.” You will lose nothing but a little of that washed-out look, and your content becomes legible to far more people.

Mistake 4: Images that say nothing to screen readers

Every meaningful image on a website needs a short written description, called alt text, that a screen reader can read aloud to someone who cannot see it. AI builders almost always drop in images — hero graphics, product photos, logos, icon-only buttons like a magnifying glass for search — with this description missing or left blank.

When that happens, a blind visitor hears nothing where your image is, or worse, hears a meaningless file name read out letter by letter. If the image carried real information — a chart, a product, a button that only shows an icon — that information is simply gone for them.

How to check: This one is hard to see by eye, which is exactly why it gets missed. The quickest route is a free tool (see the toolbox below) that flags missing alt text for you. Pay special attention to buttons that are only an icon with no words, like a hamburger menu or a close X — those need a description too.

How to fix: Prompt the AI: “Add a short, descriptive alt text to every informative image, mark decorative images as decorative, and give every icon-only button a label describing what it does.” Then read the descriptions the AI wrote — its alt text is often vague, so improve anything that does not actually describe the image.

Mistake 5: Pop-ups and menus that trap or lose you

When an AI builds a custom pop-up, dialog, or dropdown menu from scratch, it frequently forgets the invisible plumbing that makes these work for keyboard and screen reader users. Opening a dialog should move you into it; pressing Escape should close it; closing it should return you to where you were. Built carelessly, a pop-up can leave a keyboard user stranded — unable to get in, unable to get out, unable to reach the page behind it.

How to check: Find a pop-up, modal, or dropdown on your site and open it using only the keyboard (Tab to the trigger, then Enter). Can you reach the controls inside it with Tab? Does the Escape key close it? Can you get back to the page afterward? If any of those fail, this is your bug.

How to fix: Ask the AI: “Rebuild the pop-ups, dialogs, and dropdown menus using an accessible component library so that keyboard focus, the Escape key, and screen reader behavior all work correctly.” This is the one fix where leaning on a well-tested building block beats hand-rolled code, and the AI can usually swap it in for you.

Your twenty-minute pre-launch routine

You do not need to memorize any of this. Just run these checks once before you launch, and again after any big change:

  1. Tab through the whole page. Every clickable thing should be reachable and show a visible focus outline.
  2. Look at every form. Each field needs a label that stays put.
  3. Hunt for the faintest text. If you squint, darken it.
  4. Scan for missing image descriptions with a free checker.
  5. Open every pop-up with the keyboard and make sure Escape gets you out.

A quick warning specific to AI builders: when you prompt the tool to add a new feature, it often rewrites surrounding code and quietly undoes fixes you made earlier. Accessibility is not one-and-done here. Re-run this five-point routine after every significant change, not just once at the end.

A small free toolbox

You do not need to buy anything to do this. Three free tools cover almost everything above:

  • WAVE (wave.webaim.org) — a browser add-on that visually marks accessibility problems right on top of your live site, including missing labels and image descriptions.
  • WebAIM Contrast Checker (webaim.org/resources/contrastchecker) — paste in two colors and it tells you instantly whether your text passes.
  • Your keyboard’s Tab key — the single best accessibility tool you already own, and the one that catches the most serious problems.

AI builders are genuinely wonderful for getting an idea online fast. They are just not yet wise enough to build for everyone on their own. That last twenty minutes of checking is the part that is still yours to do — and now you know exactly what to look for.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.