by A11yGuard (LX AI)

WCAG 2.2 checklist for AI-generated UI

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.

What WCAG 2.2 changed for generated UI

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.

Step-by-step workflow before you ship

- Freeze the generated branch. Do not keep regenerating while you measure. - Run an automated accessibility scan (axe, Lighthouse, or your CI gate) and file every contrast / missing-name / invalid-ARIA hit. - Walk the WCAG 2.2 Quick Reference filters for Level AA and mark the 2.2-only criteria as explicit rows in your ticket. - Keyboard-only pass on every primary user journey (sign-up, pay, core task). - Screen-reader spot check (NVDA on Windows or VoiceOver on macOS) on icon buttons and dialogs. - Record residual risk: what the scanner cannot see, what you deferred, who owns the follow-up.

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).

Contrast you can compute, contrast you cannot

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).

Checklist — contrast

- Body copy ≥ 4.5:1 on every theme (including dark mode) - Large text / big numerals ≥ 3:1 - Focus ring ≥ 3:1 against the surface behind it - Icon-only affordances ≥ 3:1 when the glyph carries meaning - No reliance on color alone for error or success state (pair with text or icon)

Target size and dragging after WCAG 2.2

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.

Checklist — pointer access

- Every icon button's hit area ≥ 24×24 CSS px - Adjacent targets have enough spacing or share a conforming exception - Every drag gesture has a non-drag path documented in the UI - Touch targets still work when the OS text size increases

Focus order, sticky chrome, and 2.4.11

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.

Checklist — focus

- Visible focus on links, buttons, inputs, custom widgets - Focus order matches reading order for the main flows - Modals trap focus and return it to the invoker on close - Sticky/fixed UI never fully covers the focused control (2.4.11) - Skip link present and working on content-heavy pages

ARIA: semantic HTML first, ARIA second

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.

Why automated checks catch only part of the picture

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.

Common mistakes teams make with AI UI

- Regenerating after manual fixes without locking tokens or primitives, so contrast and names vanish - Trusting the demo recording (mouse-only) as evidence the keyboard path works - Stacking ARIA to silence a linter instead of fixing the element type - Shipping marketing gradients that were never measured on the live DOM - Calling a CI green build "compliant" in sales decks — that language overclaims

Decision criteria: AA now vs later

Ship blockers for most B2B apps at AA:

- Empty accessible names on primary actions - Body text under 4.5:1 on the default theme - No keyboard path through checkout or the core task - Focus fully hidden by sticky UI on required fields - Drag-only critical actions with no alternative

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.

What this is NOT

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.

Closing

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.

References

- WCAG 2.2 - WCAG 2.2 Quick Reference - WAI Accessibility Fundamentals - ARIA Authoring Practices Guide (APG) - WAI-ARIA 1.2 - Smashing Magazine — accessibility standards and chart design - ADA.gov — AI and disability discrimination guidance

- Contrast and ARIA in vibe-coded apps - Explore the full AI micro-SaaS topic matrix →

Does a perfect Lighthouse accessibility score mean my site is WCAG 2.2 compliant?

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.

What is the minimum target size under WCAG 2.2?

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.

Is 3:1 enough contrast for all text?

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.

Should I rely on ARIA to fix generated UI?

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.

Decision-support only. Not legal advice or an accessibility conformity certificate.

← Back to blog · Read full English article