Lovable turns a chat conversation into a working website or app. It writes solid, modern code, but it builds what you ask for: if accessibility is not part of the request, a few problems come back in project after project. This guide shows what Lovable generates, which problems to watch for, where to put instructions so Lovable follows them in every change, and how to check the result.
What Lovable builds
Lovable writes React (a widely used way to build web pages) in TypeScript, styled with Tailwind CSS. Since 13 May 2026, new projects are built on TanStack Start, a React framework that prepares pages on the server so they load faster and are easier for search engines to read. Older projects are usually single-page apps built with Vite. For data, logins and file storage, Lovable uses Supabase, directly or through Lovable Cloud.
Most interface parts come from shadcn/ui, a collection of ready-made components built on Radix. Menus, dialogs, tabs and dropdowns from that collection come with keyboard support and the right information for screen readers (software that reads the screen aloud). That is a good start, but it only helps where Lovable actually uses those components and keeps their behaviour intact.
Problems that often appear
These patterns come up regularly in generated sites. They are not faults in every Lovable project, and clear instructions prevent most of them.
- Buttons that are only an icon. Lovable uses an icon set called Lucide for menus, close crosses, search, social links and “add to cart”. Without a name in the code, a screen reader announces just “button”.
- Error messages that only appear as a toast. A toast is the small message that slides into a corner and disappears after a few seconds. When a form error only shows there, people miss it, and nothing next to the field says what to fix.
- Muted text with too little contrast. The default theme has a soft grey for secondary text. On white, and especially on light grey cards, it often falls below the minimum contrast.
- A missing or wrong page language. The page language tells a screen reader which pronunciation to use. A site in Dutch or French that still says “English” is read aloud with the wrong accent.
- Clickable cards and boxes. A product card or pricing box that reacts to a mouse click but is not a real link or button cannot be reached with the Tab key.
- Fields with only a placeholder. The grey hint text inside a field disappears as soon as you type.
Where to put permanent instructions
Lovable calls its standing instructions Knowledge. It sends them along with every request, so you write your accessibility rules once.
- Project knowledge applies to one project. Open the project settings by clicking the project name in the top bar and choosing Settings, or press Ctrl+. (Cmd+. on a Mac), then go to the Knowledge section. Lovable’s documentation describes this path.
- Workspace knowledge applies to every project in your workspace. If you build several sites, put the accessibility rules there, and keep project knowledge for things like brand colours and content.
Keep knowledge short, with bullet points. Menu names change from time to time, so look for “Knowledge” if the path above has moved.
Lovable also has skills, reusable playbooks you start by typing a slash in the chat. One of the built-in skills is /accessibility, which reviews and fixes common accessibility problems. It is useful for a review round, but it is not a replacement for knowledge: a skill runs when you call it, knowledge counts in every change.
Instructions for Lovable
Paste this into project or workspace knowledge. Replace the language if your site is not in English.
Accessibility rules for every change (aim for WCAG 2.2 level AA): - Use semantic elements: header, nav, main, footer, real <button> for actions and real <a> or router Link for navigation. Never put onClick on a div, span or Card. If a whole card is clickable, put a real link inside it. - Every icon-only Button (Lucide icons) gets an aria-label in the site language, such as "Open menu". Mark the icon itself aria-hidden. - Every Input, Select and Textarea has a visible Label linked to it. Placeholders are never the only label. - Form errors appear as text next to the field and are linked to it. Never show an error only in a toast. - Text contrast is at least 4.5:1, large text 3:1. Check text-muted-foreground on every background, including cards and dark mode, and darken it where needed. - Keep the visible focus ring on all interactive elements. Never remove it. - Set lang="en" on the html element and give every page a unique title. - One h1 per page, headings in order. Do not choose heading levels for their size. - Keep the keyboard behaviour of shadcn/ui and Radix components. Dialogs close with Escape and return focus. - Meaningful images need alt text that describes their purpose; decorative images get alt="". - Respect prefers-reduced-motion for animations.
Follow-up prompts for common problems
After a check, ask for one fix at a time. Replace the parts in square brackets.
- Icon buttons: “Give every icon-only button in [the header and footer] a clear name in English that says what it does. Do not change how they look.”
- Toast-only errors: “In [the contact form], show each error as text below the field it belongs to, linked to that field. Keep the toast only as an extra.”
- Muted text: “The grey secondary text has too little contrast on [the pricing cards]. Darken the muted text colour until it reaches at least 4.5:1 on every background where it is used, in light and dark mode.”
- Page language: “Set the page language to [Dutch, nl] on every page.”
- Clickable cards: “I cannot reach [the project cards] with the Tab key. Replace the click handler on the card with a real link around the title, so the card works with a keyboard.”
You can also run /accessibility after a larger change and then check the page again with ibin.
Publish and check
ibin checks pages on the public web, so it needs an address anyone can open.
- Publish. Click Publish at the top right of the editor. Lovable suggests an address ending in lovable.app, which you can change. Share preview links are meant for showing work to a person and expire after seven days, so use the published address for checks.
- Make sure the site is public. On some plans you can limit who may visit the published site to your workspace. A checker cannot sign in, so choose Public while you check.
- Check the page with ibin. Start with the home page, then your most important form.
- Paste the fix into Lovable. Each problem in the report has a “Copy instructions for an AI tool” button. Paste the result into the Lovable chat. It asks for a fix in the site itself.
- Publish again and check again. Changes only reach the public address after you publish.
- Check more pages. Sign in to check up to 200 pages of the same site, and turn on weekly checks to catch problems that come back.
Automatic checks find roughly a third to half of all problems, so also do the 10-minute keyboard test.
What Lovable cannot judge
Some things depend on knowledge that only you have. Lovable may describe a photo as “team working in an office”, but it cannot know that it shows your three founders. It cannot tell whether “Learn more” makes sense when a screen reader lists all links on a page, or whether your text is easy to read. Review image descriptions and link texts yourself every time you add content. ibin’s optional second look from AI rates these on a scale from 1 to 5, so you know where to start, but a person makes the final call.
For the general approach that works in every tool, see the overview for AI builders. The repair guides explain each problem in plain language, for example buttons without a name and colour contrast.
Check your Lovable site
Publish your project and check a page for free with ibin. Copy the instructions for each problem into Lovable, publish again 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.