AI-Generated UI Components Fail WCAG 2.2: The Review Checklist That Catches It

The button an AI tool just generated looks perfect. It has the right padding, the hover state matches the mockup, and it renders without a single console error. It is also a <div> with an onClick, no keyboard handler, no accessible name, and a focus outline someone told the model to remove because it "looked cleaner." It will pass a demo and fail a screen reader, and if you are shipping AI-generated UI at any scale, you are shipping this failure at scale too.

This is the accessibility version of a problem the security world already named. The research that put the flaw rate in AI-generated code near 45% was measuring security, but the root cause is identical for accessibility: these tools are trained to produce code that satisfies the visible request, and both a security boundary and an accessibility affordance are invisible when everything goes right. The model optimizes for the demo, and in the demo the only user is a mouse.

Why AI-generated components fail the same way every time

The failures are not random. They cluster, because the causes are structural.

The training data is the average web, and the average web is inaccessible. Models learn from an enormous corpus of real front-end code, most of which never passed an accessibility review. When the most common pattern for a clickable thing is a styled div, that is what gets generated, confidently.

Visible correctness is rewarded, invisible correctness is dropped. A keyboard handler, an aria-label, a :focus-visible style, a pause control on a carousel: none of these change what the component looks like when you glance at it working. So they are exactly the parts that get skipped, the same way server-side authorization gets skipped behind a login screen that looks finished.

"Make it look clean" actively removes accessibility. Prompts that ask for polish routinely strip focus outlines, shrink touch targets below the Web Content Accessibility Guidelines (WCAG) 2.2 minimum of 44 by 44 pixels, and replace semantic elements with styled generics that lose their built-in behavior.

The result is a predictable set of WCAG failures in almost every batch of AI-generated components: non-semantic interactive elements, missing accessible names, removed focus indicators, drag-only interactions with no keyboard alternative, touch targets that are too small, and color contrast that looks fine to the person who approved it and fails for the person who cannot read it.

The review checklist that catches it

You do not need a full audit on every component to catch the majority of these. You need a fast, repeatable pass that a reviewer runs before AI-generated UI merges. Here is the one we use.

1. Tab through it with the keyboard only. Every interactive element must be reachable, operable with Enter or Space, and show a visible focus indicator. If you cannot get to it or cannot see where you are, stop here.
2. Check the semantics. A thing that clicks is a <button> or an <a>, not a <div> with a handler. Real elements bring keyboard behavior and a role for free. This one check removes a large share of the failures.
3. Confirm every control has an accessible name. Icon-only buttons and inputs need a label a screen reader can announce, not just a visual glyph.
4. Verify focus is never removed or trapped. No global outline: none. Modals trap focus while open and restore it on close. Focus never lands under a sticky header, which is the WCAG 2.2 "focus not obscured" rule.
5. Measure the touch targets. Interactive targets are at least 44 by 44 CSS pixels, with spacing between adjacent ones.
6. Find the drag-only interactions. Any slider, carousel, or reorder that only responds to dragging needs a button or keyboard alternative.
7. Run an automated scan, and do not trust it alone. Axe or a similar engine catches the machine-detectable failures fast. It will not catch keyboard flow or whether the content makes sense, so it is the floor of the review, never the ceiling.

Steps one and two catch most of what AI tools get wrong. The whole pass takes a few minutes per component once it is a habit, and it is dramatically cheaper than finding these failures in an accessibility audit or a legal complaint after launch.

This is the same failure, human or machine

Here is the connection worth sitting with. The failures an AI tool generates are the same failures a content author introduces on a mature Sitecore site months after launch: empty alt text, "click here" links, a carousel with no pause, a focus outline nuked in global CSS. We wrote about the authoring version of this in the WCAG 2.2 guide for Sitecore teams, and the fix is the same on both sides: a front-end fix that a person or a model can override is temporary, and the durable fix is a constraint the system enforces.

For a content management system (CMS), that constraint lives in the fields, the rendering defaults, and the workflow. For AI-generated code, it lives in the review gate and in the rules you give the model. In both cases you are moving the accessibility decision from "hope the author or the AI got it right" to "the system will not let them get it wrong." That is the only version that holds up over the life of a real product.

If you are generating UI with AI and it is heading for production, run the checklist above before it merges, and treat accessibility the way you should already be treating security: as an invisible property the tool will not give you for free, that you have to build a gate for. The same 45 percent that worries you about security should worry you about who can and cannot use what you ship.

Read next

• WCAG 2.2 vs 2.1 for Sitecore Teams: the authoring-side version of these failures, and the CMS-layer fix.
• The free WCAG 2.2 AA checklist: the component-level bar this review pass is built on.
• Enterprise CMS in 2026: choosing the platform and the partner, with delivery discipline as the through-line.