AI website builders such as Lovable, Bolt and v0 let you describe a site in a chat window and watch it appear within minutes. You type "a landing page for my yoga studio with a booking form", and the tool writes the code, usually in React (a widely used way to build web pages) styled with Tailwind CSS. The builder mostly does what you ask for, though. If accessibility is not in your instructions, it is left to chance, and a site can look polished while being hard to use for people who navigate with a keyboard, listen with a screen reader (software that reads the screen aloud) or need stronger contrast. A short set of instructions at the start and a simple checking routine afterwards prevent most of the common problems. This article gives you both, ready to copy.
Why accessibility slips in AI-built sites
Building a site by chatting with AI is often called "vibe coding", a term Andrej Karpathy coined in February 2025. Lovable, Bolt (bolt.new) and v0 by Vercel are among the best-known tools for it. All three let you save standing instructions that apply to every request: Lovable and Bolt call this knowledge and keep it in your project settings, and v0 lets you save instructions (from the + button in the prompt bar) that apply to every chat until you switch them off. Some builders use ready-made components such as shadcn/ui, whose menus and dialogs come with keyboard support, and Lovable's documentation lists accessibility checks among its built-in skills. Useful foundations, but they only cover the parts the AI decides to use.
The deeper reason is that AI models learn from existing web code, and most of the web is not accessible. According to WebAIM's 2026 analysis of the top one million home pages, 95.9% had errors that automatic tests could detect. Low-contrast text appeared on 83.9% of pages, images without alt text on 53.1% and form fields without labels on 51%. A tool that learns from the average website also learns its habits.
Common patterns to watch for
These patterns often appear in generated sites. They are not claims about any specific tool, and clear instructions prevent most of them.
- Clickable boxes that are not real buttons. A card or plain box (a "div" in code) responds to a mouse click, but you cannot reach it with the Tab key and a screen reader does not announce it as something to press.
- Trendy low-contrast palettes. Prompts like "minimal" or "soft pastel" tend to produce light grey text on white, which many people cannot read comfortably.
- Icon-only buttons without a name. A menu icon, close cross or social icon that a screen reader announces only as "button". WebAIM found empty buttons on 30.6% and empty links on 46.3% of home pages.
- Fields with only a placeholder. The grey hint inside a field disappears as you type, and no label says what the field is for.
- Images without alt text. Alt text is a short written description of an image that screen readers read aloud. Generated sites often skip it or fill in "image" or a file name.
- Animation everywhere. Fade-ins, parallax and auto-playing carousels. Motion can make some people dizzy, which is why devices offer a "reduce motion" setting.
- Pop-ups that lose the keyboard. A dialog opens, but Tab moves behind it, Escape does nothing, or there is no way out.
- Missing page language and jumbled headings. Without a language, a screen reader may pronounce your text with the wrong accent. Headings picked for their size break the page outline.
The accessibility instructions to paste first
Paste this block into your builder's standing instructions before you generate the first version, or at the top of your first prompt in tools without them. It refers to WCAG, the Web Content Accessibility Guidelines from the W3C, the international standard most accessibility rules build on.
Accessibility requirements for this whole project. Aim for WCAG 2.2 level AA. Follow these rules in every change, and tell me when a request would conflict with them. 1. Use real buttons for actions and real links for navigation. Never make a div, span or card clickable on its own. If a whole card should be clickable, put a real link inside it. 2. Every form field has a visible label that stays visible while typing. A placeholder is never the only label. Error messages appear in text next to the field and explain how to fix the problem. 3. Every meaningful image has alt text that describes what it shows or does. Decorative images get an empty alt (alt=""). Ask me when you cannot know what an image means. 4. Text has a contrast ratio of at least 4.5:1 against its background. Large text (24px, or about 19px bold) and icons, field borders and focus indicators need at least 3:1. This includes dark mode and text on images or gradients. 5. Every link, button and form field has a clearly visible keyboard focus style. Never remove the focus outline without a visible replacement. 6. Every icon-only button or link has a name that says what it does, such as "Open menu" or "Close dialog", in the language of the site. 7. Each page has one h1 that describes it, and headings follow in order (h2, then h3) without skipping levels. Never choose a heading level for its size. 8. Set the page language on the html element (for example lang="en") and give every page a unique, descriptive title. 9. Everything works with a keyboard alone. Tab moves in a logical order, Enter and Space activate buttons, menus open and close with the keyboard, and Escape closes dialogs and menus. When a dialog opens, move focus into it, keep it there until it closes, then return focus to the button that opened it. 10. Respect the prefers-reduced-motion setting by turning off parallax, auto-playing carousels and large movement when it is on. Nothing moves automatically for more than five seconds without a way to pause it. 11. Tap targets are at least 24 by 24 pixels, and main buttons and menu items at least 44 by 44 pixels on mobile, with space between them. 12. Use header, nav, main and footer, and add a "Skip to main content" link as the first item on every page. 13. Never use colour alone to convey meaning, such as red for errors. Add text as well. 14. Keep the built-in keyboard and screen reader behaviour of the components you use.
A contrast ratio compares the lightness of text with its background, from 1:1 (no difference) to 21:1 (black on white). The 24 by 24 pixel minimum for tap targets is one of the requirements added in WCAG 2.2; 44 by 44 is a stricter, more comfortable size for fingers.
Follow-up prompts to fix specific problems
After a check, ask for one fix at a time: short, focused prompts give more reliable results than one long list. Replace the parts in square brackets with what your report says.
- Buttons without a name: "The report says buttons have no name. Give every icon-only button an accessible name that says what it does, such as 'Open menu'. Do not change how they look."
- Low contrast: "The report says text in [the footer] has too little contrast. Adjust the colours until all text reaches at least 4.5:1, or 3:1 for large text. Stay close to the brand colours and tell me the new values."
- Missing labels: "The report says form fields have no label. Add a visible label above every field in [the contact form], connected to its field."
- Missing alt text: "The report says images have no alt text. List every image on this page and suggest alt text for each. Mark decorative images for an empty alt. Wait for my approval before applying."
- Keyboard access: "I cannot reach [the pricing cards] with the Tab key. Replace clickable divs with real buttons or links so everything works with the keyboard, in a logical order."
- Invisible focus: "When I press Tab, I cannot see where I am. Add a clear focus style to every link, button and field, with at least 3:1 contrast against the background."
- Pop-ups: "The [booking] pop-up does not work with the keyboard. Move focus into it when it opens, keep Tab inside, close it with Escape and return focus to the button that opened it."
- Language and headings: "The report says the page language is missing and headings skip levels. Set the page language to English and fix the heading order without changing how the headings look."
A routine that works: prompt, preview, check, repeat
You do not need to read code to keep your site in good shape. You need a loop you repeat until the important problems are gone.
- Prompt with the instructions. Add the block before you generate, or ask the builder to review an existing project against it.
- Publish a preview. Put the site or a preview on a public web address. A checker cannot reach a page that is only visible inside the builder or behind a login.
- Check it with ibin. The report says what is wrong, who it affects and where it is on the page, with close-up pictures.
- Paste the problems back into the builder. Use the plain-language description or the prompts above. The technical detail under "Code for your developer" can go into the builder too.
- Check again until no problems marked as critical remain, then work through the rest. Then sign in and check up to 200 pages of the same site, because builders repeat the same header, footer and forms everywhere.
- Test with the keyboard and review your own content, as described below.
The 10-minute keyboard test
Automatic checks find many common problems, roughly a third to half of all issues, but not everything. Put your mouse aside and try this on your home page and your most important form.
- Press Tab from the top. Is "Skip to main content" the first thing you reach, and can you always see where you are?
- Keep pressing Tab. Do you reach every link, button and field in an order that follows the page?
- Open and close the menu with Enter and Escape.
- Fill in and send the form with the keyboard alone. Are error messages clear?
- Open a pop-up. Can you close it with Escape and carry on where you were?
- Turn on "reduce motion" in your device's accessibility settings and reload. Do the big animations stop?
- Zoom to 200%. Is all text still readable?
What the AI cannot know
Some things no builder or automatic check can judge, because they depend on your purpose and your audience.
- Whether an image description is right. The AI may write "woman smiling at a laptop", but it cannot know the photo shows your founder, or that the point of a chart is that bookings doubled.
- Whether link texts make sense. Six links saying "Read more" confuse someone who hears a list of links read aloud. "Read more about our yoga classes" works anywhere.
- Whether your copy is clear. Short sentences and familiar words help everyone, including people reading in a second language.
- Whether the steps make sense. A booking flow can pass every automatic test and still be confusing.
The same goes for everything you add after launch: each new image needs alt text, each new link a text that says where it goes. ibin's optional second look from AI rates image descriptions, link texts, keyboard use and clear language from 1 to 5, so you know where to look first. A person still makes the final call, and if you can, ask someone who uses a keyboard or screen reader every day to try your site.
Check your AI-built site
Publish a preview and check a page for free with ibin. Paste the plain-language problems into your builder with the prompts above, check again, and use the repair guides when you want to understand a fix. Once your home page is in good shape, sign in to check up to 200 pages of the same site for free.
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.
