Ontario businesses & non-profits: the AODA reporting deadline is December 31, 2026. Check what applies to you
AI-built products

Built it with Lovable, Bolt, or v0? It probably fails the basics. That is fixable.

AI site builders ship visually finished products with missing labels, broken keyboard access, and low contrast by default. I test the real thing and fix it, in the code or in prompts you can paste back.

Fit

Who this is for, and who it is not for

For

  • Founders and small teams with a live AI-built site or app and no developer
  • Agencies and freelancers delivering AI-built sites to clients

Not for

  • Teams that just want a score
Triggers

What starts this work

A customer said they could not use itSomeone using a screen reader or a keyboard got stuck, and you have no way to see what they saw.
A bigger customer asked for a VPAT or an accessibility statementThe deal is real, the document is required, and the builder cannot produce one.
A demand letter arrivedThe site is live, the letter names it, and there is no developer to hand it to.
You are about to launch and a friend told you to checkYou want to know what is wrong before a customer or a lawyer tells you.
Deliverables

What I do

The deliverable is the fix, not a report you cannot act on.

  • Manual test of the live product with keyboard and screen reader, not just a scanner
  • Findings written two ways: as code changes, and as prompts written for your builder tool so you can apply them yourself
  • Direct fixes in the exported codebase where you have one
  • Re-test after changes
  • A short accessibility statement for the site
What the builders get wrong

The failures are consistent, and they do not depend on your prompt.

Independent tests of sites built on AI builders find the same profile every time: form fields without labels, buttons with no accessible name, focus that disappears or lands in the wrong place, contrast below the minimum, and page structure that reads as one long block to a screen reader. The critical failures show up whether the prompt was one line or a page.

The tools are improving, and some now ship accessibility linting. The gap is in interaction patterns, focus management, and forms, which linting does not catch. Those are found by using the product with a keyboard and a screen reader, which is what the review does.

If the site is already named in a letter, see what counsel will need from a technical reviewer.

Why a named practitioner

One person scopes it, tests it, and fixes it.

  • Named practitionerThe person who scopes it does the work
  • Manual + assistive techKeyboard and screen-reader testing
  • Fixes, not just findingsRemediation from the same person
FAQ

Questions asked before scoping

Do I need a developer?

No. Every finding comes with a prompt you can paste into your builder, and with the code change for anyone who has the exported project. If you have neither, I make the changes in the exported codebase and hand it back.

Can you just give me prompts?

Yes. Prompts are written per finding and per tool, so they name the component, the change, and how to check it worked. You apply them in your own session and I re-test the result.

Which builders have you worked with?

Placeholder (VERIFY with practitioner): list only the builders actually tested, for example Lovable, Bolt, v0, or Replit.

Will the fixes survive the next regeneration?

Not always. A regeneration can rewrite a component and drop the fix. The protection is to keep the fixed components in your project instructions or system prompt, to re-run a short check after each regeneration, and to export the code once the product is stable.

How long does this take?

A typical product with five to fifteen screens is tested within five business days of access. Fixes and re-test depend on whether you apply the prompts yourself or I work in the exported code.

Next step

Send the live URL and the builder you used.

A short call confirms whether you have the exported code, who applies the changes, and what the first deliverable should be.