Accessibility & Inclusive Research

The full lesson

Accessibility research is not a compliance checkbox or a final QA pass. It is a research posture — it changes who you study, when you study them, and what questions you ask. When teams skip it, they ship products that systematically exclude around one billion people worldwide who live with a disability. They also miss design improvements that would benefit everyone. This lesson covers the principles, recruiting realities, facilitation adjustments, and analysis practices that make accessibility genuinely central to your research program.

Why “Accessibility Testing at the End” Fails

The most common accessibility research pattern is one round of assistive-technology testing scheduled just before launch. This pattern fails for two reasons.

First, it treats disability as an edge case affecting a small, separate group of users. In reality, disability is a spectrum and a context. Someone with a broken arm is temporarily disabled. Someone using a phone in bright sunlight is situationally impaired. The W3C defines three types of impairment — permanent, temporary, and situational — and this model is useful precisely because it shows that accessible design is resilient design for all users, not a special accommodation for a minority.

Second, late-stage accessibility testing reveals problems that are expensive or architecturally hard to fix. A broken heading structure, a wrong focus order, or a color system built without contrast in mind cannot be patched with surface-level tweaks. Inclusive research throughout the product cycle catches these problems when fixing them is still cheap.

Building an Inclusive Recruiting Strategy

Recruiting disabled participants is the single highest-leverage change a research team can make. It is also the step most teams skip. The usual reasons are: “We don’t know how to find them,” “Our sessions aren’t set up for it,” and “We don’t want to do it wrong.” All three obstacles are solvable.

Defining Disability for Recruitment

Disability is not a monolith. For research purposes, segment by functional characteristic rather than diagnostic label:

• Vision: blind or low vision. This distinction matters — a screen-reader-fluent blind user and a user with low vision who relies on zoom have very different workflows.
• Hearing: deaf or hard of hearing. “Deaf” with a capital D refers to people whose primary language is a signed language.
• Motor: upper-limb limitations that affect pointer use; includes users who rely on switch access, eye tracking, or voice control.
• Cognitive: attention, memory, or executive-function differences; includes dyslexia and acquired cognitive impairment.
• Vestibular and seizure disorders: relevant whenever your design uses motion, parallax, or flashing content.

Your screener should ask about assistive technology use and accommodation needs — not ask participants to self-label as “disabled.” Many people who use screen readers, speech recognition, or keyboard-only navigation do not identify with a disability label, but they are exactly the users your research needs.

Where to Recruit

General-purpose panels (UserTesting, Respondent, Prolific) now include disability filters, but coverage is uneven and verification is limited. More reliable channels include:

• Disability-specific organizations and advocacy groups — local and national organizations often have community boards or research partnership programs.
• Assistive technology user communities — forums and communities for JAWS, NVDA, VoiceOver, Dragon NaturallySpeaking, and AAC device users.
• Your own product’s accessibility settings data — if users have enabled system-level accessibility features, that is a recruitment signal (use appropriate privacy safeguards and obtain consent).
• Specialized recruitment agencies — firms like Fable (disability-inclusive UX research) and AllStripes (health and disability research panels) maintain vetted disability-inclusive panels.

Keep these contacts in your research repository so they are available for every study, not just dedicated accessibility sprints.

Screening Without Excluding

Screener design can accidentally exclude disabled participants before the study even begins. Common failure modes:

• A screener that requires completing a CAPTCHA will exclude many screen-reader users.
• A screener hosted on an inaccessible survey platform — small tap targets, no keyboard navigation, no alt text on required image questions — will produce an unrepresentative sample. Participants with lighter impairments or more workarounds will get through; those with more significant access needs will not.
• Asking “Do you have a disability?” as a yes/no question misses the full spectrum of functional impairment.

Use accessible survey platforms, test your screener with a screen reader before publishing it, and ask about assistive technology use and specific accommodation needs rather than diagnostic categories.

Designing Accessible Research Sessions

Recruiting inclusive participants means nothing if the session itself is a barrier. Every research format — moderated interviews, usability tests, diary studies, surveys — has accessibility considerations.

Moderated Sessions

Before the session:

• Ask participants in advance about their preferred communication modalities and required accommodations. Do not guess.
• Confirm whether your video-conferencing platform works with their assistive technology. Zoom has better screen-reader support than many alternatives. Check in advance whether the participant needs a different platform.
• Send materials (prototypes, tasks, discussion topics) ahead of time so participants can orient themselves without the pressure of live observation.
• Allow extra time. A 60-minute session with a screen-reader user may need 90 minutes to cover the same ground — not because the user is slower, but because the tasks involve more interaction steps that are worth observing in full.

During the session:

• Do not narrate what you see on screen (“I can see you’re tabbing through the menu”) unless the participant invites it. It interrupts their process and implies you are evaluating their competence rather than the product’s design.
• For users of signed languages, work with a qualified interpreter rather than automated captions. Brief the interpreter on technical terminology in advance.
• When testing with a screen-reader user, resist the urge to step in when a task takes longer than expected. The time-on-task and the moments of hesitation are the data.

Prototype fidelity and modality:

