Menu

Accessibility

Assistive Technology Testing

A practical UX and accessibility method for validating real-world usability with assistive technologies across key journeys.

How to run assistive technology testing to identify compatibility and interaction barriers beyond baseline compliance.

4 min read

What it is

Assistive technology testing is a UX and method used to evaluate how well a product works with tools that people rely on to interact with digital experiences.

These tools include , voice control software, screen magnifiers, switch devices, and other technologies.

The method involves testing real using these tools to understand how the experience actually works in practice.

It goes beyond compliance to focus on real .

The goal is to ensure the product works effectively for people with different needs, abilities, and ways of interacting.

Assistive technology testing shows whether accessibility holds up in real conditions, not just in audits.

When to use it

Use this method when needs to work in reality, not just on paper.

It is most useful when:

you are building or auditing accessible products
you need to validate real user experience
you are working in regulated sectors
you want to go beyond WCAG compliance
you are testing complex interactions

It is less useful when:

the product is still in very early concept stages
accessibility is not being prioritised
Assistive technology testing is often used alongside accessibility audits and WCAG reviews.

Key takeaway

Use this method when the question is whether people can actually use the product with their real tools.

How to run it

Set up properly

Decide which technologies you are testing with and why. , magnification, speech input, switch access and reading tools fail in different ways, and covering all of them badly is worse than covering two properly.

Use real tools and realistic scenarios. Emulating assistive technology tells you what the markup says, not what a person experiences.

Run the method

Assistive technology testing is hands-on and scenario-based. It is the most expensive of the checks, which is why it belongs after the cheaper ones have passed.

  1. Use the technology to navigate the product as its users do, rather than checking that it can be made to work with effort.
  2. Attempt to complete whole tasks. Component-level checks pass routinely on products that cannot be used end to end.
  3. Observe how content and behave under each tool: magnification reflow, speech command targets, switch scanning order.
  4. Test across tools and devices, because differs between combinations more than most teams expect.
  5. Note as well as blockers. Something that takes forty keystrokes is technically accessible and practically abandoned.

Focus on real use, not technical checks. The question is whether someone can finish, not whether the attribute is present.

Capture and make sense of it

The value comes from real-world . After testing, document:

  • Barriers and issues, with the tool and they appeared on
  • Inconsistencies between tools, which often point at non-standard markup
  • Fixes prioritised by impact on
  • What was tested and what was not, so the claim is honest

Use this to improve in practice. It is the check that tells you whether the earlier ones were meaningful.

What to look for

Focus on:

Compatibility: whether the product works with different tools
Cost of completion: how many steps the task actually takes
Interaction: how users engage with elements
Consistency: behaviour across technologies
Barriers: issues that block or slow users

Where it goes wrong

Most issues come from:

If it only works in theory, it doesn’t work.

Testing one technology and generalising to all of them
Emulating assistive technology rather than using it, which tests the markup and not the experience
Checking components instead of attempting whole tasks
Assuming people use the tools the way the documentation describes
Reporting technical conformance while the task remains impossible to finish

What you get from it

Done properly, this method gives you:

Evidence of whether people can actually complete tasks with the tools they use
Barriers that the cheaper accessibility checks cannot reach
A clear picture of where behaviour differs between tools
Confidence that the earlier accessibility work was meaningful

Key takeaway

It helps ensure your product works for everyone.

Get in touch

If this sounds like something you need, we can test your product with assistive technologies and fix the issues that impact real users.

No guesswork. No assumptions. Just accessibility that actually works.

FAQ

Common questions

A few practical answers to the questions that usually come up around this method.

What is assistive technology testing in UX?

It is a method for testing how a product works with tools like screen readers and voice control.

When should you use assistive technology testing?

Once the basics hold. Run it after keyboard and screen reader testing pass, because it is the most expensive of the three and will otherwise surface problems those cheaper checks would have caught. Before release for anything carrying a legal or safety obligation.

What tools should you test with?

Screen readers, voice control, magnifiers, and other assistive tech.

Is it the same as a WCAG review?

No. It focuses on real usability, not just compliance.

Does assistive technology testing improve UX?

Yes. It ensures your product works in real-world conditions for all users.

Quick take

If your product doesn’t work with assistive tech, it doesn’t work for a lot of people.

LET'S WORK TOGETHER

Ready to improve your product?

UX, research and product leadership for teams tackling complex digital services.

Previous feedback

I had a fantastic experience working with Andy. One of his most impressive achievements during our time at NHS HEE was masterminding a deeply complex information architecture for a new platform that brought together a large number of legacy websites.

Will Parkhouse

Senior Content Designer