Summary
Effective accessibility (a11y) research requires recruiting users proficient with their own assistive technology, never testing on lab computers, and translating behavioral observations into technical specifications tied to WCAG criteria. Accessible design benefits everyone: the permanent (blindness), the temporary (broken arm), and the situational (parent holding a baby). Designing for the extreme solves for the mainstream.
Accessibility research goes beyond compliance checklists. While automated tools can catch some issues, only testing with real users who rely on assistive technology reveals the barriers that truly matter.
Why Accessibility Testing Matters
Accessibility, often abbreviated as a11y, is the practice of making products usable by as many people as possible. While this includes people with disabilities, the benefits of accessible design extend to everyone.
The Situational Limitation Argument
Accessible design helps three groups of people:
| Category | Example | Design Solution |
|---|---|---|
| Permanent | Blindness | Screen reader support |
| Temporary | Broken arm | Keyboard navigation |
| Situational | Parent holding a baby | One-handed operation |
The Curb Cut Effect
| Designed For | Also Helps |
|---|---|
| Blind users (screen reader support) | Users with slow connections |
| Low vision users (high contrast) | Anyone using a phone in bright sunlight |
| Deaf users (captions) | Anyone watching in a noisy environment |
| Motor impairments (keyboard navigation) | Anyone with a temporary injury |
Use this table when stakeholders question the ROI of accessibility work. The audience is far larger than they assume.
Recruiting and Screening Protocol
Finding the right participants for accessibility research requires a different approach than general usability testing.
Screen for Tools, Not Conditions
Do not just ask "Are you blind?" or "Do you have a disability?" Instead, screen for proficiency with specific assistive technologies:
- "Do you use a screen reader (e.g., JAWS, NVDA, VoiceOver) daily?"
- "What is your primary input method (keyboard, voice control, switch device)?"
- "How long have you been using this assistive technology?"
The "Bring Your Own Device" Rule
Never test on a lab computer. A screen reader user has highly customized settings:
- Speech rate (often 2-3x faster than default)
- Custom keyboard shortcuts
- Specific verbosity preferences
- Trained voice profiles
Testing on a generic machine produces invalid data. The participant will be fighting unfamiliar settings rather than evaluating your product.
Session Setup Checklist:
- Participant uses their own computer with their own configured assistive technology
- Allow extra time for sessions (typically 1.5x a standard session)
- Ensure your prototype or product is accessible via the participant's remote setup
- Have a backup plan if screen sharing causes issues with assistive tech
Where to Recruit
Move beyond general panels to specialized sources:
- Accessibility-focused agencies: Organizations that specialize in disability research recruitment
- Community outreach: Disability advocacy groups, centers for independent living
- Assistive technology user groups: JAWS user communities, VoiceOver forums
- University disability services: Students often eager to participate
For the fundamentals of finding and screening research participants, see Recruiting Participants: Finding the Right People.
From Observation to Standard
The unique challenge of accessibility research is translating what you observe into specifications developers can act on.
The Translation Workflow
Your job is to translate a behavioral struggle into a technical specification:
| What You Observe | What You Report |
|---|---|
| "User couldn't find the submit button" | "Submit button is missing ARIA label, violating WCAG Success Criterion 4.1.2 (Name, Role, Value)" |
| "User didn't know the form had errors" | "Error messages not announced to screen reader, violating WCAG 4.1.3 (Status Messages)" |
| "User couldn't distinguish links from text" | "Links rely on color alone, violating WCAG 1.4.1 (Use of Color)" |
Connecting to Standards
Accessibility spans laws and technical standards [1] [2]:
- Laws (like the ADA in the U.S., EAA in Europe) create legal duties and protections
- Standards (like WCAG 2.2) define concrete technical criteria
- Research ensures real-world accessibility beyond checkbox compliance
While automated tools can check for missing alt text, only human testing reveals whether that alt text actually makes sense in context.
The Analysis Framework
When analyzing accessibility research, categorize findings by:
- Severity: Does this block task completion or merely slow it down?
- WCAG Level: Is this Level A (critical), AA (standard), or AAA (enhanced)?
- Affected Technology: Which assistive technologies are impacted?
- Fix Complexity: Is this a quick fix or architectural change?
For structured session scripts that apply these observation standards, see The Perfect Usability Test Script.
What This Means for Practice
Accessibility research is not a separate discipline—it follows the same principles as all good research. The difference is in the details:
- Recruit for tool proficiency, not disability labels
- Never use lab equipment—participants must bring their own configured devices
- Translate observations to standards—connect findings to WCAG criteria
- Remember the spectrum—you are designing for permanent, temporary, and situational limitations
The extra effort required pays off in products that truly work for diverse audiences, not just the majority case your team might implicitly assume.
For help choosing the right accessibility evaluation method, see the Research Method Explorer.
For catching accessibility issues before user testing, see Heuristic Evaluation: The Audit Before the Test. For how accessibility testing maps to core research building blocks, see Building Blocks and Core Methods.