OxyPages

The AI Website Accessibility Fixes That Take An Hour

The AI Website Accessibility Fixes That Take An Hour

Your AI website accessibility gaps are likely the same six errors found across most of the web. Here's how to spot all six and fix them in about an hour.

The OxyPages Team · · 9 min read

Your clinic's new page came out of Lovable looking calm and expensive. Soft teal, pale grey text, a smooth fade as each section slides in, a neat little grid of opening hours.

Then a patient rings to say she couldn't read the hours. She's in her seventies, and the pale grey on white just wasn't there for her.

Pale text is the most common accessibility problem on the web, and it's probably not the only one on your page.

Your AI website accessibility problems are almost certainly the same handful of errors that turn up on nearly every site. They're predictable, so you can find them in minutes with a keyboard and fix most of them in about an hour, without hiring a specialist.

This post walks through those errors on an example: a dental clinic's opening-hours page built in Lovable. Then it shows how to check your own page with nothing but a keyboard. If you're earlier in the process, the realistic guide to building a website with AI is the place to start.

TL;DR: WebAIM's 2026 scan of a million home pages found detectable accessibility failures on 95.9% of them, and 96% of all errors fell into six types: low contrast text, missing alt text, form fields without labels, empty links, empty buttons, and a missing page language. AI-built pages tend to fail the same ways. Tab through the page first, then fix those six, write opening hours as a real table in full words, and make the phone number a tap-to-call link.

Why Do AI-Built Pages Fail Accessibility Checks?

Because the model is judged on how the page looks, and most accessibility lives in the parts you can't see. A pale grey on white looks elegant in a preview. An icon with no label looks clean. Neither shows up as a problem until somebody uses the page differently from you.

The whole web has the same problem. WebAIM checks the home pages of the top million websites every year, and the 2026 report found 56.1 detected errors per page on average. The WebAIM Million 2026 accessibility report

What helps you is that 96% of those errors are just six kinds.

Lovable has one advantage here. Its pages usually build menus, dialogs and tabs from ready-made components that sit on a library called Radix, which has keyboard support built in. What Radix can't do is name things for you. Its own docs say providing labels is up to the developer, and on an AI-built page, that developer was the model.

The Six Errors, And What They Look Like On A Clinic Page

Six errors make up 96% of what WebAIM finds, and on a clinic page they look like this.

Error (share of home pages)On a typical clinic pageThe fixRoughly
Low contrast text (83.9%)Pale grey body text, white text on light teal buttonsDarken the text until it passes 4.5:110 minutes
Missing alt text (53.1%)The surgery photo and the team photo, described by nothingWrite one plain sentence for each10 minutes
Form fields without labels (51%)A booking form where "Your name" is grey text inside the boxA visible label above each field10 minutes
Empty links (46.3%)Facebook and Instagram icons, a map pin iconAdd a text label to each icon link5 minutes
Empty buttons (30.6%)The menu button on a phone, a close button with only an XAdd a label to each icon button5 minutes
Missing page language (13.5%)No lang on the html taglang="en" or your local variant1 minute

About 40 minutes for all six. The rest of the hour goes on opening hours and testing.

Quick Fixes For Your AI Website Accessibility

Each one below is a single prompt in the Lovable chat, or a single edit if you're working in the code. Ask for one fix at a time and check the preview after each.

Contrast

Normal text needs a contrast ratio of at least 4.5:1 against its background, and large text needs 3:1. That's level AA of WCAG, the web's accessibility guidelines, and it's the level most accessibility rules ask for. W3C's explanation of the WCAG contrast minimum Large text means roughly 24px, or 19px bold.

Paste your text and background colours into a free colour contrast checker and it tells you pass or fail in a second. Then give the model the exact numbers: "Change the body text colour to #374151 everywhere." Vague prompts like "make the text more readable" get you a redesign.

Alt Text

Every meaningful image gets one plain sentence saying what's in it. "Dr Patel with a patient in the treatment room" is good alt text. "Image" or "dental-clinic-hero.jpg" is not.

Decorative images, like a wave shape, get an empty alt="" so screen readers skip them. If your photos are still placeholders, replacing the images on an AI-built page with your own covers that first.

Labels On Form Fields

Placeholder text inside a box is not a label. It vanishes the moment someone starts typing, and many screen readers don't announce it reliably. Ask for "a visible label above every form field, connected to its input."

<label for="phone">Phone number</label>
<input id="phone" name="phone" type="tel" autocomplete="tel">

An icon on its own has no name. A screen reader announces the Instagram icon as "link" and the menu icon as "button", and the user has no idea where either goes.

The fix is a hidden text label. Ask for "an accessible label on every icon-only link and button, saying what it does."

<a href="https://instagram.com/yourclinic" aria-label="Our Instagram">...</a>
<button aria-label="Open menu">...</button>

Focus Outlines And Fake Buttons

If you can't see where you are when you press Tab, the styling has removed the focus outline. Ask for "a visible focus outline on every link, button and form field."

Anything you can click that Tab skips over is a fake button: a box made to act like one. Ask for it to be rebuilt as a real button.

The Page Language

One attribute on the opening html tag tells a screen reader which voice and pronunciation to use. Without it, a reader set to another language may read your English page with the wrong accent. One minute, and it's done for good.

Opening Hours Are Where Clinic Pages Go Wrong

Opening Hours Are Where Clinic Pages Go Wrong - OxyPages

Write them as a real table in full words, with a tap-to-call phone number underneath. That's the whole answer, and it's the part of a clinic page patients use most.

