Your AI-Generated Components Have Broken Focus States and Missing ARIA — Here is How to Find Them All

TL;DR: AI-generated UI reliably passes visual review and fails accessibility audit. Install the axe-core Claude Code skill to catch violations in the same turn Claude Code writes the component.

What you will be able to do after this:

• Automatically scan every AI-generated component for WCAG 2.2 violations before committing
• Feed axe-core output back into Claude Code so it fixes violations in the same session
• Know exactly where automated scanning stops and what still needs human eyes

Three things to know up front:

1. Automated scanners like axe-core catch 30–50% of WCAG 2.2 success criteria — mainly color contrast, missing labels, and structural errors. Keyboard flow, reading order, and cognitive-load issues usually need a human pass.
2. The most consistent failures in Claude Design and Claude Code-generated UI: <button> elements without accessible names, generated color palettes below 4.5:1 contrast ratio, and outline: none in generated CSS that removes focus rings entirely.
3. Running jest-axe in component tests gives you a baseline scan on every PR without spinning up a browser.

Walk-through:

Install the community skill:

claude skill install airowe/claude-a11y-skill

Run the audit on a component file:

/a11y-audit src/components/Button.tsx

The skill runs axe-core (Deque's engine) and jsx-a11y (static JSX lint rules), feeds the violation list back into context, and Claude Code proposes targeted fixes in the same turn. Typical output:

axe-core: 3 violations
  [critical] Button: missing accessible name (aria-label or text content)
  [serious]  Color contrast: 3.2:1 (target: 4.5:1) on .badge-text
  [moderate] Focus indicator: outline removed on .btn-primary:focus

For a broader sweep before merging a feature:

npx jest --testPathPattern=accessibility

The skill generates a jest-axe component test if you don't already have one. For full-page checks, it generates a Playwright-based audit test that runs headless.

What to do after the scan:

1. Feed the violation list into the same Claude Code session: "Fix the three axe violations in Button.tsx." Claude Code can address most structural and ARIA issues in one turn.
2. After the fix, rerun /a11y-audit to confirm the violations are gone (Claude sometimes introduces new ones while fixing others).
3. Do one keyboard-only navigation pass through the feature manually — tab order, focus management after modal open/close, and screen-reader label flow are outside what axe catches.

The limit to be honest about: Axe finds structure. It does not find that your generated error message says "Invalid input" instead of telling the user what to enter, or that your onboarding flow requires 12 clicks where 3 would suffice. The automated pass is not a substitute for testing with assistive technology — it is a first filter that prevents the worst violations from reaching users at all.

Sources: airowe/claude-a11y-skill — GitHub · dequelabs/axe-core — GitHub · I Built 33 Claude Skills to Fix the Vibe Design Accessibility Gap — Matthew Stephens, Medium