Accessibility Checks AI Site Builders Miss

AI website builders are good at producing pages that look fine. They are less good at producing pages that work for someone using a keyboard, a screen reader, a high-contrast theme, voice control, or simply a browser they did not test on.

Most of the failures are not exotic. They are the same ten or so issues that shipped on hand-built sites a decade ago, repeated faster because the toolset has the same defaults as everyone else's toolset.

This is a Design Notes piece, not a WCAG essay. The intent is a small list of checks any team can run on an AI-generated page in about half an hour, before deciding whether the site is good enough to be the front door of a real business.

AI-built pages still need human checks

More small businesses are publishing pages that came out of a builder, a model demo, or a generated component library. The drafts look polished, use the same hero and the same three cards, and the accessibility problems are not visible in the screenshot, so they tend to ship.

The AI tools that read the web for users (search, shopping, summarisation) lean on the same things screen readers lean on: real headings, real labels, real link text, real alt copy. When a page is opaque to a screen reader, it is also harder for the assistant deciding whether to cite or recommend you.

Accessibility used to be sold as a legal-risk box to tick. In 2026 it is also a practical question of whether anyone, human or AI, can actually parse the page.

The ten-minute keyboard pass

Press tab from the top of the page. Keep going. You are looking for four things.

Can you see where you are? A visible focus ring, on every element you can reach, in a colour that contrasts with the background. Many generated pages strip the focus ring as part of a "clean look" pass and never put it back.

Is the order sensible? Tab order should follow the visual reading order. If tabbing from the hero jumps you into a footer modal, then back into the navigation, then into a card three sections down, the page is using positioned layouts without thinking about source order.

Can you actually use everything? Buttons styled as divs, dropdowns built from animated list items, modals that trap nothing, cookie banners that cannot be dismissed without a mouse. If a control needs Enter or Space to activate it and nothing happens, it is not a button. It is a picture of a button.

Can you escape? Modals, menus, and overlays should close with Escape and return focus to where you were. Generated pages frequently get the open right and the close wrong.

Ten minutes of tabbing finds most of this without any tools.

Check headings and page landmarks

View the page with a quick headings outline (any browser extension, or a screen reader's heading list).

You should see one h1 that says what the page is about, then h2s that match the visible section labels in order, then h3s underneath where they belong. No skipped levels, no decorative h4 hiding above an h2, no second h1 from a generated promotional band.

You should also see real landmarks: a header, a main, a nav, a footer. Generated pages often render everything as a stack of div sections with classes, which leaves a screen reader user with no way to jump between regions.

If the heading outline reads like a sensible table of contents for the page, you are probably fine. If it reads like a random list, the markup needs work before the page is doing anything for assistive tech, search, or AI parsing.

Generated forms often fail quietly

Forms are where the most embarrassing accessibility failures hide.

Every input needs a real label, attached to it, not just placeholder text that disappears when you start typing. The label needs to make sense on its own (a screen reader user hears the label without seeing the surrounding section).

Required fields need to say so in the label, not only in colour or with an asterisk.

Errors need to appear next to the field, in text, with the input marked invalid, and with focus moved to the first error so the user can find it. A red outline alone is invisible to anyone who is not looking at it.

Generated forms often have a placeholder, no label, a tooltip-style error that vanishes, and a submit button that says "Submit" rather than what is being submitted. All four are easy to fix. None are fixed by default.

Contrast, motion, and the high-zoom test

Run a contrast checker on the body text, link text, button text, placeholder text, and any pale grey "secondary" copy. WCAG 2.1 AA wants 4.5:1 for body text and 3:1 for large text. Generated themes love a pale grey on white that fails both.

Look for motion that runs without consent: parallax scrolling, animated backgrounds, video heroes that autoplay with sound, marquee strips. These should respect the user's reduced-motion setting. If your site shakes when a vestibular-sensitive visitor lands on it, motion is not "polish".

Zoom the page to 200 per cent in a desktop browser. Is the content still usable? Or does the navigation collapse into something you cannot reach, do columns overlap, do controls disappear off-screen? AI-generated pages often look great at the design viewport and fall apart the moment a real user scales the text up.

These three are about ten minutes combined. They catch most of what an automated audit flags later.

Useful alt text helps people and AI tools

Images need alternative text that describes what the image is for, not what it shows. A photo of a smiling person in a meeting room rarely needs to read "smiling person in a meeting room". If the image is decoration, the alt should be empty (alt="") so the screen reader skips it. If the image is the only source of a piece of information, the alt should carry that information.

Generated alt text frequently does the opposite of this: long, generic, present on decorative images, missing on important ones. A sweep through the image list, asking "is this telling the user something or not", takes a few minutes and improves both the user experience and how AI summarisation tools describe your page.

This is the only check on this list that has a direct AI-search payoff. The same alt copy that helps a screen reader user understand a product image helps a model decide whether to recommend the product. They are the same need.

Ask how accessibility was tested

If you are reviewing an AI-generated site against an alternative, the simple test is this: would the page still work with the CSS turned off and the JavaScript disabled?

A page whose structure makes sense as plain HTML is a page that will be more accessible, more durable, more search-friendly, and easier to extend. A page that becomes incomprehensible without its styling is a page where the structure is doing none of the work, and the look is carrying everything.

This is not a perfect rule. Plenty of useful interactive components need JavaScript to function. The point is the underlying document. If the headings are real, the labels are real, the buttons are real, the page survives. If the markup is a soup of generated divs, accessibility is something you will retrofit later, badly, and probably more than once.

These checks do not replace user testing

A clean pass on these checks is not a WCAG audit. It does not tell you anything about cognitive accessibility, language clarity, or how the page works for someone with low vision, photosensitive conditions, or motor impairments who needs more than the tab pass.

For a public-facing site that earns money or carries legal weight, you still want a proper audit by someone who tests with real assistive tech. AI builders do not replace that.

What this list does is catch the failures that are most embarrassing and most cheaply fixed. Most generated sites we have looked at this year fail at least three of them. None was hard to fix once someone noticed.

Run this check before launch

AI is not the reason these checks fail. The reason they fail is that the toolset's defaults were set for "looks finished in a screenshot", not "works for the next person who lands on the page". The screenshot is not the user.

We care about whether a page works under real conditions, not whether the generated mockup looked tidy. Half an hour with the keyboard, a heading outline, a contrast checker, and a form pass tends to find most of what is broken. The fixes are usually small. Doing them before the page goes live is the cheap moment.

Generated drafts are a fast starting point. Accessibility is one of the steps that turns a draft into a site.