Skip to content
UPCOMING EVENTS:UX, Product & Market Research Afterwork23. Apr.@Packhaus WienDetailsInsights & Research Breakfast16. Mai@Packhaus WienDetailsVibecoding & Agentic Coding for App Development22. Mai@Packhaus WienDetails
UPCOMING EVENTS:UX, Product & Market Research Afterwork23. Apr.@Packhaus WienDetailsInsights & Research Breakfast16. Mai@Packhaus WienDetailsVibecoding & Agentic Coding for App Development22. Mai@Packhaus WienDetails

Accessibility Testing: Beyond Compliance

Accessibility research is not about checking boxes on a WCAG checklist. It is about testing with real users who rely on assistive technology to understand barriers that automated tools cannot detect.

Marc Busch
Updated January 8, 2024
5 min read

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.

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:

CategoryExampleDesign Solution
PermanentBlindnessScreen reader support
TemporaryBroken armKeyboard navigation
SituationalParent holding a babyOne-handed operation

The Curb Cut Effect

Designed ForAlso 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:

  1. Participant uses their own computer with their own configured assistive technology
  2. Allow extra time for sessions (typically 1.5x a standard session)
  3. Ensure your prototype or product is accessible via the participant's remote setup
  4. 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

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 ObserveWhat 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:

  1. Severity: Does this block task completion or merely slow it down?
  2. WCAG Level: Is this Level A (critical), AA (standard), or AAA (enhanced)?
  3. Affected Technology: Which assistive technologies are impacted?
  4. Fix Complexity: Is this a quick fix or architectural change?

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:

  1. Recruit for tool proficiency, not disability labels
  2. Never use lab equipment—participants must bring their own configured devices
  3. Translate observations to standards—connect findings to WCAG criteria
  4. 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.

References

  1. [1]
    (2023). "Web Content Accessibility Guidelines (WCAG) 2.2". World Wide Web Consortium (W3C).Link
  2. [2]
    (2021). "Accessibility requirements for ICT products and services (ETSI EN 301 549 V3.2.1)". European Telecommunications Standards Institute.Link

READY TO TAKE ACTION?

Let's discuss how these insights can drive your business forward.

Accessibility Testing: Beyond Compliance | Busch Labs | Busch Labs