Accessibility user research asks whether real people can understand and accomplish meaningful tasks—not whether a prototype looks persuasive to its designers. Its gold standard is respectful, ethical participation, a credible study method and evidence that leads to demonstrably better products.
This guide follows Shoreline Reading Room, a fictional library whose catalogue lets people find books but fails to communicate a completed reservation to some assistive-technology users. The project highlights appropriate recruitment, genuine consent, unbiased observation, cautious analysis and actionable product changes.
For formal standards-based evaluation see Digital Accessibility Testing Services; for repair work see Accessibility Remediation Services. Research investigates the user’s experienced process and should not be misrepresented as a certificate of WCAG conformance.
Questions that determine whether the research is useful
- **Decision:** Which product choice or user barrier should the study illuminate?
- **People:** Whose relevant experiences and methods are missing from the current understanding?
- **Ethics:** What consent, compensation, privacy and reasonable accommodations are required?
- **Evidence:** Which observations will trigger a testable design or service change?
Choose a practical research route
23-chapter research index
Plan the question and recruit respectfully · chapters 1–8
- Accessibility research begins with what a person can actually do
- Define the decision the research needs to inform
- Separate user research from formal WCAG conformance evaluation
- Include people early, not only after development is finished
- Recruit for relevant experiences rather than simplistic labels
- Include older users without making assumptions about age
- Explain participation in plain language and allow genuine consent
- Pay people fairly for their time and expertise
Observe real tasks without bias · chapters 9–14
- Prepare an accessible research environment before inviting anyone
- Use tasks that reflect genuine decisions rather than trick questions
- Let participants choose suitable interaction methods
- Avoid coaching that conceals the original barrier
- Capture behaviour and meaning without intrusive recording
- Separate observed events from interpretation
Analyse evidence and combine standards · chapters 15–18
Act on findings and maintain trust · chapters 19–23
1. Accessibility research begins with what a person can actually do
A fictional neighbourhood library, Shoreline Reading Room, redesigns its online catalogue. Developers say book search works, and an automated accessibility test finds no serious homepage errors. During a research session, a screen-reader user locates a title but cannot tell whether the Hold button reserved it. Another participant using magnification finds the reservation deadline hidden in a collapsed panel. The product looks compliant at a glance but leaves important user decisions uncertain.
The gold standard of accessibility user research is respectful observation of meaningful tasks, combined with honest interpretation and actionable improvement. Research is not an examination in which participants must prove their ability. It asks whether the product supports people with varied abilities, experiences and tools. Shoreline Reading Room and the sessions are fictional. The case distinguishes user research from code-only testing or a technical conformance audit, both of which remain valuable but answer different questions.
Back to research index · Next chapter
2. Define the decision the research needs to inform
A research project should start with a practical uncertainty: can people discover a book, understand borrowing conditions, reserve it and recover when a hold is unavailable? Without that question, the study can produce hours of footage but no decision. The client should say what product stage and choices the findings will influence.
For the fictional library, the goal is not simply to make the interface feel modern. It is to discover which interaction prevents readers from understanding or completing a reservation. Define the task, user contexts, current assumptions and relevant boundaries. The research lead should know whether findings will inform a concept prototype, a specific component or a live service revision, and who has authority to act.
Back to research index · Next chapter
3. Separate user research from formal WCAG conformance evaluation
Accessibility testing examines success criteria, supported technologies and observed failures against a defined standard. User research investigates how people understand, navigate and experience an actual service, including problems that may not be captured by any single criterion. The methods complement one another rather than compete.
W3C’s Involving Users in Evaluating Web Accessibility explicitly recommends combining user evaluation with standards-based checks. A participant who succeeds after several confusing attempts has provided useful usability evidence, but their experience alone does not establish that every relevant WCAG criterion passes. Conversely, an evaluator can identify a programmatic label error without learning why readers struggle with a borrowing policy. Report which kind of conclusion each method supports.
Back to research index · Next chapter
4. Include people early, not only after development is finished
Waiting until the site is nearly launched can make research more expensive and reduce the team’s willingness to make meaningful changes. Short concept reviews, prototype tasks and later usability sessions can identify barriers while components are still easy to alter. Early work does not require every screen to be complete.
W3C’s guidance on involving users in projects explains benefits of including people with disabilities during planning, design and development. Shoreline Reading Room can show a rough reservation flow before implementing its final catalogue platform. Researchers should invite feedback without expecting participants to solve the product team’s design problems. Observing confusion at an early stage is valuable evidence, not an inconvenience to be hidden.
Back to research index · Next chapter
5. Recruit for relevant experiences rather than simplistic labels
People with disabilities use varied combinations of devices, skills, preferences and adaptive strategies. Two people who use screen readers may navigate in very different ways; an older participant may have strong digital expertise, while a younger user may be unfamiliar with the service. Recruitment should reflect meaningful interaction contexts, not assume disability labels predict every behaviour.
Choose participants based on the users and tasks being studied. The library might include experienced and newer screen-reader users, readers who enlarge text, people using keyboard or switch input, and ordinary mobile visitors depending on the research scope. W3C’s How People with Disabilities Use the Web gives a foundation for understanding diverse techniques. Do not treat anyone as a representative of every person sharing one diagnosis.
Back to research index · Next chapter
6. Include older users without making assumptions about age
Older people may experience changing vision, hearing, dexterity or memory, but age does not determine technical confidence. Some rely on a large text setting; others work with a smartphone comfortably and prefer an efficient interface. A study that treats all seniors as novices can both distort findings and disrespect participants.
W3C’s guidance on older users and accessibility identifies substantial overlap with disability-inclusive web standards. For Shoreline Reading Room, recruit based on actual library use and supported interaction methods, not a presumed inability to understand computers. Ask participants about relevant technology preferences rather than force them into a simplistic persona. Findings should describe observed needs, not stereotypes about a demographic group.
Back to research index · Next chapter
7. Explain participation in plain language and allow genuine consent
Research participants should understand the purpose, duration, activities, recording arrangements, data handling and compensation before agreeing. They should be able to ask questions and stop participation, subject to a clear consent process. A person invited because of an access need should never be pressured to disclose more personal information than necessary.
W3C’s inclusion guidance describes informed consent, respectful treatment and suitable compensation. Research teams in Singapore should also assess relevant privacy duties under the PDPA. A consent form hidden in a scanned PDF that a screen reader cannot access undermines the study before the session begins. Offer clear, usable information and accessible ways to ask for changes.
Back to research index · Next chapter
8. Pay people fairly for their time and expertise
People with disabilities are not free testing tools. They may spend additional time arranging transport, setting up equipment or explaining assistive techniques that the product team does not understand. Compensation, scheduling and reimbursement policies should reflect the study’s scope and local arrangements, without suggesting that payment purchases approval or a favourable quote.
Budget research participation alongside recruitment, accessible venues, interpretation, technical setup and breaks. Some participants may need flexible appointment lengths rather than a tightly packed schedule. W3C encourages appropriate compensation in its user-involvement guidance. Report recruitment incentives transparently when they may affect interpretation, but do not imply that paying a participant makes their experience invalid. Respectful logistics improve the quality of the evidence.
Back to research index · Next chapter
9. Prepare an accessible research environment before inviting anyone
A lab, online meeting or remote observation setup can itself create barriers. The venue, registration process, materials, meeting software and research tasks should accommodate the relevant participant’s tools. A researcher who cannot share a prototype with a screen reader may end up testing the research setup rather than the product.
For the library study, ensure the demonstration version is reachable, use realistic but non-sensitive test accounts, and allow participants to bring familiar devices when the design permits. Check caption, interpretation or remote access requirements before the session. A successful accommodation should not be interpreted as giving one person a special advantage; it enables them to engage with the task being investigated.
Back to research index · Next chapter
10. Use tasks that reflect genuine decisions rather than trick questions
Research tasks should be understandable and relevant to the person’s likely goals. Asking someone to ‘find the hidden accessibility setting’ tests an artificial instruction rather than whether a library catalogue supports ordinary borrowing. A realistic task has a start condition, useful goal and enough information to proceed without giving away the interface solution.
Ask a participant to find a book on a topic, check availability and place a hold for collection. Observe how they interpret the buttons and dates. Keep a task version and note if the researcher must intervene. The study should reveal whether the product makes the next action understandable, not reward people who guess what the researcher expected.
Back to research index · Next chapter
11. Let participants choose suitable interaction methods
A skilled screen-reader user may have personalised settings, commands and browser preferences. Someone using magnification may change text size and zoom dynamically. Forcing everybody to use the researcher’s standard laptop can replace realistic behaviour with a poor simulation and produce misleading findings.
Decide which environment the product intends to support and document participants’ tools without collecting unnecessary personal details. Allow familiar equipment where practical and appropriately secure. W3C’s guidance notes that problems can arise from content, browser, assistive technology or experience, requiring careful interpretation. The researcher should observe what happened rather than blame the person because they use a different interaction method.
Back to research index · Next chapter
12. Avoid coaching that conceals the original barrier
Researchers often want participants to succeed, which can tempt them to explain the interface too soon. Excessive coaching hides the moments of uncertainty that the product team needs to understand. On the other hand, allowing a person to struggle pointlessly can be disrespectful and provide little additional evidence.
Define a reasonable intervention plan before the session. First observe the attempt, then ask a neutral question, and provide assistance when it becomes appropriate. Record when help was necessary. If a participant cannot identify the Hold button, the finding is not that they failed a test. It is that the product did not convey the next action effectively under the observed conditions.
Back to research index · Next chapter
13. Capture behaviour and meaning without intrusive recording
Notes, event logs, audio or screen capture can help reconstruct an interaction. But video may reveal personal messages, account names, disability-related preferences or other details unrelated to the product. Recording should be proportionate to the stated purpose and consent, with safe storage and limited sharing.
Use test accounts and redact information where possible. If the library reserves a book for a participant, avoid collecting their genuine borrowing history merely for convenience. A research summary can explain a failed confirmation without broadcasting a recording of the person’s face or home. Maintain a clear distinction between private research evidence and public case-study permission.
Back to research index · Next chapter
14. Separate observed events from interpretation
A participant may pause at a page because an instruction is confusing, because the network is slow or because they are considering the next book. Researchers should not immediately turn every hesitation into a disability-specific problem. Observations and inferred causes need to remain distinguishable.
For Shoreline Reading Room, note that the person paused for a particular time and asked whether the hold was complete, rather than automatically label the event ‘screen-reader confusion’. Follow up respectfully to learn what the person expected. Reproduce the behaviour where feasible and compare it with programmatic or technical checks. High-quality qualitative evidence explains what happened, why the team believes it happened and what remains uncertain.
Back to research index · Next chapter
15. Investigate whether the barrier belongs to content, technology or process
A task failure may stem from missing labels, misleading words, stale inventory data, browser behaviour, third-party authentication or research setup. A design team needs to know which system it can change. Guessing that a participant ‘needs training’ may conceal an avoidable interface defect.
W3C’s user-evaluation guidance lists possible causes including web content, browser, assistive technology and user experience. The library’s confusing reservation date could arise from an unclear button label even though the screen reader announces it correctly, or from an inaccessible modal. The remedy differs. Combine observation with targeted technical investigation rather than assume every difficulty is solved by a tutorial.
Back to research index · Next chapter
16. Look for shared patterns without erasing individual differences
One participant’s experience can reveal a serious defect, but it cannot represent everyone. Small qualitative studies can identify important mechanisms and guide improvements, yet their findings should not be converted into population prevalence without suitable sampling and analysis. Research teams should describe who was included and the meaningful limits.
W3C warns that a few participants cannot support statistical generalisations across all users with similar or different disabilities. A library might observe the same unclear Hold state among several interaction methods, suggesting a broad design issue. A unique magnification problem may still warrant correction. The decision to address a defect can be justified by severity and user rights without inventing an unsupported percentage of affected customers.
Back to research index · Next chapter
17. Combine research findings with WCAG evaluation rather than replacing it
Research can reveal difficult instructions, mental models and real task consequences. Formal criteria can reveal issues that participants happen not to encounter in a small study. A complete quality programme needs both perspectives where relevant. Technical conformance does not remove the need for useful experiences, and a friendly test session does not certify WCAG conformance.
WCAG-EM 2.0 provides a five-step method for evaluating digital products against WCAG, including scope, exploration, sampling, evaluation and reporting. That is a separate methodology from recruiting people to examine usability. State which report is a conformance assessment and which contains task-based research insights; combining them without distinction produces misleading claims about product quality.
Back to research index · Next chapter
18. Give developers reproducible, humane evidence
A useful research report names the task, observed barrier, environment, user impact and possible direction for investigation. Quotes and recordings should be used with appropriate consent and privacy protection. Developers may need the starting state and screen-reader output, but not the participant’s personal diagnosis or irrelevant background.
For the fictional Hold button, document how the confirmation appeared, what the participant reasonably believed and the test conditions. Include a recommended review question, such as whether the state is labelled and announced meaningfully, rather than mandate a particular implementation without qualified analysis. A report should help a team act while preserving participants’ dignity.
Back to research index · Next chapter
19. Prioritise access-blocking problems and meaningful consequences
A confusing decorative icon and an inability to reserve an essential educational resource do not necessarily have the same urgency. Research findings should show severity, affected task, frequency of observation and confidence in the inferred cause. Accessibility and service owners can then make transparent prioritisation decisions.
A blocker affecting one participant using a supported input method can be important even if a small study has no statistical power to estimate prevalence. Do not mark a defect harmless because it was observed only once. Nor should a dramatic user quote substitute for understanding the actual failure. The objective is justified remediation and clear accountability, not a leaderboard of whose feedback sounds most compelling.
Back to research index · Next chapter
20. Retest the revised task rather than declare victory from a mock-up
After design changes, teams often show researchers a new static screenshot and report that the issue is fixed. But a changed label may not improve the actual interactive state, or may introduce another barrier. A meaningful retest checks the same goal through the relevant supported route and verifies important surrounding steps.
The library can revise its Hold control, but should then test actual reservation, pending status, date selection and confirmation. Reuse comparable task scenarios while documenting when participants or conditions differ. The improvement should be framed as tested in those conditions, not proof that no reader will ever experience another problem. A live service needs continuing feedback and regression checks.
Back to research index · Next chapter
21. Keep the research relationship respectful after publication
Participants may invest effort explaining barriers but never hear whether anything changed. A reasonable follow-up, when agreed, can thank people and explain which improvements were prioritised. Do not promise every suggestion will be implemented; give an honest account of decisions and known limitations.
Respect withdrawal and data-handling commitments throughout the life of the project. Remove personal identifiers from public case studies unless a separate, valid permission covers their use. Access-oriented research should improve the product without turning individual people into a permanent marketing illustration of disability. Fair partnerships make future work better and reduce exploitative recruitment practices.
Back to research index · Next chapter
22. The gold standard is evidence that changes the experience
Return to Shoreline Reading Room. The research team observes actual catalogue tasks, distinguishes interface and information problems, protects participants’ data, pays them fairly and gives developers actionable evidence. The revised reservation flow now communicates whether a hold has been placed and what the collection deadline means under the tested conditions.
Accessibility user research earns its gold standard when real people influence consequential product decisions and the service honestly reports what it learned. The achievement is not a gallery of participant photographs, a perfect satisfaction score or a declaration that one person speaks for everyone. It is respectful, repeatable insight that results in access people can actually use.
Worked example: finding a book is not the same as reserving it
Shoreline Reading Room is a fictional service. The example separates an observed event from the hypothesis about its cause and the next product test.
| Participant task | Observation | Research question | Next check |
|---|---|---|---|
| Find a book | Title appears in results | Is title and availability understood? | Ask participant to explain the result |
| Place hold | User unsure whether button succeeded | Is confirmation missing or poorly announced? | Inspect state and actual assistive output |
| Check deadline | Zoom user misses collapsed policy | Is timing or navigation unclear? | Retest with enlarged content |
| Return later | Old reservation state unavailable | Is task continuity broken? | Test supported account journey |
Ethical recruitment and practical evidence matrix
The study must distinguish participation, evidence gathering, technical investigation and final product ownership.
| Responsibility | Owner | Evidence of quality |
|---|---|---|
| Task and sample design | Research lead and service owner | Relevant goals and clear limits |
| Consent and accommodation | Research operations | Accessible information, dignity and fair arrangements |
| Observation | Trained facilitator | Neutral notes with help and deviations recorded |
| Technical root cause | Accessibility and engineering specialists | Reproducible component and environment findings |
| Product change | Accountable development team | Retested task outcome and documented limitations |
A Clementi-plus user research checklist
- Define meaningful tasks and the decision that results will influence.
- Recruit for relevant methods and contexts without stereotyping.
- Provide accessible consent, fair compensation and useful accommodations.
- Use test accounts and protect sensitive participant data.
- Observe the whole task and record facilitation interventions.
- Separate description, inference, confidence and technical cause.
- Avoid generalising small qualitative findings into population statistics.
- Combine user feedback with applicable WCAG conformance evaluation.
- Retest product changes and communicate what remains unresolved.
Frequently asked questions
These answers address common problems in recruitment, participant treatment, measurement and the interpretation of accessibility research.
1. How is accessibility user research different from a WCAG audit?
A WCAG audit evaluates relevant criteria and conformance within a defined product scope. User research observes how people understand and use a service in real contexts, including general usability problems not captured by one criterion. W3C recommends combining them where appropriate. A participant completing a task does not prove every criterion passes; a technically passing control may still confuse users.
2. Do researchers need participants from every disability category?
A single small study cannot cover every user and assistive strategy. Recruit participants relevant to the product, tasks and research stage while seeking diversity where possible. Explain who was not included and avoid generalising findings beyond the evidence. A single severe barrier can still merit a fix even without a statistically representative sample.
3. Is someone who has a disability automatically an accessibility expert?
They are an expert in their own experience, but cannot be expected to represent every other person with a similar diagnosis. Their real-world knowledge is valuable; technical and design specialists can investigate causes, and multiple participants help identify differences. Ask about the person’s actual interaction tools and context rather than assume medical labels determine preferences.
4. Should research participants be paid?
Compensating people appropriately respects their time and expertise. W3C recommends suitable compensation and respectful logistics. The amount and arrangements depend on local conventions and project demands. Account for travel, preparation, interpretation and access needs rather than assume participation should be unpaid because it serves an inclusion goal.
5. Can researchers film participants using assistive technology?
Only with appropriate informed consent and privacy controls. Screen or video recording can reveal messages, account information or other personal data unrelated to the task. Use test accounts, minimise retention, restrict access and separately obtain permission for any public excerpt. A recording made for internal research is not automatic marketing material.
6. When should user research happen?
Early and throughout design, with suitable check-ins after meaningful changes. Concept tests can reveal poor information structure, while later sessions assess an interactive task. Waiting until launch limits options and often increases correction costs. W3C encourages early user involvement alongside formal evaluation.
7. Does a participant’s struggle prove the interface is broken?
It is evidence worth investigating, not a complete root-cause analysis. Difficulties can involve content, browser, assistive technology, familiarity, network issues or interaction design. Record the observed state and ask neutral follow-up questions. A respectful study does not blame the participant or assume every pause has one cause.
8. Should facilitators never help during a usability session?
A rigid no-help rule can produce unnecessary frustration and weak evidence. Allow an initial authentic attempt and agree on neutral prompts and intervention boundaries in advance. Record when assistance occurred. The aim is to understand the product and support participant dignity, not make a person pass a secret test.
9. Can five participants prove a site is accessible?
No. A small qualitative study may reveal important patterns and serious individual failures, but it does not establish statistical prevalence or formal WCAG conformance. Report the methods, relevant user characteristics, tasks and limits. Combine user evidence with technical testing to address broader standards requirements.
10. How should the team prioritise findings?
Consider whether an essential task is blocked, consequences to the user, recurrence, confidence in the observed cause and remediation feasibility. Do not inflate one observation into unsupported population statistics, but do not dismiss a severe blocker because few people experienced it in a small study. Keep owners and testable follow-up actions clear.
11. What should a user-research vendor deliver?
The agreed research scope, recruitment and consent method, tasks, environments, observation summaries, suitably de-identified evidence, confidence limits, actionable findings and a plan for retest. A client should know which recommendations are grounded in observation and which are hypotheses needing technical investigation. A slide deck full of quotations without decisions is incomplete.
12. Does disability research require collecting medical diagnoses?
Usually the most relevant information concerns interaction methods, accessibility needs and project tasks. Sensitive personal information should be collected only when appropriate and lawful, with informed consent and safeguards. A participant should not be forced to disclose unrelated medical history to demonstrate a keyboard or screen-reader issue.
Official research sources and connected eduKate guides
- W3C Involving Users in Web Projects
- W3C Involving Users in Evaluating Web Accessibility
- W3C How People with Disabilities Use the Web
- W3C Older Users and Accessibility
- W3C Combined Expertise in Accessibility Evaluation
- W3C WCAG Evaluation Methodology 2.0
- Singapore PDPC Personal Data Protection Act
- eduKate — Digital Accessibility Testing
- eduKate — Accessibility Remediation
- eduKate — Accessible Forms Design
- Gold Standard Sectors & Services Directory
Standards note, October 2026: user research provides evidence about observed tasks and circumstances, not by itself a WCAG conformance certification or statistically representative claim. Studies involving sensitive personal data must follow applicable privacy law and consent arrangements. Findings should retain methodological limitations and not be presented as universal disability preferences.