Accessibility

Accessibility testing without real users is not enough

Accessibility testing only tells part of the story when it stops at tools and audits. The real gaps appear when people try to use the product in practice.

Why automated checks and formal validation are useful but incomplete, and why real user testing is what shows whether an accessible product is actually usable.

15 November 20236 min read

In short

Why automated checks and formal validation are useful but incomplete, and why real user testing is what shows whether an accessible product is actually usable.

Why formal testing can create false confidence

From a perspective, everything appears to be in place, and by the time testing is complete, there is a sense that has been properly validated.

That is understandable.

It is also where a lot of teams get caught out.

Because testing tools can only tell you what is detectable.

Accessibility tools can tell you what is technically wrong. They cannot tell you what still feels difficult to use.

What tools are good at and where they stop

They can identify missing labels, insufficient contrast, incorrect semantics, and a range of technical issues that are important to fix. They are useful, and in many cases essential, for catching problems early and maintaining a baseline level of quality.

But they do not tell you how the experience actually feels to use.

And that is where the gap sits.

Key takeaway

Automated and audit-based testing is essential for baseline quality, but it cannot reveal how effort, confusion, or hesitation show up in real use.

Why technically sound products can still create friction

In my experience, you can have a product that performs well in automated tests and still creates significant for real users. can technically work, but require unnecessary effort. Content can be accessible, but difficult to understand in . Interactions can be valid, but unintuitive when used in a different way than originally intended.

Nothing is technically wrong.

But something is clearly not working.

That only becomes visible when real people start using it.

Why real usage reveals what testing tools cannot

Users who rely on assistive technology do not interact with products in the same way as those designing or building them. users navigate differently. Keyboard-only users move through content in a different rhythm. Voice control introduces another layer of entirely. Even the way information is processed can vary significantly depending on the user.

These are not .

They are real usage .

And they expose issues that tools cannot.

Where accessible journeys still break down in practice

For example, a might be able to access every element on a page, but the order in which those elements are read can make the confusing. A form might be fully operable via keyboard, but require too many steps to complete efficiently. might technically work, but lack the context needed to make decisions quickly.

From a compliance perspective, everything passes.

From a user perspective, the experience breaks down.

This is where testing needs to go beyond validation.

It needs to become understanding.

Why real user testing changes what teams learn

Testing with real users introduces a different kind of . It shows where hesitation happens, where confusion , and where effort increases. It highlights the moments where users need to stop and think, where assumptions in the design do not hold up, and where the experience does not support the way they naturally interact.

These are the issues that matter most.

Because they directly affect whether someone can complete what they came to do.

Why this testing needs to happen earlier

What I have found is that teams often underestimate how early this kind of testing should happen. It is frequently left until later stages, once the product is more complete, under the assumption that it is something to validate rather than something to shape the design.

By then, the same problem appears again.

You are testing something that is already fixed in place.

At that point, become harder to act on. Changes require more effort, timelines are tighter, and there is less flexibility to rethink core decisions. The value of the testing is still there, but the ability to respond to it is reduced.

Why accessible products need both validation and lived use

When real user testing is brought in earlier, the dynamic changes.

It becomes part of how decisions are made, not just how they are checked. Assumptions are challenged sooner. are refined before they are scaled. are shaped based on actual , rather than being adjusted after the fact.

The result is not just a more accessible product.

It is a more usable one.

This is where testing becomes more than a .

It becomes a way of understanding how your product performs in the real world.

Automated tools and audits still have a place. They provide , speed, and coverage that would be difficult to achieve otherwise. But they should not be the only source of truth. Without real user input, you are only seeing part of the picture.

And it is the part that is easiest to measure.

The harder part is understanding how people actually experience what you have built.

is not proven by passing tests.

It is proven by people being able to use the product without unnecessary effort.

And that is something only real users can show you.

LET'S WORK TOGETHER

Ready to improve your product?

UX, research and product leadership for teams tackling complex digital services. The work usually starts where things have become harder than they need to be: unclear journeys, inconsistent products, competing priorities, or teams trying to move forward without a clear direction. I help simplify the problem, shape the right next step, and turn complexity into something people can actually use.

Previous feedback

Will Parkhouse

Senior Content Designer

01/20