Inclusive UX Research: Designing 'With', Not 'For'
Author
Redaksi Disabilitas.com
Inclusive UX Research: Designing "With", Not "For"
In traditional software design, designers build products for users. However, in the realm of accessibility, designing software for people with disabilities often leads to patronizing assumptions and impractical solutions. The modern approach demands that we design with them.
A famous slogan in the disability community is "Nothing About Us Without Us." Based on a synthesis of research methodologies from Guide to Digital Accessibility and Inclusive Design for Accessibility, this article will dismantle the fatal flaws in traditional UX research and explain how to build truly inclusive testing sessions.
Related Insight
Why Automated Accessibility Testing Tools Are Not Everything1. The Fatal Flaw: Disability Simulation (The Blindfold Fallacy)
Many UX agencies attempt to conduct "empathy testing" by having their designers put on blindfolds, thick gloves, or earplugs, and then attempt to use their website.
This practice is heavily opposed by accessibility experts (including Jonathan Lazar and Dale Cruse). Why?
- It's Not Actual Reality: A designer who is suddenly blindfolded will experience sudden panic and confusion. Conversely, a truly blind person has lived for years with that condition; they are highly proficient at using a Screen Reader at 400 words per minute—something a blindfolded designer cannot possibly do.
- Focusing on Pity, Not Solutions: These simulations usually only produce the conclusion "Wow, it's really hard to be blind", rather than yielding objective UX data regarding where the DOM navigation fails.
The Solution: Never simulate a disability. Recruit actual people with disabilities to test your product.
Related Insight
Manual Accessibility Testing Methodology (Web & Mobile Apps)2. Expert Review vs Usability Testing
When auditing a website, you need two distinct things: an Expert Review and Usability Testing. Do not confuse the two.
A. Expert Review
Conducted by a technical accessibility auditor. Their job is to inspect the source code, verify 4.5:1 contrast, validate ARIA tags, and ensure the website technically complies with WCAG laws. This is checklist-based testing.B. Usability Testing
Conducted by disabled users (laypeople). Their job is not to find WCAG violations. Their job is to try and buy shoes on your e-commerce site. A website can pass 100% of a WCAG audit legally, but if a blind user takes 30 minutes just to find the "Checkout" button, the UX experience is a complete failure.3. The Logistics of Co-Testing with Disabled Users
Hosting an inclusive Usability Testing session requires logistical adjustments:
- Use Their Own Devices: Do not force a blind participant to use a laptop provided by your office. They have configured their Screen Reader (JAWS, NVDA, or VoiceOver), reading speed settings, and keyboard macro shortcuts on their own machine. Changing their machine ruins the test.
- Fair Compensation: Their lived experience is expert data. Pay them professionally just as you would pay an IT consultant.
- Providing Additional Accommodations: Ask in advance if they require a sign language interpreter, wheelchair access to the testing facility, or additional transcription software.
4. Data Analysis and Pity Bias
When analyzing research results, UX researchers often fall into the trap of "Pity Bias." If a disabled participant fails to complete a task, researchers often help them or excuse the failure because "it's a pity, their condition is difficult."
Related Insight
Anatomy of an Accessibility Audit Report (Bug Report & ACR/VPAT)This is an insult to the data. If a participant fails because your interface is bad, record it as an absolute UX failure. Do not treat disabled users as fragile patients; treat them as consumers (Users) who have high standards for the quality of the products they use.
5. Conclusion
Designing inclusive software cannot be done solely from behind a monitor surrounded by W3C specification books. Complying with WCAG keeps you safe from lawsuits, but inviting real people with disabilities into your UX lab is what makes your product beloved. Great design is always built from human empirical observation, not just code assumptions.
References
The critique against disability simulation (the blindfold fallacy) and the fundamental differentiation between technical compliance (Expert Review) and practical experience (Usability Testing) are extracted from methodological insights in Inclusive Design for Accessibility (Dale Cruse, Denis Boudreau). The logistical guidelines for conducting research alongside disabled participants refer to the managerial framework in Guide to Digital Accessibility (Rae Mancilla).What do you think?
Give your reaction to this article