Static image prototypes are effectively useless for testing with screen-reader users — they expose no semantic structure. For assistive-technology research, you need either a coded prototype or a browser-based prototype with meaningful ARIA roles (labels that tell assistive technology what an element is and does) and a logical DOM order (the reading order the browser gives to elements on the page). Figma’s Prototype mode with accessibility annotations can be a useful starting point, but it does not replicate real assistive-technology behavior and should not substitute for code-based testing.

Remote vs. In-Person Trade-offs

Remote sessions remove travel barriers and are often preferable for participants who would otherwise spend significant effort getting to a research facility. However, remote sessions introduce their own access challenges: unreliable captions, screen-sharing latency that disrupts think-aloud for screen-reader users, and platform-specific assistive-technology incompatibilities. Pilot every remote study with a participant using the relevant assistive technology before your first real session.

Inclusive Survey and Unmoderated Research

Surveys and unmoderated usability tests reach larger audiences, but there is no live moderator to catch and correct accessibility barriers. That makes up-front accessibility more critical, not less.

Survey Accessibility Checklist

• All form fields have visible, persistent labels. Avoid using placeholder text as a label — it disappears when the user focuses the field, which creates problems for screen readers and users with cognitive impairments.
• Error messages use specific language and link the error to its field using aria-describedby. Do not rely only on color to signal errors — colorblind users will not see the difference.
• Rating scales and matrix questions are keyboard-navigable and have programmatic labels.
• The survey platform itself passes WCAG 2.2 AA — test with a screen reader before deploying at scale.
• Use plain language throughout: active voice, short sentences, no jargon. Plain language helps users with cognitive impairments, non-native language speakers, and low-literacy users — and it improves response quality across all populations.

Unmoderated Usability Tests

Platforms like Maze, UserZoom, and Lyssna vary in their accessibility. Confirm platform accessibility before recruiting disabled participants into an unmoderated study. Be prepared to offer a moderated alternative when the platform cannot accommodate a participant’s needs.

Analyzing Findings With an Equity Lens

Inclusive recruiting only produces inclusive insights if the analysis preserves the differences between participant groups rather than flattening them.

Avoid Majoritarianism in Synthesis

A common synthesis failure is treating findings from disabled participants as “edge cases” — noted in an appendix while the “main findings” reflect the majority non-disabled sample. This systematically underweights exactly the insights that require design change. Instead:

• Analyze disabled participant data as a first-class segment with its own affinity clusters and insight statements.
• Look specifically for divergence: where do disabled users hit barriers that non-disabled users do not notice? That divergence marks an exclusion point in the design.
• When a barrier affects even one participant in a segment that represents millions of users, the usual “frequency = importance” heuristic breaks down. A 100% failure rate among the five screen-reader users you tested is a critical finding, regardless of how it looks relative to the full participant pool.

Connecting Findings to WCAG Criteria

When an accessibility research finding maps to a specific WCAG 2.2 criterion, make that connection explicit in your deliverable. WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility. Linking your findings to it gives engineering teams a normative anchor, a legal baseline, and cleaner prioritization conversations.

The current legal baseline is WCAG 2.2 AA. Key WCAG 2.2 additions (published October 2023) that commonly surface in research include:

Criterion	What it covers	Why it matters in research
2.4.11 Focus Not Obscured (Minimum)	Focused element must not be entirely hidden by sticky headers or overlays	Keyboard and switch users lose track of where they are on the page
2.5.3 Target Size (Minimum)	Interactive targets must be at least 24x24 CSS pixels	Motor-impairment research frequently surfaces small tap/click targets as high-severity barriers
3.3.7 Redundant Entry	Users should not have to re-enter information already provided in the same session	Cognitive-load research; directly benefits users with memory and attention differences
3.3.8 Accessible Authentication (Minimum)	Authentication must not rely solely on cognitive function tests (like image-based CAPTCHAs)	Screen-reader and cognitive-impairment research; CAPTCHAs are the single most-cited authentication barrier

Note: WCAG 2.0’s Parsing criterion (4.1.1) was removed in WCAG 2.2 and should no longer be a research or audit target. Teams still citing it as a failure criterion are working from an outdated checklist.

Embedding Inclusion Throughout the Research Cycle

Accessibility and inclusive research is most powerful as a continuous posture, not a dedicated workstream.

Discovery phase: when mapping your user population, explicitly include users with disabilities in the segments you plan to study. If your product serves older adults, users in low-bandwidth environments, or users in high-stakes contexts (medical, financial), the overlap with disability is high and the cost of exclusion is severe.

Generative research: include assistive-technology users in contextual inquiry and diary studies. The goal is not just to find interface problems. It is to understand the broader context of use — what tools, workarounds, and community resources disabled users bring to the experience that your product either supports or ignores.

Evaluative research: run moderated usability tests with screen-reader users, keyboard-only users, and users with cognitive differences at every major milestone, not just before launch. A moderated session with a JAWS user before engineering builds a new navigation pattern is worth ten times the same session after the pattern is already in production.

Benchmarking: include accessibility-relevant metrics in your quantitative benchmarks. Task completion rates segmented by assistive-technology use, error rates on form completion for users with cognitive differences, and time-on-task divergence between disabled and non-disabled participants are all signals that belong in a mature research program’s standard dashboard.

Systemic tracking: track accessibility findings in your research repository with consistent tags. Over time, this creates a longitudinal record of where your product creates barriers and whether interventions are working — the same evidence base you would want for any other usability dimension.