Claude for Accessibility Testing: Where AI Helps and QA Matters

Accessibility testing can be one of those things that gets pushed back when a release has functional issues to resolve, regression tests to run and a deadline approaching.

The problem is that accessibility barriers do not always stand out during a normal testing session. A page may look fine; its buttons may work with a mouse, and its main journey may pass every functional check. Yet someone navigating with a keyboard might get stuck, lose track of focus or miss information that is communicated only through colour.

We wanted to explore how AI could help us examine these issues more efficiently without losing the judgement that good accessibility testing requires.

For a recent client web application, we used Claude to support accessibility checks guided by the Web Content Accessibility Guidelines (WCAG). What made the approach useful was not simply asking AI to find problems. It was how we defined what to check and how the results should be presented. 

A better question to ask AI

A broad prompt such as “check this website for accessibility” is unlikely to give a QA team everything it needs. Accessibility covers different types of interaction, and a useful result depends on what the team is actually trying to assess.

We gave Claude a more defined scope, focusing on keyboard navigation, focus visibility and behaviour, colour use, form labels and validation messages, and the way the interface behaved on smaller screens. We used WCAG as the reference point rather than treating accessibility as a matter of visual preference.

We also specified the rules and reporting format for the task. That distinction matters. A list of possible issues is not particularly helpful if testers have to spend more time working out where each issue occurs, how to reproduce it and why it matters.

The aim was to make the output useful within the QA workflow, not just generate observations about the interface.

You can read more about

QA-led approach to AI-assisted test automation

The problems weren't always visible on the page

The checks brought attention to several different barriers in the application.

Some cards and videos could not be reached using the keyboard. Focus disappeared after a pop-up closed, leaving the user without a clear place to continue navigating. Status information relied on colour alone, while a help button overlapped other controls on smaller screens.

These problems have something in common: they can be easy to miss when testing focuses mainly on whether a feature works as intended. A card might open when clicked with a mouse, but that does not tell us whether someone using a keyboard can reach it. A pop-up might close correctly, but the interaction can still leave the user disoriented. A status indicator might look obvious, yet communicate very little to someone who cannot distinguish its colours.

Across one testing session, 20 accessibility issues were identified. We also examined the interface at phone, tablet and laptop sizes, with findings recorded in Jira using reproduction steps and expected-versus-actual behaviour.

The examples were a useful reminder that accessibility is not a separate layer of polish to add after functionality is complete. It is part of how the product behaves for the people using it. Read More: These issues also show how small interface defects can affect the way people use a product. Explore other examples in our article on common UI bugs that affect the user experience.

Getting a finding is not the same as confirming a defect

This is where we would be careful about relying on AI alone.

An observation needs to be checked against the actual application. A suspected contrast issue, for example, needs to be measured against the relevant requirement. A suggested WCAG reference needs to be verified. And before a finding is passed to a developer, the team needs enough detail to understand the behaviour and reproduce it.

There is another important distinction. Keyboard checks, visual inspection and responsive-layout checks can reveal useful problems, but they do not establish that a website works correctly with screen readers or meets every applicable WCAG criterion. Those questions require the appropriate additional testing.

Claude helped us structure the checks and the resulting findings. QA judgement remained necessary to assess the observations, confirm their significance and identify where more testing was needed.

That separation matters when introducing AI into a testing process. The objective is not to accept everything a tool reports. It is to make the work more manageable while maintaining confidence in the results.

Where AI fits into accessibility testing

Our experience with Claude highlighted a practical opportunity for QA teams. AI can support accessibility checks when the task is clearly defined, the expected output is useful to the team, and the findings are reviewed as part of the normal testing process.

For teams already balancing functional, regression and release testing, that is worth exploring. Not because AI removes the need for accessibility expertise, but because a more structured workflow can help bring accessibility checks into the work that is already happening.

The question is not whether AI can declare a website accessible. It is whether we can use it to examine the right things, produce findings that developers can act on and make better use of our testing time.

That is where we see its value: as part of a considered QA approach, with the testing standard, evidence and human judgement still doing their jobs. Check CalibreCode’s accessibility testing services