Whether you build in a chat window with Lovable, Bolt, v0 or Replit, or let a coding agent such as Claude Code, Cursor or GitHub Copilot write code in your own project, the same thing is true: the AI builds what you ask for. Accessibility, making a site usable for people with a disability, only shows up reliably when you ask for it. This page is the short version: five habits, one block of instructions you can paste into any tool, and a routine to check the result. The guides for each tool, linked at the end, show where the instructions go and which problems to watch for.
Why accessibility slips
AI models learn from existing websites, and most of them are not accessible. In WebAIM’s 2026 check of the one million most visited home pages, 95.9% had problems that automatic tests could detect. A tool that learns from the average site picks up its habits: light grey text, buttons that are only an icon, forms without labels.
Three more things work against you:
- You judge with your eyes. A builder shows you how the page looks, not how it sounds in a screen reader (software that reads the screen aloud) or how it behaves with only a keyboard.
- Conversations forget. A request from twenty messages ago may no longer count when the AI rewrites a page.
- Every change can undo a fix. A new section or redesign can bring back a problem you already solved.
Five habits that prevent most problems
1. Put your instructions somewhere permanent
Every serious tool has a place for standing instructions that apply to every request: knowledge or project instructions in chat builders, an instructions file in coding agents. Put your accessibility rules there once instead of repeating them in prompts. The platform guides tell you where that place is.
2. Ask for real buttons, real links and visible labels
Ask for “semantic HTML”: page parts that say what they are. A button should be a real button, not a box that reacts to a click, so it works with the Tab key and a screen reader announces it. Every form field needs a visible label above it, not just grey hint text that disappears when you type.
3. Keep the focus visible
When someone moves through a page with the Tab key, a frame or underline shows where they are. That is the focus indicator. Designs that look “clean” often remove it. Ask for a clear focus style on every link, button and field, and never let the AI remove it without a replacement.
4. Check contrast
Contrast is the difference in lightness between text and its background. Normal text needs a ratio of at least 4.5:1, large text 3:1, according to WCAG 2.2, the international accessibility guidelines most laws build on. Pale grey on white, text on photos and soft pastel themes are the usual problems. Check dark mode too, if your site has one.
5. Write real image descriptions and link texts yourself
Alt text is the short description a screen reader reads instead of an image. The AI can fill it in, but it does not know that the photo shows your shop or that the chart is about this year’s bookings. Link texts work the same way: “Read more” six times on one page tells a screen reader user nothing. Review both yourself, every time you add an image or a link.
Instructions for any tool
Paste this block into your tool’s permanent instructions before you build. In a tool without them, paste it at the top of your first message. For a site that already exists, add it and then ask the AI to review every page against it.
Accessibility rules for this whole project (aim for WCAG 2.2 level AA). Follow them in every change and tell me when a request conflicts with them. - Use semantic HTML: header, nav, main, footer, real button elements for actions and real a elements for links. Never make a div, span or card clickable on its own. - Every form field has a visible label linked to it. Placeholders are never the only label. Show errors as text next to the field, not only in a toast or in colour. - Every icon-only button or link has an accessible name in the site language, such as "Open menu". - Keep a clearly visible focus style on every interactive element. Never remove outlines without a visible replacement. - Text contrast is at least 4.5:1 (3:1 for large text, icons, field borders and focus styles), in light and dark mode. - Meaningful images get alt text that describes their purpose; decorative images get alt="". Ask me when you cannot know what an image shows. - Link text says where the link goes. No "click here" or repeated "read more". - Set the page language on the html element and give every page a unique title. One h1 per page, headings in order. - Everything works with the keyboard alone. Dialogs move focus inside, close with Escape and return focus afterwards. - Respect prefers-reduced-motion. Never use colour alone to convey meaning.
Check, fix, check again
You do not need to read code for this. You need a routine you repeat until the important problems are gone.
- Publish a preview on a public web address. A checker cannot reach a page that only exists inside the builder or behind a login.
- Check the page with ibin. You get a plain-language list of problems, ordered by what to fix first, with a close-up picture of where each one is.
- Copy the fix. Each problem has a “Copy instructions for an AI tool” button. Paste the result into your builder or agent. It asks for a repair in the site itself, not a patch on top.
- Fix one problem at a time. Short, focused requests work better than one long list.
- Check again until the problems marked as most urgent are gone. Then sign in to check up to 200 pages of the same site, because builders repeat the same menu, footer and forms everywhere.
- Turn on weekly checks so you hear about it when a later change brings a problem back.
Automatic checks find roughly a third to half of all problems. Also do the 10-minute keyboard test on your home page and your most important form. The repair guides explain each problem in plain language when you want to understand a fix.
What still needs a person
No AI and no automatic check can decide whether an image description is right, whether a link text makes sense out of context, whether your copy is easy to read or whether a booking flow feels logical. ibin’s optional second look from AI rates image descriptions, link texts, keyboard use and language on a scale from 1 to 5, so you know where to look first. Those scores are leads, not verdicts. If you can, ask someone who uses a keyboard or a screen reader every day to try your site.
Guides for each tool
Each guide covers what the tool generates, where its permanent instructions live, a ready-to-paste block adapted to it and follow-up prompts for its typical problems.
- Lovable: project knowledge and workspace knowledge
- Bolt: project knowledge and Bolt’s own hosting
- v0: Instructions, from the + button in the prompt bar
- Replit: the instructions file of the Replit agent
- Coding agents: Claude Code, Cursor, GitHub Copilot and similar tools
For a longer explanation with a full list of follow-up prompts, read Built with an AI builder? Make it accessible from the first prompt.
Check your AI-built site
Publish a preview and check a page for free with ibin. Use “Copy instructions for an AI tool” on each problem, paste it into your builder and check again until the urgent problems are gone.
See how your own site does
Check a page for free, without an account. You get a plain list of what to fix first, with pictures of where each problem is.