Bolt, made by StackBlitz, builds websites and apps from a chat conversation at bolt.new. It writes the code, installs what it needs and shows a live preview next to the chat within minutes. Like every AI builder, it follows your request closely: when accessibility is not part of it, the result can look finished while being hard to use with a keyboard or a screen reader (software that reads the screen aloud). This guide shows what Bolt generates, which problems to watch for, where to put instructions so Bolt follows them in every change, and how to publish and check the result.
What Bolt builds
When you do not ask for anything specific, Bolt usually starts a project with React (a widely used way to build web pages), Vite and TypeScript, styled with Tailwind CSS and with icons from the Lucide icon set. You can also ask for other frameworks, such as Next.js, Astro, Vue or Svelte. When your project needs a database or logins, Bolt Cloud provides them on Supabase without a separate account.
Bolt runs your project inside your own browser, using a StackBlitz technique called WebContainers. That is why the preview appears so quickly. It also means that the preview in the editor exists only on your computer, which matters when you want to check it (see below).
Problems that often appear
These patterns come up regularly in generated sites. They are not faults in every Bolt project, and clear instructions prevent most of them.
- Hand-built menus and pop-ups. Bolt’s default setup keeps extra packages to a minimum, so menus, dropdowns and dialogs are often written from scratch instead of taken from a tested component library. Hand-built versions often miss keyboard support: Escape does not close them, or Tab moves behind an open dialog.
- Buttons that are only an icon. Menu, close, search and social buttons with a Lucide icon and no name. A screen reader announces just “button”.
- Stock photos with vague descriptions. Bolt often links to free stock photos to fill a page. Their alt text, the description a screen reader reads instead of the image, is often missing or generic, such as “hero image”.
- Text on gradients and photos. Large hero sections with white text over a light photo or a bright gradient often fall below the minimum contrast.
- Clickable cards and boxes. A card 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, and form errors shown only in red, without text that explains what to fix.
Where to put permanent instructions
Bolt calls its standing instructions Knowledge. They are sent along with your requests, so you write your accessibility rules once.
- Project knowledge applies to one project. Click the gear icon at the top centre of the screen, choose All project settings and then Knowledge in the menu on the left. Bolt’s documentation describes this path.
- Knowledge in your personal settings applies to all your projects. Put rules there that you want everywhere, such as your accessibility block, and keep project knowledge for brand colours and content.
Older projects may still show a “project prompt” or a file called .bolt/prompt. It does the same job: add the block there if that is what your project has. Menu names change from time to time, so look for “Knowledge” if the path above has moved.
Before a big change, you can use Plan mode to ask Bolt to review your project against the rules without changing code yet.
Instructions for Bolt
Paste this into project knowledge or the knowledge in your personal settings. Replace the language if your site is not in English.
Accessibility rules for every change (aim for WCAG 2.2 level AA): - Use semantic HTML: header, nav, main, footer, real <button> for actions and real <a> for links. Never put onClick on a div, span or card. If a whole card is clickable, put a real link inside it. - Menus, dropdowns, tabs and dialogs must work with the keyboard: Tab, Enter, Space, arrow keys where expected, Escape to close. Dialogs move focus inside, keep it there and return it on close. Use a tested accessible component library for these if building them by hand is unreliable. - Every icon-only button or link (Lucide icons) has an aria-label in the site language, such as "Open menu". The icon itself is aria-hidden. - Every image gets alt text that describes its purpose on this page, never "image" or a file name. Decorative images get alt="". List stock photos for me to review. - Text contrast is at least 4.5:1, large text 3:1. Text over photos or gradients gets a solid or darkened background. - Every form field has a visible label. Errors appear as text next to the field, not only in colour. - Keep a clearly visible focus style on every interactive element. - Set lang="en" on the html element and give every page a unique title. One h1 per page, headings in order. - 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.
- Menus and dialogs: “The [mobile menu] does not work with the keyboard. Make it open and close with Enter and Escape, move focus into it when it opens and back to the menu button when it closes.”
- Icon buttons: “Give every icon-only button in [the header] a clear name in English that says what it does. Do not change how they look.”
- Stock photos: “List every image on [the home page] with its current alt text. Suggest a description that fits its purpose on this page, and wait for my approval.”
- Text on images: “The white text in [the hero section] has too little contrast. Add a dark overlay or solid background behind it until it reaches at least 4.5:1.”
- Clickable cards: “I cannot reach [the service cards] with the Tab key. Replace the click handler on the card with a real link around the title.”
Publish and check
The preview in the Bolt editor runs in your own browser, so ibin cannot reach it. You need a public address first.
- Publish. Click Publish at the top right. Bolt hosts the site for you on an address ending in bolt.host. You can also connect Netlify if you prefer to host there.
- Check the page with ibin. Start with the home page, then your most important form.
- Paste the fix into Bolt. Each problem in the report has a “Copy instructions for an AI tool” button. Paste the result into the Bolt chat. It asks for a fix in the site itself.
- Publish again and check again. Changes reach the public address only 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. For hand-built menus and pop-ups, it matters more than any report.
What Bolt cannot judge
Bolt can add a description to a stock photo, but it cannot know whether that photo belongs on your page at all, or what it should tell a visitor. It cannot tell whether “Learn more” makes sense when a screen reader lists all the 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 image descriptions and link texts.
Check your Bolt site
Publish your project and check a page for free with ibin. Copy the instructions for each problem into Bolt, 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.