Accessibility Testing with AI Assistance: Claude for WCAG-Compliant Reviews

1. Why accessibility testing often gets shortchanged

Accessibility is considered late in the development process in many projects, usually only once an audit or a legal requirement such as the European Accessibility Act sets a concrete deadline. By then, typical frontend codebases have accumulated numerous smaller violations: missing alt text, insufficient color contrast, interactive elements without keyboard focus, forms without linked labels. Each individual spot seems small, but together they add up to an application that is hard or impossible to use for people with disabilities.

A central problem is the lack of resources: specialized accessibility testers are rare, and most development teams have neither the time nor the deep expertise to manually check every WCAG success criterion. Accessibility testing with AI assistance addresses exactly this gap: Claude knows the WCAG guidelines in detail and can act as an always-available sparring partner that names violations before an external audit uncovers them at a higher cost.

The expectation matters from the start: Claude replaces neither automated scanners nor the experience of real users of assistive technology. AI-assisted accessibility testing complements both by performing structural and code analysis, formulating test cases, and systematically matching WCAG criteria, at a depth and speed that would otherwise be barely achievable in everyday development.

2. What Claude can and cannot do for accessibility testing

Claude can read HTML markup and ARIA attributes and derive from them whether the semantic structure meets WCAG requirements: correct heading hierarchy, meaningful landmark regions, appropriate roles for interactive components. This static analysis is one of Claude's strengths, because it is based on textual understanding and does not require actual execution in a browser.

What Claude cannot do is the actual perception with a real screen reader or the tactile experience of keyboard operation by a person who depends on it. Claude can predict how a screen reader is likely to read out a certain markup, but that prediction does not replace an actual test with NVDA, JAWS, or VoiceOver. Likewise, Claude cannot precisely measure visual contrast values from a screenshot, and instead relies on color values explicitly stated in the code.

3. Automated checks vs. manual review: Claude's role

Automated scanners such as axe-core or Lighthouse Accessibility reliably cover roughly thirty to forty percent of all WCAG violations, focused on mechanically checkable criteria such as missing alt attributes or insufficient color contrast. The remaining violations, for example whether an error message is actually understandable or whether a complex interaction stays logically traceable for screen reader users, require judgment that automated tools fundamentally cannot provide.

Claude positions itself precisely in this gap between mechanical checking and full manual review: it can simulate judgment that goes beyond pure pattern recognition, for example estimating whether an error message provides enough context for a screen reader user, without claiming the finality of an actual user test. This intermediate position makes Claude a valuable first filter that reduces the number of cases that actually need to be reviewed with real screen readers and real users.

4. Analyzing HTML and ARIA structure with Claude

The most direct use of Claude for accessibility testing is static analysis of templates and components. A prompt that provides a Hyvä template and asks for WCAG violations in the ARIA structure often finds problems overlooked in day-to-day development: a <div> with a click handler instead of a real <button> element, an aria-label that contradicts the visible text, or a modal component without role="dialog" and without a focus trap.

This analysis works best when Claude is explicitly asked to name each found problem with its corresponding WCAG success criterion number, for example 4.1.2 Name, Role, Value or 2.4.6 Headings and Labels. This mapping makes the results directly transferable into a ticketing system and lets the team prioritize based on the WCAG conformance level A, AA, or AAA, instead of working through an unstructured list of vague observations.

<!-- WRONG: clickable div, no keyboard access, no semantic role -->
<div class="btn-primary" onclick="submitForm()">Submit</div>

<!-- WRONG: aria-label contradicts the visible text content -->
<button aria-label="Delete">Edit</button>

<!-- RIGHT: native button, keyboard accessible by default, no ARIA needed -->
<button type="submit" class="btn-primary">Submit</button>

<!-- RIGHT: modal with proper role, labelledby, and focus trap target -->
<div role="dialog" aria-modal="true" aria-labelledby="modal-title" tabindex="-1">
  <h2 id="modal-title">Edit address</h2>
  <!-- Alpine.js x-trap directive handles the focus trap here -->
</div>

5. Generating keyboard operability test cases

Keyboard operability is one of the most commonly overlooked WCAG criteria, because most developers and testers primarily work with a mouse. Claude can derive concrete keyboard test cases from a component description: is every interactive element reachable by Tab, does the tab order follow the visual order, can a dropdown be operated with arrow keys, does Escape close an open modal, is focus returned to the triggering element after closing it.

These test cases can be formulated directly as manual review steps or as automated end-to-end tests with Playwright or Cypress. It is especially valuable that Claude systematically goes through every interactive element of a component and names the expected keyboard interaction for each one, instead of limiting itself to the most obvious cases such as buttons and links and overlooking more complex widgets such as tabs or accordions.

// Keyboard accessibility test cases generated with Claude
// for a custom accordion component (Playwright)

test('accordion is fully keyboard operable', async ({ page }) => {
  await page.goto('/faq');

  // Tab order should follow visual order
  await page.keyboard.press('Tab');
  await expect(page.locator('[data-accordion-trigger]').first()).toBeFocused();

  // Enter or Space should toggle the panel
  await page.keyboard.press('Enter');
  await expect(page.locator('[data-accordion-panel]').first()).toBeVisible();

  // Escape should not be required to close an accordion panel,
  // but focus must remain on the trigger after toggling
  await expect(page.locator('[data-accordion-trigger]').first()).toBeFocused();

  // Arrow keys should move between accordion triggers (WAI-ARIA pattern)
  await page.keyboard.press('ArrowDown');
  await expect(page.locator('[data-accordion-trigger]').nth(1)).toBeFocused();
});

