Why your AI-built site still isn't accessible

How a clean scan hides a broken site

Automated tools such as WAVE or axe are genuinely useful, and a good first check. But they can only test what’s measurable in the code: is there an alt attribute, does the contrast ratio pass, is there a label element nearby. They can’t tell you whether a menu traps keyboard focus, whether a form makes sense when read aloud, or whether a button that looks like a button actually behaves like one to a screen reader. Estimates vary, but automated tools typically catch somewhere around a third of WCAG failures. The rest need a person with a keyboard and a screen reader.

That gap matters more with AI-generated code than with hand-written code, because a language model optimises for “looks right” far more reliably than it optimises for “behaves right”. It has seen millions of examples of what a styled button looks like, and it will happily reproduce that appearance with a <div> and an onclick, because visually the result is identical. A scanner may still pass it, because nothing about it is technically wrong until you try to tab to it.

Semantic HTML: the fix that's usually already free

“Semantic HTML” means using the element that actually describes what something is, rather than a generic <div> or <span> styled to look like it. The native elements aren’t just tidier markup: each one comes with keyboard behaviour, a role, and a focus state built in, for free, with no extra code.

• <button> instead of <div onclick> gets you Enter and Space activation, a visible focus outline, and “button” announced automatically. A styled div gets you none of that unless you build it all by hand.
• <a href> instead of a clickable span gets you keyboard access and a destination a screen reader can announce before it’s activated, plus normal browser behaviour like open-in-new-tab.
• <nav>, <main>, <header>, <footer> instead of unlabelled divs give screen reader users landmarks to jump between, which is how many of them navigate a page at speed.
• A real heading hierarchy (<h1> through <h6>, in order, one <h1> per page) lets screen reader users skim a page’s structure the way a sighted user skims with their eyes.
• <label for=""> tied to an input’s id gets you a form field that’s announced correctly and has a larger, easier click target, with nothing else required.

If you’re prompting an AI tool to build something, ask for it this way rather than describing only the look: “a button element, not a div”, “a real nav landmark around the menu”, “label elements tied to each input by id”. Being specific about the HTML, not just the appearance, is often the difference between a working result and one that merely looks the part.

No ARIA is better than bad ARIA

ARIA (Accessible Rich Internet Applications) is a set of attributes that can tell assistive technology what something is and does, when HTML alone can’t. The W3C’s own ARIA Authoring Practices Guide opens with a rule worth remembering: “No ARIA is better than Bad ARIA.” Incorrect ARIA doesn’t just fail to help, it actively lies to a screen reader about what’s on the page.

Two patterns show up often in AI-generated code:

• ARIA added on top of an already-correct native element. Putting role="navigation" on a <ul>, for instance, when wrapping it in a <nav> would have done the job with no ARIA at all. It’s not wrong exactly, but it’s clutter that's easy to get subtly wrong, and unnecessary.
• aria-hidden="true" applied too broadly, often on a wrapper element without checking what’s inside it. If a focusable link or button ends up inside that hidden wrapper, a keyboard user can still tab to it while a screen reader is told it doesn’t exist. That’s a genuine, common failure, not a hypothetical one, and it’s a pattern this kind of over-application produces repeatedly.

The rule of thumb: reach for ARIA only for things HTML genuinely can’t express, such as a live region announcing a dynamic update, or state on a custom widget you had to build because no native element fits. If a native element already does the job, use it and add nothing on top.

Why the overlay won't fix it

An accessibility overlay is a script you add to a site, sometimes just one line, that promises to detect and patch accessibility issues automatically, often via a small widget in the corner of the page. It’s a tempting fix precisely because it’s so little effort compared with going back through the code.

The problem is what it can and can’t actually do. An overlay can adjust things like font size, colour contrast toggles and cursor size, because those are surface-level CSS changes. It cannot write a meaningful alt description for a photo it’s never seen tested, cannot fix a heading order, cannot make a styled div behave like a real button, and cannot repair a missing label-to-input association. Those all require knowing what the content actually means, which is exactly the judgement an automated script doesn’t have.

This isn’t a minority view. The Overlay Fact Sheet, an open statement created by accessibility researcher Karl Groves, has been signed by more than 800 accessibility professionals worldwide, including people who helped write the WCAG and ARIA specifications themselves, and it recommends against overlays as a category. In a WebAIM survey of people who use screen readers and other assistive technology, the majority rated overlays as “not very” or “not at all” effective.

If you’ve already got an overlay running: it’s not doing the harm some marketing content claims, but it isn’t doing the job either. Get an audit of what’s actually wrong underneath it, fix that at the source, and then decide whether the overlay is worth keeping for its genuinely useful bits, like font resizing, rather than trusting it as your accessibility strategy.

What to look for if you hire someone to check this

If you’d rather have someone else verify all of this rather than doing it yourself, here’s what separates a useful check from a rubber stamp:

• They test manually, not just with a scanner. Ask directly: do they use a keyboard and a screen reader themselves, or only run a tool and hand you the output?
• They can show you a finding, not just a score. A number out of ten tells you little. A specific barrier, on a specific page, with a specific fix, tells you what to do next.
• They separate diagnosis from the fix. An auditor who also sells you the remediation work has an incentive to find more than is really there. Independent findings you can hand to any developer are worth more.
• They test against a named standard, normally WCAG 2.2 at Level AA, and tell you the result criterion by criterion rather than a vague “mostly compliant”.
• They’re specific about overlays and automated fixes, and won’t recommend one as a substitute for fixing the code.

For more on this, see our guide on what a quick oversight audit and a full audit actually cover.

Common questions