A conference website built with AI had a perfect automated accessibility score. Daniel still had trouble using it. In a May 2026 account published by Axess Lab, Hampus Sethfors described his colleague testing the site with an iPhone screen reader. Menus and a ticket dialog appeared on screen, but focus stayed behind them. The site had been built with Lovable and included third-party integrations.
That gap matters as building a website gets faster. A small business can get something that looks finished before anyone has checked whether its customers can complete a task. If builders keep making components that some people cannot use, they can spread the same barriers across many sites. They should make accessible defaults part of the product, including the tools disabled people use to build websites themselves.
A finished-looking site can still block a task
A menu has more to do than appear. Someone using a screen reader needs to understand that it has opened and be able to reach its options. Someone using a keyboard needs a sensible route through its controls. When a dialog opens, the controls inside it need to receive focus. Otherwise, a person can be left operating the page behind the box that a sighted mouse user sees in front.
The consequences depend on the task. A flaw in a bit of visual flair may be annoying. A flaw in booking an appointment or making a payment can stop the sale. A screenshot cannot show whether either person can finish.
Automated checks are useful. They can catch common errors fast and give developers a place to begin. A perfect score tells us only that the checks being run found no failures. It cannot show that each part of a task works for everyone who needs it.
The web already has a large problem here. WebAIM ran automated checks on one million homepages in February 2026. Those checks found accessibility failures on 95.9% of the pages. The study gives us a baseline for the web as a whole, not a comparison of AI-built and human-built sites. It cannot tell us that AI is making accessibility worse, or assign a failure rate to AI builders.
Builders still have to decide what their software repeats. If a tool repeats familiar errors, faster output can spread those errors across more sites. If it uses well-tested components each time, speed can help spread the fixes. The result depends on what builders make routine.
Small-business owners can struggle to spot the difference in a preview. The page may look professional. Its form may work when they click it. They may have no reason to suspect that a menu works differently with a screen reader. To spot every problem in a new site, owners would need the kind of expert knowledge the product promises to spare them.
Owners will always have work to do, especially as they add content and connect services. But a builder should not leave each customer to learn from scratch how a menu or form needs to work. These needs should be part of the design from the start.
Better prompts need better defaults
In the Axess Lab account, several problems were fixed quickly after expert feedback. Sethfors also praised the feat of building a working website on a phone while commuting. One tested site cannot tell us the quality of a whole product. Its third-party integrations also make it harder to say who caused each failure. The account shows why easy creation and expert review belong together.
In a study published in July 2025, Iyad Abu Doush and Reem Kassem examined eleven web components generated by four models. Their abstract reports that follow-up prompts improved accessibility. The models were given accessibility context, and people took part in judging the results. The finding supports using AI with guidance. It does not show that a full website made without that help will work for all its users.
When a model responds to expert feedback, the product team can use what it learns to improve its prompts before a customer has a failure to report. It can test common patterns, revise the instructions that produce them and check that a later change has not brought a known problem back.
The benefit should reach the owner who does not know the right technical phrase to put in a prompt. Ask for a ticket form, and its controls should be clear and work as intended. Asking for a menu should not require a second lesson in focus management. That is part of what a menu needs to do.
This will take work. Builders need people who understand accessibility, and they need testing that goes beyond looking at generated code. They also need to test how the parts work together. A form that works on its own can still leave a person stuck if the dialog around it fails. Third-party services make the chain longer, but do not make the finished task less important.
W3C urges teams to involve disabled users as they build. Their input helps find problems with using a site that checks against standards alone can miss. W3C also warns that one person cannot speak for every disability or way of using the site. A test that goes well tells us something useful, but cannot prove the site will work for everyone.
Product teams should pay for that expertise and use it as they build. By the time a disabled customer reports a barrier, they have already had to deal with it. Relying on unpaid reports also leaves progress to whoever has the time and patience to explain what went wrong.
For a small site owner, a more useful promise would describe what the builder has tested:
- Which tasks did people try?
- How did they use the site?
- Which version did they test?
- What still needs work?
Those details give the owner more to go on than a broad claim that AI has handled everything. They also give the owner somewhere to start when a later edit changes how the site works.
Disabled people need to create websites too
When people discuss web accessibility, they often speak of disabled people as the users of a website. They are also business owners, designers, writers and volunteers who need to make one. A builder can make a public page people can use while leaving its creator unable to edit or publish it without help.
W3C’s Authoring Tool Accessibility Guidelines cover both needs. The interface people use to build should be accessible, and the tool should help them make accessible output. This distinction came before today’s AI builders and applies to no-code tools too. Even when a person has less code to write, they still need to use the tools to build their site.
A prompt box is only the beginning. People may need to review a change, select a control, revise text, connect a service or undo an edit. If they cannot do those things, they face a limit on easy creation that other customers do not. A person should not need somebody else to complete routine steps for them simply because the product team tested only one way to use its tools.
AI could make some of this work easier. Being able to ask for a change in plain words may save someone a series of hard steps. Good guidance could help a novice understand what an edit will do. These are reasons to give disabled creators a say in how the product works, with enough power to change it.
The work continues after launch. Websites get new content, forms and integrations. Builders need ways to keep useful defaults through those changes and explain when an edit creates a problem. They also need to offer repairs to sites already using a faulty component. A polished first version is a small part of a website’s life.
A faulty menu can appear on many websites, leaving users to meet the same barrier again and again. A tested repair can reach the next site that uses that component. Builders should use their scale to make the repaired version the norm.
