Disabled User Research for Product Teams

Plan inclusive user research with practical guidance for recruiting disabled participants, arranging accommodations and adapting methods.

What disabled user research does—and does not—test

Disabled user research for product teams involves disabled people in discovery, interviews, prototype evaluation and usability testing. It is not a final accessibility check.

A study should answer three separate questions:

Does the product meet relevant accessibility standards?
Can the participant access the research activity?
Does the product work in that person’s usual context, technology and routines?

Research sessions reveal contextual barriers, workarounds and priorities. They do not certify conformance. W3C recommends combining user involvement with WCAG conformance evaluation.

No participant represents an entire impairment group. Record the task attempted, device, browser, assistive technology and study conditions alongside findings. This guide covers recruitment, participation preferences, method adaptations and reporting limits. See our guide to UX research methods.

Recruit disabled participants without screening by diagnosis

Start with likely product users and the interaction under study, rather than a generic list of disability categories. Translate the study into functional interaction profiles. A checkout study may need people who navigate without a pointer, use screen readers, enlarge content, enter text through alternative input methods or need more time to process complex instructions.

Ask only what is needed to establish study fit and arrange participation:

usual device, browser and operating system
input and output methods
assistive technology used for relevant tasks
preferred session format
requested support or adjustments

Section 508 guidance recommends screening for functional needs rather than diagnoses. Medical information is rarely necessary for product research; keep sensitive responses restricted and confirm the team’s privacy and consent process.

Use appropriate routes, such as existing customers, specialist recruiters and disability-led or community organisations. Explain the study clearly and do not request member lists. GOV.UK recommends varied research and recruitment approaches. Keep eligibility questions separate from accommodation questions so a request for support does not become a reason to exclude someone.

For detailed planning, see recruit disabled participants for accessibility research and participant recruitment fundamentals.

Arrange accommodations before the session

Ask every participant: “What would make taking part easier for you?” Ask early, repeat the invitation before the session and do not infer needs from a disclosed condition.

Offer choices for communication channel, timing, breaks, camera use, response mode and document format. Department for Education guidance describes informed consent as requiring accessible communication and paperwork.

For remote research, test the joining flow, captions or interpretation, screen sharing and prototype compatibility with the participant’s preferred setup. For in-person sessions, confirm step-free access, room layout, toilets, arrival arrangements, emergency information and space for personal equipment or support people.

Give every agreed adjustment an owner and confirmation deadline. Include accessible consent materials, interpreter or captioner bookings, joining instructions and payment arrangements. Build these checks into research operations rather than treating them as exceptions.

A hypothetical example: a participant asks to give written answers in chat rather than speak during a remote prototype session. The researcher keeps the same checkout task and follow-up questions, shares instructions in advance and allows time for written responses. The logistics change; the research objective remains fixed.

Choose and adapt accessible research methods

Choose the method for the question. Interviews help you understand experiences and needs. Contextual observation shows how people work in their environment. Usability testing examines interaction with a product or prototype.

Choose remote, in-person, synchronous or asynchronous participation according to the research question and participant preference. An asynchronous diary can suit activity over time but cannot provide live follow-up at the moment a prototype issue occurs. A live remote session permits follow-up only if the research platform is usable for that participant.

Run basic accessibility checks before asking participants to use a prototype. Resolve blockers that prevent the intended task from starting. Let people use familiar assistive technology and settings where feasible, then record adaptations to task delivery, pacing, response format and breaks.

This record helps distinguish between a product barrier, research-platform failure, task-design problem, facilitator intervention and technology compatibility issue. User sessions provide contextual usability evidence; they do not certify WCAG conformance. Consider the trade-offs in human-moderated versus AI-moderated research before automating an inclusive study.

Moderate accessible user interviews respectfully

Make the session usable from the first minute. Introduce observers, interpreters and support people, explain their roles and confirm consent in the participant’s preferred format.

Address the participant directly rather than speaking through an interpreter, assistant or companion. GOV.UK advises researchers not to guess what someone can do and to ask before helping.

Ask before changing a device setting, taking control of a screen or altering a task. Give clear instructions and time to read, navigate, think and respond. Do not complete someone’s words or treat silence as failure.

