Axess Lab | Lovable’s AI built a 100% accessible site – or did it?

To main content

Lovable’s AI built a 100% accessible site – or did it?

Published 13 May 2026,<br>by Hampus Sethfors

We wanted to get an indication of how accessible AI-built sites are at the moment. So I let my colleague Daniel try out a site built with Lovable, using the screen reader on his iPhone. And we recorded it all so you can come along for the ride!

Background about the site

First off: the way the site was built was pretty mind blowing to me.

A friend of mine, an AI-enthusiast, built it only using his smartphone during bus rides to and from work. The fact that you can now build a functional, high-fidelity site into existence while commuting is pretty cool. And you could argue that this is a form of accessibility, making it possible for many more people to build sites and apps.

But yeah, in brief, the site was for a dev conference. It included information about speakers, dates, venue and that sort of stuff. It also included a way secure your tickets and pay for them. So not a super complex site, but still not just a basic one-way info site.

It was built with Lovable and has some third party integrations, for instance in the checkout flow. Accessibility had been prompted to be a priority, but no more detailed requirements regarding that was given.

On paper the site was perfect. It got a 100% accessibility score in Lovable’s Speed tool, that runs Axe. By the way: great to see that Lovable has an accessibility tool like this built in!

But how did it work in real life, for an actual assistive tech user? I’ll give a hint: it wasn’t 100%…

The issues

Getting stuck behind components

Let’s look at some of the issues, and I’ll begin with the most critical ones.

One of the most frustrating experiences for a screen reader user is when the visual layer and the code layer lose sync. When the menu was open, the screen reader kept reading content underneath it.

Check out the video if you can, but I’ll summarise it (and others videos later on) after the clip if you for some reason can’t want to watch it.

Basically, the video shows the menu being open, but the screen reader focusing on some object behind the meny. Which obviously causes confusion:

I thought I was in the menu, but it announced the thing I read before from the start page… probably underneath the menu, right? So that was weird!

This "ghosting" effect happened again with the ticket modal.

Here’s the clip on Youtube, for some reason I can’t embed it here in the article:

Buying ticket using VoiceOver on AI-built site (Youtube)

Here Daniel initally uses swipe navigation, where swiping right moves to the next item. It’s a common way of navigating when you’re in new interfaces, or for less tech savvy users. Using swipe navigation, he gets stuck behind the modal.

However, he manages to force focus into the modal when he switches to navigating by touch. Basically dragging his finger across the screen and having what’s underneath his finger read to him.

Far from everyone will figure out that they need to switch ways of navigating, and like Daniel mentions at the end, some users will have keyboards or braille displays connected and not use navigation by touch at all.

Hush! Stop screaming!

Automated security features together with a strange hidden region also caused a bit of chaos. This was the experience every time a new page opened:

So here we had two issues.

One was that there was a strange, hidden region at the top of the page saying "Notification alt+t".

However, the most frustrating one was that the screen reader began automatically announcing "Cloudflare integrity" and "Verify if you are a human" repeatedly.

For a user trying to get an overview of a site, having a security bot interrupt your flow is the digital equivalent of a megaphone going off in a library.

This is a great example of the issues you can run into if you follow guidelines, but don’t test for the actual experience. The Cloudflare component does update its content, and then having it in a live-region is the general rule of thumb. However, in this specific case it hurts the screen reader experience tremendously, as you probably noted in the video.

Lost in the single-page application (SPA)

Because the site was built as an SPA, "navigating" to a new page didn’t actually trigger a traditional page load. When that’s the case, focus needs to be controlled so it lands in the proper place when new pages load. However, on this site, screen reader focus wasn’t handled well:

Focus was never managed… my screen reader tried to figure out what happened there so it put focus in that visual area where I pressed the link.

The result? Daniel landed on a heading halfway down the page, missing all the content above it.

When "Toggle Menu" tells you nothing

The first thing Daniel reacted to was the menu button. The button was labelled “Toggle menu”, so it wasn’t unlabelled (a common issue). So that’s good!

But...