6. Reasoning through screen reader scenarios with Claude

Without access to a real screen reader, Claude can still provide valuable groundwork by describing how a given markup is likely to be read out, based on the documented behavior of NVDA, JAWS, and VoiceOver for standard ARIA patterns. This prediction helps identify obvious problems in advance, for example an image gallery whose alt texts are all identically "image", or a live region that announces changes but carries no aria-live attribute.

A proven approach is asking Claude to simulate the likely read-out text of a component step by step, the way a screen reader would navigate through the page. This simulation does not replace an actual test, but it frequently reveals that important status changes, such as successfully adding a product to the cart, remain completely unnoticed for screen reader users because no live region exists to announce the change.

<!-- WRONG: cart update happens silently, no announcement for screen reader users -->
<div id="cart-count">3</div>

<!-- RIGHT: aria-live region announces the change automatically -->
<div id="cart-count" aria-live="polite" aria-atomic="true">3</div>

<!-- Simulated Claude screen reader walkthrough for the RIGHT version:
     "Region updated: 3. Cart." spoken automatically after the
     product is added, without the user needing to navigate to the cart. -->

7. Systematically matching WCAG criteria with Claude

WCAG 2.2 comprises over eighty success criteria, spread across the conformance levels A, AA, and AAA. A complete manual review against every single criterion is time-consuming, especially for a team with little experience with the criteria yet. Claude can systematically match a component or page against a prioritized subset of the criteria, for example Level AA, which most legal requirements treat as the target level.

The practical value of this matching lies in its structure: instead of an open question like "is this accessible", Claude delivers a clear status for each checked criterion, met, not met, or not applicable, with a brief justification. This structured output can be transferred directly into a conformance matrix, which is needed anyway for accessibility statements under the EU directive.

{
  "component": "Checkout address form",
  "wcag_level_checked": "AA",
  "results": [
    {
      "criterion": "1.3.1 Info and Relationships",
      "status": "fail",
      "reason": "Street and house number fields share one unlabeled fieldset"
    },
    {
      "criterion": "3.3.1 Error Identification",
      "status": "pass",
      "reason": "Invalid postal code shows inline text error, not color alone"
    },
    {
      "criterion": "2.4.6 Headings and Labels",
      "status": "not_applicable",
      "reason": "Form has no section headings by design"
    }
  ]
}

8. CI integration: axe-core plus Claude review

The most practical workflow combines axe-core as an automated check in every CI pipeline with a periodic, deeper Claude review for new or changed components. axe-core runs on every pull request and blocks on clear, mechanically checkable violations. Claude is brought in specifically for new interactive components, where mechanical checks fundamentally reach their limits, for example a new custom dropdown or a multi-step form.

This two-tier pipeline prevents accessibility from being checked only once a year as part of an external audit, and instead distributes the review continuously across the development process. The result is a codebase where new violations are caught early and cheaply, instead of accumulating over months and requiring costly rework at the end.

# CI pipeline step: automated axe-core scan on every pull request
npx @axe-core/cli http://localhost:8080/checkout --exit

# Separate, less frequent step: Claude review for new interactive components
claude -p "Review app/design/frontend/Mironsoft/default/Magento_Checkout/
templates/form/element/dropdown.phtml against WCAG 2.2 Level AA.
List each violated criterion with its number and a one-sentence reason." \
  --file app/design/frontend/Mironsoft/default/Magento_Checkout/templates/form/element/dropdown.phtml

9. Limits and comparison: automated, AI-assisted, manual

Claude cannot replace an actual screen reader experience. Whether an announcement in practice actually sounds confusing or an interaction feels unnatural can ultimately only be answered through tests with real users of assistive technology, ideally with people who use these technologies every day. Even for complex visual aspects such as actually rendered contrast values after the CSS cascade and theme overrides, Claude remains limited to the values visible in the code.

The table above shows clearly: none of the three approaches alone achieves reliably high coverage. Only the combination of automated checks for mechanically checkable criteria, Claude for fast, broad structural and code analysis, and real manual review for the remaining judgment-based criteria delivers an accessibility review that can actually be trusted.

10. Summary

Accessibility testing with AI assistance closes the gap between mechanical scanners such as axe-core, which cover only part of the WCAG criteria, and a complete manual review, for which most teams lack the time. Claude analyzes ARIA structure, generates concrete keyboard test cases, simulates screen reader read-out text, and systematically matches components against prioritized WCAG criteria, with a clear mapping to success criterion numbers.

It remains essential to understand Claude as a complement rather than a replacement: automated tools reliably cover mechanically checkable criteria, Claude speeds up judgment-based analysis and delivers structured intermediate results, real users of assistive technology provide the final confirmation. Anyone who integrates these three layers into the CI pipeline instead of checking accessibility only once a year significantly reduces after-the-fact corrections.

11. FAQ: Accessibility Testing with AI Assistance