Your AI pair programmer never gets tired, never skips a semicolon, and never argues about tabs versus spaces. It also never remembers, on its own, that a <div> is not a button. Ask it to build a card component, a modal, a settings toggle, anything with interactivity, and it will hand you something that runs perfectly and looks pixel-correct in the browser. Run a screen reader over it and the illusion falls apart in the same five places, every time, unless someone in the loop explicitly tells the tool not to do that.
We work inside codebases that lean heavily on Copilot-style, in-editor code completion every day. The pattern is consistent enough that we could set a clock by it. The bugs are not exotic. They are the accessibility equivalent of a typo, small, mechanical, and completely invisible until a real user with a keyboard or a screen reader hits the wall.
The Stat: Deque's own published research finds automated scanning alone catches roughly 57.38% of WCAG issues on a page - a gap that AI-assisted code completion does not close by default. (Source: Deque Systems)
That gap matters even more when the code being scanned was written by a model that was never trained to prioritize accessibility in the first place. It was trained to predict the next plausible token in millions of public repositories, a large share of which have the exact same bugs baked in.
Why the same five bugs keep showing up
Code completion models are pattern matchers. They complete the next few lines based on what similar code, written by similar developers, in similar contexts, usually looks like. Most of the training corpus is ordinary application code written by developers who were not thinking about assistive technology in that moment. So the model learned the shortcuts along with the syntax.
That is the whole story. There is no malice, no missing feature flag. The tool is doing exactly what it was built to do: predict the statistically likely continuation. Accessible markup is often the less common continuation, so it loses.
1. The div that pretends to be a button
Ask an assistant to "add a clickable card" or "make this row expandable" and it will very often reach for a <div onClick={...}> before it reaches for a <button>. It compiles. It looks right. It is completely invisible to keyboard navigation because a plain div has no default tab stop and no default role, so a mouse user never notices anything is wrong while a keyboard user cannot reach it at all.
The fix is not complicated. Native interactive elements come with keyboard support, focus handling, and semantics for free. The ARIA Authoring Practices Guide's button pattern lays out exactly what a custom button needs if you truly cannot use a native one: a role="button", tabindex="0", and both Enter and Space key handling. In practice, we almost never need the custom version. A real <button> styled to look like anything you want is simpler and safer than reconstructing button behavior from scratch.
2. Form fields with no real label
Autocomplete loves to generate an <input> next to some descriptive text, styled to look like a label, but never actually wired to the input with a for/id pair or wrapped in a <label> element. Visually it is indistinguishable from a correctly labeled field. Functionally, a screen reader announces "edit text, blank" and nothing else, so the user has no idea what they are supposed to type.
This one is especially sneaky because placeholder text makes it look done. Placeholder text is not a label. It disappears the moment someone starts typing, and many screen reader and browser combinations do not reliably announce it as the field's name in the first place.
3. Headings chosen for size, not structure
We see this constantly: a model generates a <span> or <div> styled with large, bold text to "look like a heading," or worse, it jumps from an <h2> straight to an <h5> because that combination happened to produce the font size the prompt asked for. Sighted users scanning the page visually never notice. Screen reader users who navigate by heading level, a core, widely used technique, land on a document that makes no structural sense.
Headings are a table of contents, not a font-size utility. Get the visual size from CSS and get the level from the actual document outline.
4. Focus styles removed, not replaced
Somewhere in the training data, outline: none shows up next to almost every custom-styled interactive element, usually because a developer was annoyed by the default browser outline and never replaced it with something better. Completion models learned the association and now suggest it constantly. The result is a page where tabbing through the interface reveals nothing about where you are. For anyone who navigates by keyboard, this is not a cosmetic complaint, it is the difference between using the product and giving up on it.
The fix is one line: keep a visible focus indicator, even if you restyle it to match your brand.
5. Images with no alt attribute at all
Not a bad alt, not a lazy alt="image", but the attribute simply missing. This is common in AI-generated code specifically because example snippets and quick demos in the training data frequently drop alt for brevity. The completion model reproduces that brevity in production code, where it becomes a hard stop for anyone relying on a screen reader to know an image is even there.
We covered exactly this kind of failure in detail in our earlier piece on everything ChatGPT got wrong building an accessible form, and if you want to see how this plays out across multiple assistants side by side rather than one narrative test, our structured comparison in Can AI Write Accessible Code? We Tested 4 AI Models scores exactly these kinds of gaps model by model.
What actually catches these before launch
None of these five bugs require a redesign. They require a review step that specifically looks for them, because visual QA and even most manual testing will not surface them. A page can look flawless and fail every one of these checks at the same time.
A practical workflow that holds up in real teams:
- Run an automated scanner like axe DevTools on every pull request that touches markup, not just before a release.
- Tab through new components with the mouse unplugged. If you cannot reach it, use it, and see where you are, a keyboard-only user cannot either.
- Treat AI-suggested interactive elements as a draft, not a final answer. If the suggestion reaches for a
divwhere a native element would do the job, take the native element. - Spot-check headings against the actual document outline, not the rendered font size.
Automated tools will catch a large share of this fast, but remember the stat above: scanning alone gets you roughly 57.38% of the way there. The rest needs a human pass, and that is exactly the gap we built our free accessibility tools to help close.
If your team is shipping fast with AI-assisted code completion and wants a second set of eyes on what is actually going out the door, reach a real person on our team at experts@wcag.world, or start with our free tools to see where these five patterns might already be hiding in your product.