AI tools love a neat grid of boxes for hours. It looks tidy, but to a screen reader it's a run of disconnected fragments: "Mon. 8-5. Tue. 8-5. Sat. 9-1." Abbreviations and dashes get read out inconsistently, and "8-5" can come out as "eight minus five".

Here's the shape that works for everyone:

<table>
  <caption>Opening hours</caption>
  <tr><th scope="row">Monday to Friday</th><td>8am to 5pm</td></tr>
  <tr><th scope="row">Saturday</th><td>9am to 1pm</td></tr>
  <tr><th scope="row">Sunday</th><td>Closed</td></tr>
</table>
<p>Call us: <a href="tel:+441234567890">01234 567890</a></p>

Two details matter more than they look.

  • A real phone link. On a phone, tapping it dials. For anyone who struggles with small text, that's the whole page.
  • Emergency information as text, not inside a banner image. "Out of hours, call 111" has to be readable by everyone, every time.

Walkthrough: A Dental Clinic Page Built With Lovable

Here's the hour worked through on an example clinic page from the top of this post: a hero, three services, a team section, the hours grid and a booking form, all generated in Lovable.

  1. Run the keyboard test first. On a page like this, the focus outline often vanishes on the booking button because the styling removed it. Note it.
  2. Check the colours. Light grey body text often lands below 3:1 against white, and white on light teal buttons lower still. Both fail.
  3. Ask for one fix per message in the Lovable chat: exact text colour, darker button teal, a visible focus outline on every link and button.
  4. Rewrite the hours as the table above, with the phone number as a call link, using one prompt with the exact hours pasted in.
  5. Label the icons. Social icons, the map pin and the mobile menu button.
  6. Fix the form. Turn placeholders into visible labels, and make the error message say which field is wrong instead of just turning the box red.
  7. Turn down the motion. If every section fades in on scroll, ask for the animations to respect the reduced-motion setting, so people who switch motion off on their device don't get them.

Every fix here is a short chat message, so there's no reason to leave Lovable for it. If one ever isn't, and you end up in the code yourself, how to edit AI-generated code without breaking it is worth reading first.

How Do You Test Accessibility Without A Specialist?

How Do You Test Accessibility Without A Specialist? - OxyPages

With your keyboard, your browser's zoom, and twenty minutes.

Run these four checks, in this order.

  1. The keyboard test. Click the address bar, then press Tab repeatedly. You should see where you are at every step and reach every link, button and form field. Then press Enter on the booking button.
  2. The zoom test. Zoom the browser to 200%. Nothing should overlap or disappear, and you shouldn't need to scroll sideways to read a sentence.
  3. An automated scan. In Chrome, right-click the page, choose Inspect, then open the Lighthouse tab for an accessibility check. It finds missing labels and contrast failures in seconds.
  4. A screen reader, briefly. VoiceOver is built into every Mac and iPhone, and NVDA is free on Windows. Listen to your hours table once.

For a longer list you can work through by hand, W3C's Easy Checks, a first review of web accessibility is the best free starting point I know.

What To Do Next

Start with the keyboard test, today, before you change anything. It finds the worst problems in two minutes.

  1. Tab through the page and note anything you can't reach or can't see.
  2. Check your text colours and fix anything under 4.5:1.
  3. Add alt text, form labels, icon labels and the page language.
  4. Rewrite your opening hours as a table in full words, with a tap-to-call number.
  5. Run Lighthouse and fix what it flags.

Wherever the page ends up, the fixes travel with it. If you're on Lovable, its own Publish button is the simplest way to put the page online. Hosts that build from a repository, like Netlify or Cloudflare Pages, will build the project for you. Check which kind of Lovable project you have before you move it: Lovable says new projects since May 2026 render on a server, so they need a host that runs code, while older React and Vite projects build into a plain folder of files.

A static host like OxyPages serves your files exactly as you upload them, so it can't make a page accessible for you, and it can't run a server-rendered app. If you have the finished folder a build produces, upload the built folder and get a live link. A clinic site is commercial, so it needs a paid plan, but you can build and test it on a free account first, then upgrade before you share it.

For a small clinic, that's the whole job. Book the hour this week.

FAQ

Are Lovable Websites Accessible By Default?

Partly. Its interactive components come from Radix, which handles keyboard behaviour and focus well. The gaps are in what the model writes around them: colours, alt text, labels on icons and form fields. Those are the same gaps WebAIM finds on most of the web, and each is a short chat prompt to fix.

It depends on where you are and what you offer, and the rules have been tightening in several countries. I'm not a lawyer, so check what applies to you locally. For a clinic, the better reason is simpler: some of your patients have low vision or use a screen reader, and they need your hours too.

Will An Accessibility Checker Find Every Problem?

No. Automated tools reliably catch contrast failures, missing alt text and missing labels, but they can't judge whether alt text is accurate or whether the page makes sense with a keyboard. Pair a scan with the keyboard test and a short screen reader check.

Does An Accessibility Widget Fix This For Me?

No. A widget that adds a toolbar to your page doesn't change the code underneath, so the missing labels and alt text are still missing for anyone using a screen reader. Fix the six errors in the page itself.

Try It Now

Still Here? Drop It In.

The whole pitch fits in one sentence: your HTML, on a link, in seconds.

Drag and drop your HTML files, a folder, a ZIP, your app's build folder, a PDF or an image

or ·

No account needed. Your unclaimed website stays live for 30 minutes on a free subdomain. Claim it to your account to keep it permanently.

  • No Account Needed
  • Free SSL
  • 30-Minute Unclaimed Link, Claim To Keep It