Reviewed October 30, 2026

Accessibility User Testing: Recruiting Real Users Instead of Simulating Them

Automated scans and internal keyboard tests catch a lot, but they cannot tell you what a task feels like. How a store recruits disabled users for testing, what to pay, and how to run sessions that actually change decisions.

What testing with users catches that scans miss

An automated scan finds missing labels, contrast failures, and heading order problems. It does not find that your checkout, while technically labelled, asks a screen reader user to make a choice they cannot understand, or that your product filter, while keyboard reachable, takes forty tab stops to reach. Those are task failures, not code defects, and only a person performing the task finds them. That is the whole case for user testing, and it is a strong one: the gap between a page that passes a scan and a page a person can shop on is often larger than the gap between a failing page and a passing one.

User testing also changes internal arguments. A scan report is a list. A session recording of a customer abandoning a checkout because the error message never announced is an experience a team remembers when prioritizing. The most persuasive accessibility evidence in a product meeting is rarely a number. It is a specific person, on a specific task, hitting a specific barrier, in their own words. Recruit for that evidence deliberately.

Recruiting: where and how

Recruit through disability organizations, accessibility communities, and, where appropriate, your own customer base, with a clear description of the tasks, the time required, the assistive technology you need them to use, and the compensation. Pay properly, at consultant rates, not gift cards, because you are hiring expertise: lived experience with assistive technology is professional skill, and the quality of the session reflects the respect of the arrangement. Be specific about the technology: a screen reader user on a particular platform and browser, a keyboard only user, a magnification user, a voice control user, because each finds different barriers.

Screen for the task, not for a diagnosis. You need people who shop online regularly with their technology, not people who happen to use a screen reader once a month. A short screening conversation about shopping habits and technology setup saves a session that would otherwise be spent on setup rather than on your store. And recruit more than one person per technology, because one user is one set of habits, and a barrier that only one person hits is still a barrier, but a pattern across three is a priority.

Running the session

Give participants real tasks with real goals, not a tour of your site. Find a product in a category, buy it with a discount code, start a return, change a delivery address: the tasks your customers actually do, with the friction intact. Watch and listen without guiding. The moment a facilitator explains the interface, the test of the interface is over. Record the session, with consent, and note the exact step where the task breaks, the exact words the participant uses, and the workaround they try, because workarounds are diagnostic gold: they show what the user needed and what the interface failed to provide.

After the session, debrief while it is fresh, and thank participants concretely, including telling them what will change because of their session. That follow up is not politeness. It is retention. The same participants, brought back after fixes, are the most valuable retest you can buy, because they know the tasks and can tell you whether the barrier actually moved. Treat the panel as a relationship, not a one off purchase, and your second round will be better than your first.

Turning sessions into fixes

Write each finding as a task, a barrier, and a fix, with the session evidence attached, and prioritize by task criticality, not by defect count. A barrier in checkout outranks five barriers on a blog page, whatever the scan says about the blog. Assign owners and dates, and retest the fixed tasks with the same participants where possible. That loop, recruit, task, fix, retest, is the entire method, and it is what separates a store that did user testing once from a store whose accessibility keeps improving.

Budget honestly. A small panel, three to five participants, tested on the core shopping tasks quarterly, costs less than one complaint cycle and produces a prioritized fix list your team can actually work through. The alternative, scanning forever and never watching a person shop, is cheaper on paper and more expensive in every way that matters. Your store is not accessible when a tool says so. It is accessible when the people who need it can use it, and the only way to know that is to ask them, properly, and then to fix what they show you.

Frequently asked questions

What does accessibility user testing find that automated scans miss?

Task failures: a checkout choice a screen reader user cannot understand, a filter that takes forty tab stops to reach, an error that never announces. Scans find code defects. Only people performing real tasks find whether a page is actually shoppable.

How should I recruit disabled users for testing?

Through disability organizations, accessibility communities, and your customer base, with clear task descriptions, time, technology needed, and proper consultant rate compensation. Screen for regular online shopping with their assistive technology, and recruit more than one person per technology.

What tasks should accessibility test sessions use?

Real shopping tasks: find a product, buy it with a discount code, start a return, change a delivery address. Do not guide participants through the interface, since guidance ends the test. Note where tasks break and what workarounds participants try.

How often should a store run accessibility user testing?

A small panel of three to five participants on core shopping tasks, quarterly, is a workable cadence. Retest fixed tasks with the same participants where possible, and prioritize findings by task criticality, with checkout barriers first.