by A11yGuard (LX AI)
LLM UIs fail accessibility in predictable ways: missing alt text, divs used as buttons, unlabeled controls, and focus states that vanish under sticky headers. WCAG 2.2 added success criteria that hit these generated-interface problems. Run an automated first pass, then verify the checklist by hand before you ship.
WCAG 2.2 builds on 2.1 and adds nine success criteria aimed at mobile, low-vision, and mobility needs. It became a W3C Recommendation in October 2023; keep the normative text open while you audit (w3.org/TR/WCAG22). For teams shipping AI-generated components, the additions that matter most are Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7), and Accessible Authentication (3.3.8). Most product orgs target Level AA. WAI's fundamentals pages still frame why these rules exist beyond "pass the scanner" (WAI Accessibility Fundamentals).
Generators fail here because they optimize for visual density and click-demo polish. They shrink icon hit areas, invent drag-only kanban boards, stack sticky chrome that covers focused fields, and sprinkle ARIA roles that do not match behavior. The checklist below is ordered for a release day pass: measurable items first, judgment items second.
A11yGuard is built for the measurable first pass. Legal conformity and judgment calls still need a human QA owner. If your product uses AI in hiring or similar decision flows, also read the U.S. guidance on algorithms and disability discrimination so UI exclusion is not treated as a cosmetic bug (ADA.gov AI guidance).
Text contrast is the easiest failure to catch: body text needs 4.5:1 against its background; large text needs 3:1 (criterion 1.4.3). Generated themes frequently ship grey-on-grey or placeholder gradients that fail. Measure against the rendered background, including images and overlays.
Non-text Contrast (1.4.11) is the twin rule: UI component boundaries, icons needed to understand the control, and focus indicators must reach 3:1 against adjacent colors. A button drawn with only a faint border, or a focus ring set to a low-opacity outline, fails even when the label text passes. Chart and dashboard UIs hit the same wall; Smashing Magazine documents how accessibility thresholds reshape chart visual design without requiring decorative noise (accessibility standards for chart design).
Target Size Minimum (2.5.8) requires interactive targets of at least 24×24 CSS pixels at Level AA, with limited exceptions for inline links and certain spacing cases. AI layouts commonly produce 16-pixel icon buttons with no padding. That is now a conformance issue, not a taste debate. Padding, min-width/min-height, or larger hit-slop around the visible glyph all count if the pointer target meets the size.
Dragging Movements (2.5.7) means any drag interaction — slider thumb, kanban card, range scrubber — needs a single-pointer alternative such as arrow buttons, a numeric input, or click-to-set. If a user cannot complete the task without dragging, the pattern does not conform. Generators love drag demos because they look interactive in a GIF; ship the alternative control in the same PR.
Focus Not Obscured (Minimum) requires that when a control receives keyboard focus, it is not entirely hidden by author-created content. Sticky headers, bottom nav bars, cookie banners, and floating "AI Help" widgets are the usual offenders in vibe-coded apps. Tab through the page with those layers open. If the focused field sits under a 72px sticky bar, fix the scroll padding or the stacking, not the user's eyesight.
Also confirm 2.4.7 (Focus Visible): every interactive element shows a visible focus indicator. Generators often remove outlines "for aesthetics." Restore a high-contrast ring that meets 1.4.11.
Generators invent ARIA roles that do not match behavior, or add role="button" to elements that are already links. Prefer native elements: <button>, <a>, <nav>, <main>, form controls. ARIA fills gaps; it does not replace semantics. Mismatched roles confuse screen readers and can hide the real action. Treat every generated aria-* attribute as a claim to verify.
When you truly need a custom widget, follow a published pattern from the ARIA Authoring Practices Guide and check roles/states against WAI-ARIA 1.2. Copy-pasting a role string from a chat answer without keyboard support is how "accessible" markup becomes inaccessible behavior.
| Generated smell | What to do | WCAG / practice hook |
|---|---|---|
<div onClick> as CTA | Replace with <button> or <a href> | Name, role, keyboard |
| Icon button, empty name | Add visible text or stable aria-label | 4.1.2 Name, Role, Value |
| Drag-only board | Add move buttons or menus | 2.5.7 Dragging Movements |
| 16px icon hit area | Pad to ≥24×24 CSS px | 2.5.8 Target Size |
| Focus under sticky header | scroll-padding / stacking fix | 2.4.11 Focus Not Obscured |
Decorative role="button" on link | Remove role; keep native link | APG / ARIA 1.2 |
Industry practice and vendor documentation commonly put automated coverage in the roughly 30–40% range of real-world accessibility issues. Tools find missing alt text, many contrast failures, and invalid ARIA. They cannot fully judge whether focus order matches reading order, whether drag alternatives exist, or whether an icon button's name is understandable. That gap is why a clean Lighthouse score is not proof of WCAG 2.2 conformance. Combine an automated first pass with keyboard testing and a manual review of the generated markup.
Do not quote a single percentage as law; treat it as a planning assumption: scanners are necessary and insufficient. Budget human time for the judgment layer every release.
Ship blockers for most B2B apps at AA:
Defer only with an owner and a date: secondary decorative animations, non-critical charts with a data table alternative already present, help-widget polish that does not block tasks. Deferred is not forgotten.
This checklist is not a full WCAG audit, not a VPAT, and not legal advice. It does not claim A11yGuard (or any tool) guarantees conformance, ADA compliance, or that automated scans "never miss" issues. We do not publish invented customer metrics or before/after conversion lifts. The product automates the measurable first pass; you still need human QA for judgment criteria and for sign-off language used with customers or regulators.
Print the tables, freeze the branch, run the scanner, then do the keyboard and naming pass. Keep the normative WCAG text and the Quick Reference open while you argue about edge cases. When the model regenerates a screen, re-run the same list — accessibility debt in vibe-coded apps is a loop, not a one-time project.
No. Lighthouse and similar tools run automated checks that cover about 30–40% of real issues. They miss focus order, drag alternatives, and accessible naming of icon buttons. A clean score clears the measurable basics but is not proof of conformance.
Criterion 2.5.8 sets a minimum of 24×24 CSS pixels for pointer targets at Level AA, with limited exceptions for inline links. Tiny icon buttons without padding fail this rule.
Only for large text. Body text needs 4.5:1 under criterion 1.4.3. The 3:1 threshold applies to large text and to non-text contrast such as icon and focus-indicator boundaries under 1.4.11.
Use semantic HTML first. Native buttons, links, and landmarks are more reliable than ARIA roles. Add ARIA only where native markup cannot express the behavior, and verify every generated role actually matches the element's function.
Try the product: A11yGuard
2026-09-16 · primary sources only · no fabricated traffic metrics