v0 is Vercel’s AI builder: you describe a page or an app in a chat, and it writes the code, shows a live preview and publishes the result. The code is modern and tidy, but v0 builds what you ask for. If accessibility is not part of the request, the same few problems keep coming back. This guide shows what to watch for, how to give v0 standing instructions, and how to check the published site.
What v0 builds
According to v0’s own FAQ, v0 uses Next.js, React, TypeScript, Tailwind CSS and shadcn/ui. React is a widely used way to build web pages, Next.js prepares those pages on the server, and Tailwind CSS styles them with short class names. shadcn/ui is a collection of ready-made interface parts, such as menus, dialogs and tabs, built on a library called Radix.
That last part is good news: shadcn/ui dialogs, dropdowns and tabs come with keyboard support and the right information for screen readers (software that reads the screen aloud). But anything v0 builds from scratch, such as a custom card grid or an animated banner, depends on your instructions.
Problems that often appear
These patterns come up regularly. Clear instructions prevent most of them.
- Icon-only buttons without a name. Generated designs often use small icon buttons for menus, search, close and social links. Without a name in the code, a screen reader announces only “button”.
- Soft grey text with too little contrast. The default theme uses a muted grey for secondary text. On white or light grey cards it often falls below the minimum contrast.
- The wrong page language. The main layout file sets the language once, usually to English. A Dutch, French or German site that still says English is read aloud with the wrong pronunciation.
- The same title on every page. The page title appears in the browser tab and is the first thing a screen reader reads. Unless you ask, pages often share one generic title.
- Clickable cards. A pricing or product card that reacts to a mouse click but is not a real link or button cannot be reached with the Tab key.
- Lots of motion. Fade-ins and sliding sections look polished, but can make some people dizzy.
- Generic image descriptions. When you swap a placeholder for a real photo, the description (alt text) often stays generic.
Where to put permanent instructions
v0 calls its standing instructions Instructions. They are saved to your account and can be switched on for any chat. v0’s documentation describes how to create one:
- Click the + button in the prompt bar.
- Under Instructions, choose New Instruction.
- Give it a Title, such as “Accessibility”, and paste the block below into Rule.
- Click Add.
To use it, click + again and tick the instruction. A ticked instruction is applied to every message until you untick it, so check that it is still ticked when you start a new chat. Menus in v0 change regularly; look for “Instructions” if the steps above have moved. For a larger clean-up, also tick the built-in Plan Mode instruction: v0 then explains its plan and waits for your approval.
Instructions for v0
Paste this into a new instruction. Change the language code 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. Use next/link Link for navigation and Button for actions. 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 (size="icon", lucide-react icons) gets an aria-label in the site language, such as "Open menu". Mark the icon aria-hidden. - Every Input, Select and Textarea has a visible Label connected with htmlFor. A placeholder is never the only label. Form errors appear as text next to the field, not only in a toast. - Text contrast is at least 4.5:1, large text and icons 3:1. Check text-muted-foreground on every background, including cards, gradients and dark mode. - Keep the visible focus ring (focus-visible classes) on all interactive elements. - In app/layout.tsx set <html lang="en">. Give every page its own title with the metadata export. - One h1 per page, headings in order. Do not pick heading levels for their size. - Keep the keyboard behaviour of shadcn/ui and Radix components. Dialogs close with Escape and return focus to the button that opened them. - Every next/image has alt text that describes its purpose; decorative images get alt="". - Wrap animations in motion-safe: or check prefers-reduced-motion. No auto-playing carousels without a pause button. - Add a "Skip to main content" link as the first item on every page.
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.”
- Contrast: “The grey secondary text has too little contrast on [the pricing cards]. Darken the muted text colour in the theme until it reaches at least 4.5:1 on every background where it is used, in light and dark mode. Tell me the new values.”
- Language and titles: “Set the page language to [German, de] in the root layout and give every page its own descriptive title.”
- Clickable cards: “I cannot reach [the project cards] with the Tab key. Remove the click handler from the card and put a real link on the title, so the card works with a keyboard.”
- Motion: “Turn off the [hero and scroll] animations when the visitor has asked their device to reduce motion.”
If you change colours in v0’s visual Design mode, check contrast again afterwards.
Publish and check
ibin checks pages on the public web, so it needs an address anyone can open. v0 publishes to Vercel.
- Publish. Select Publish in the chat header. The first time, v0 asks for a project name, who may see the site and a domain. The default address ends in vercel.app.
- Make sure the address is public. In the publish flow, choose a visibility that lets anyone open the site. Vercel can also protect preview addresses so that only signed-in team members see them; it calls this Deployment Protection. A checker cannot sign in, so check the public production address, or a preview address without protection.
- Check the page with ibin. Start with the home page, then your most important form.
- Paste the fix into v0. Each problem in the report has a “Copy instructions for an AI tool” button. Paste the result into the v0 chat; it asks for a fix in the site itself.
- Publish the changes and check again. Open Publish and choose Publish Changes. 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 after later edits.
Automatic checks find roughly a third to half of all problems. Also do the 10-minute keyboard test: put the mouse aside and use the Tab key to go through the menu, open and close a dialog and send your form.
What v0 cannot judge
v0 may describe a photo as “person working on a laptop”, but it cannot know that it shows your head of support. It cannot tell whether three links called “Learn more” make sense when a screen reader lists all links on a page, or whether your text is easy to follow in a second language. Review image descriptions and link texts yourself whenever 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.
See also the overview for AI builders and the repair guides, for example on buttons without a name and colour contrast.
Check your v0 site
Publish your project and check a page for free with ibin. Copy the instructions for each problem into v0, publish the changes 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.