AI-Powered Accessibility Audits: A Practical Step-by-Step Guide

Why Most Accessibility Audits Fall Short

I have audited dozens of React applications for accessibility issues, and here is the uncomfortable truth: most teams think they are covered because they ran Lighthouse once and got a 90+ score. Lighthouse catches maybe 30% of real accessibility problems. It cannot test keyboard navigation flows. It cannot verify that a screen reader user can complete your checkout process. It cannot tell you that your custom dropdown traps focus in an infinite loop.

AI tools changed how I approach accessibility audits. Not as a replacement for manual testing — that is still essential — but as a first pass that catches 80% of issues in a fraction of the time. Here is my complete process.

Step 1: Run the Automated Baseline (5 Minutes)

Start with the tools that give you quick, reliable results. Install axe-core if you do not have it:

npm install -D @axe-core/react

Add it to your development entry point:

// src/main.tsx (development only)
if (process.env.NODE_ENV === 'development') {
  import('@axe-core/react').then((axe) => {
    axe.default(React, ReactDOM, 1000);
  });
}

Now open your app and check the browser console. Every accessibility violation will be logged with severity, the element, and a link to the WCAG rule it violates.

Export the results by running in your browser console:

// Run axe on the current page
axe.run().then(results => {
  console.log(JSON.stringify(results.violations, null, 2));
});

Save this JSON output. You will feed it to Claude Code in the next step.

Step 2: AI Analysis of Automated Results (10 Minutes)

Take the axe-core output and give it to Claude Code with this prompt:

Here are the accessibility violations found by axe-core on our dashboard page:

[paste JSON results]

For each violation:
1. Explain the impact on real users (who is affected and how)
2. Provide the exact code fix with before/after examples
3. Rate the fix difficulty: easy (1-5 min), medium (15-30 min), hard (1+ hour)
4. Group fixes that can be done together

Prioritize by: critical (blocks usage) > serious (major difficulty)
> moderate (inconvenience) > minor (best practice)

This transforms a list of cryptic WCAG rule codes into a prioritized action plan. Claude Code explains each violation in plain English — "users who navigate with keyboard cannot reach the submit button because the custom modal does not trap focus" — which is infinitely more useful than "focus-trap-violation."

Step 3: Component-Level Deep Audit (15 Minutes)

This is where AI really shines. For each complex interactive component, run this prompt:

Read src/components/ui/ComboBox.tsx

Perform a complete accessibility audit of this component. Check:

1. ARIA attributes:
   - Is role correct for this type of widget?
   - Are aria-expanded, aria-selected, aria-activedescendant used correctly?
   - Does aria-label or aria-labelledby provide context?

2. Keyboard navigation:
   - Can users open/close with Enter and Escape?
   - Can users navigate options with Arrow keys?
   - Does Tab move focus out of the component (not trap it)?
   - Is there a visual focus indicator?

3. Screen reader experience:
   - Will a screen reader announce the component's purpose?
   - Are state changes (open/close, selection) announced?
   - Is the live region used for dynamic updates?

4. Color and contrast:
   - Are interactive states distinguishable without color alone?
   - Does focus indicator have 3:1 contrast ratio?

For each issue found, provide the exact fix with code.

I run this on every custom interactive component: dropdowns, modals, date pickers, tabs, accordions, data tables. These are the components that break accessibility most often because they require careful ARIA implementation.

Step 4: Page-Level Flow Audit (10 Minutes)

Individual components can be accessible, but the page-level flow can still be broken. Use this prompt:

Read all components rendered on the checkout page:
- src/pages/Checkout.tsx
- src/components/checkout/CartSummary.tsx
- src/components/checkout/PaymentForm.tsx
- src/components/checkout/AddressForm.tsx

Audit the complete user flow for accessibility:

1. Focus order: Does Tab move through the page in logical order?
2. Error handling: Are form errors announced to screen readers?
3. Loading states: Is there an aria-live region for async updates?
4. Navigation: Can a user complete checkout using only a keyboard?
5. Headings: Is there a logical h1 > h2 > h3 hierarchy?
6. Skip links: Can users skip to the main content?

Identify any flow where a keyboard-only or screen reader user
would get stuck or miss critical information.

This catches issues that component-level audits miss: wrong heading hierarchy, missing skip links, focus moving to the wrong place after a form submission.

Step 5: Generate the Accessibility Report (5 Minutes)

Compile everything into a report your team can act on:

Based on our accessibility audit, generate a markdown report with:

## Executive Summary
- Total issues found
- Critical vs serious vs moderate
- Estimated fix time

## Critical Issues (Must Fix)
For each: description, affected users, component, exact fix, time estimate

## Serious Issues (Should Fix)
Same format

## Moderate Issues (Nice to Fix)
Same format

## Recommendations
- Testing tools to add to CI
- Team training suggestions
- Ongoing monitoring approach

Step 6: Add Automated Checks to CI (5 Minutes)

Prevent new accessibility issues from shipping. Add this to your test suite:

// src/tests/accessibility.test.tsx
import { render } from '@testing-library/react';
import { axe, toHaveNoViolations } from 'jest-axe';

expect.extend(toHaveNoViolations);

describe('Accessibility', () => {
  it('Dashboard page has no accessibility violations', async () => {
    const { container } = render(<DashboardPage />);
    const results = await axe(container);
    expect(results).toHaveNoViolations();
  });

  it('Login form has no accessibility violations', async () => {
    const { container } = render(<LoginForm />);
    const results = await axe(container);
    expect(results).toHaveNoViolations();
  });
});

Install the dependency:

npm install -D jest-axe @types/jest-axe

Now every PR that introduces accessibility violations will fail the build.

What This Process Catches (And What It Does Not)

This AI-assisted process reliably catches: missing ARIA attributes, incorrect roles, heading hierarchy issues, missing alt text, color contrast problems, keyboard trap issues, missing focus indicators, and form labeling problems.

It does not catch: cognitive accessibility issues, reading level problems, motion sensitivity, or complex screen reader interaction patterns. For those, you still need manual testing with real assistive technology.

But going from "we have never done an accessibility audit" to "we caught and fixed 80% of issues in an afternoon" is a massive improvement. Start here, then build toward comprehensive manual testing.