Treat breaks, fatigue and a switch in communication mode as planned accommodations. End by asking whether the research process itself created barriers, then record those separately from product findings. Read more about accessible interviews involving interpreters.

Analyse findings without overgeneralising

Describe what happened before deciding why. Record the task, interaction, device, browser, assistive technology and relevant setup. Separate product barriers from research-platform failures, prototype limitations, facilitator interventions and known compatibility issues.

Report consented characteristics relevant to the study without unnecessary medical detail. State sample and method limits plainly. One person’s experience can identify a barrier in that context; it is not a claim about everyone with the same disability.

Triangulate user evidence with expert review, technical testing and conformance evaluation. Prioritise findings by user impact, task criticality, frequency within the observed sample and confidence in the identified cause. Our guide to turning research insight into product action covers the handoff.

Use the access-needs-to-method planning matrix

Use one row for each participant need or study dependency. This copyable matrix keeps the research question fixed while making recruitment, delivery and ownership explicit.

Research objective	Functional interaction profile	Recruitment evidence	Participation preference	Likely barrier	Agreed accommodation	Owner	Confirmation deadline	Method adaptation	Validity risk	Fallback

Here is a filled hypothetical example for a remote moderated prototype study assessing whether existing customers can find, compare and submit a service request.

Research objective	Functional interaction profile	Recruitment evidence	Participation preference	Likely barrier	Agreed accommodation	Owner	Confirmation deadline	Method adaptation	Validity risk	Fallback
Find and submit a request	Keyboard-only navigation	Uses a keyboard for relevant web tasks	Remote, live session	Pointer-dependent prototype controls	Keyboard test completed; task link sent in advance	Accessibility specialist	2 working days before	Same core task; instructions available aloud and in chat	Prototype differs from production	Test a stable build or reschedule
Find and submit a request	Screen-reader use	Uses a screen reader on their usual device	Remote using own setup	Prototype labels or platform block the task	Test joining flow and prototype with stated browser and screen reader	Researcher	2 working days before	Participant controls their device; researcher observes with consent	Screen sharing may not show all output	Verbal walkthrough and consented recording
Compare options	Captions or interpretation	Requests communication support	Live remote session	Spoken instructions inaccessible	Captions or booked interpreter; accessible consent format	Operations owner	5 working days before	Questions and task wording shared in advance	Pace may affect discussion	Written follow-up
Understand eligibility	Additional processing time	Participant requests a longer session	Shorter session with a break	Dense instructions and fatigue	Plain-language task cards; scheduled break	Researcher	2 working days before	Keep task sequence; extend timing	Reduced task coverage	Prioritise the critical task
Explain decision-making	Alternative to spoken responses	Participant prefers typing	Chat responses	Interview assumes verbal answers	Chat enabled; time for written replies	Researcher	Before invitation confirmation	Same questions in chat and speech	Observer may miss typed context	Written post-session questions

Follow the sequence: define the interaction, recruit the relevant user, ask their preference, identify the barrier, agree the adjustment, assign an owner, test it and record validity risks.

Set a go/no-go checkpoint before each session. Do not proceed if consent is inaccessible, an agreed accommodation is missing or the setup prevents the core task. Confirm handoff responsibilities across the researcher, recruiter, product team, accessibility specialist and operations owner. A maintained panel can support this work over time; see building and managing a research panel.

Frequently asked questions

How do you recruit disabled participants for user research?

Define relevant product users and functional interactions. Use suitable recruitment routes, ask about usual technology and participation preferences, and avoid requesting diagnoses that are not needed.

What accommodations should researchers offer?

Ask the participant rather than assume. Options can include accessible materials, captions or interpretation, flexible timing, breaks, alternative response modes, familiar assistive technology and accessible venues.

Should disabled participants use their own assistive technology?

Prefer familiar setups where feasible because personal configurations affect real use. Test the research platform and prototype in advance, then document the setup observed.

Does research with disabled users replace accessibility testing?

No. Research reveals contextual usability barriers and experiences. Technical and standards-based evaluation checks broader conformance. Product teams need both.

How should findings from a small inclusive study be reported?

Report the sample, method, technologies, accommodations and study limits. Describe observed barriers precisely and avoid generalising one participant’s experience to an entire disability group.

About Glasgow Research — Glasgow Research helps B2B SaaS teams turn customer and market research into product decisions. Work with us.