Start with a question, not a device checklist
A screen reader can announce every button on a page while a person still struggles to complete a purchase. A form may work with a keyboard but make it difficult to recover from an error. Usability testing helps a team understand that gap between technical operation and a workable experience. The goal is not to watch someone demonstrate assistive technology. It is to learn whether they can accomplish a meaningful task with the tools and methods they normally use.
Choose a small set of questions before recruiting. For example: Can people find the eligibility information for a service? Can they compare two options and submit a request? Which parts of the process require extra effort or guesswork? These questions keep the session focused on the product rather than treating a participant’s way of working as the problem.
Recruit for varied experiences
Assistive technology is not a single category of use. Participants may navigate with a screen reader, magnification software, voice control, switch access or a combination of tools. Even people using the same tool may have different habits, settings and levels of familiarity. Recruit according to the tasks and likely audiences for your product, rather than expecting one person to represent everyone who uses a particular technology.
When inviting participants, describe the activity, expected length and compensation clearly. Ask what they need to take part comfortably, such as permission to use their own device, a remote session, breaks or materials in a preferred format. Collect only information needed to arrange the session. If someone needs help joining a call or opening a prototype, treat that as a setup issue to resolve—not as evidence that the product being tested is difficult to use.
Prepare tasks that resemble real goals
Give participants a reason to act, not a sequence of controls to operate. “Find out whether you can change a delivery address, then try to do it” leaves room to observe how someone navigates and decides what to do. “Select the menu button, open Account and choose Address” reveals much less. Use realistic but fictional details for accounts, names and payments so nobody has to expose private information.
Check the test environment before the session. A prototype that cannot receive keyboard focus, a login that expires unexpectedly or a video-call control that blocks audio can prevent the test from reaching its intended task. Decide how you will share links and task prompts in an accessible format. If a prototype has known limitations, tell participants what they are and separate those limitations from findings about the proposed design.
Observe without taking over
At the start, explain that you are testing the product, not the participant. Ask whether they are comfortable sharing their screen or audio and how they would like to signal when they need a pause. Invite them to describe what they expect and what seems unclear, but do not require a constant spoken commentary. Some actions take concentration, and silence can simply mean that a person is working through a task.
Watch for the point where the product stops supporting progress. A participant might revisit headings to locate a section, increase magnification and lose sight of a nearby instruction, or use voice commands that match visible labels but not accessible names. Ask neutral follow-up questions such as “What were you expecting there?” before offering help. If someone becomes stuck, note where it happened, provide the minimum assistance needed to continue and distinguish assisted completion from independent completion.
Turn observations into better design
After each session, record the task, the barrier, its effect and the context in which it occurred. “Participant could not identify which field had an error after submitting the form” is more useful than “form accessibility issue.” Note the participant’s tool and relevant settings when known, without implying that the problem is limited to one setup. Protect recordings and notes according to the consent you obtained, and avoid retaining personal details that are not needed for the work.
Look across sessions for recurring patterns, while taking individual barriers seriously when they prevent an essential task. Prioritize changes by their impact on completing the task, then retest the revised experience. Automated checks and technical reviews remain useful, but they answer different questions. The strongest process combines them with direct observation—and brings people who use assistive technology back after changes are made, rather than treating one session as final approval.
