User Testing with Disabled Learners: How to Conduct Inclusive Research That Works

User Testing with Disabled Learners: How to Conduct Inclusive Research That Works Apr, 27 2025

When you design a learning app, a course platform, or even a simple quiz, who are you really designing for? If you’ve never tested your product with learners who have disabilities, you’re not building for everyone-you’re building for a fraction of the people who need it.

Accessibility isn’t a checkbox. It’s not a plugin you add at the end. It’s not just alt text or keyboard navigation. Real accessibility means understanding how people with physical, sensory, cognitive, or neurological differences actually use your product. And that starts with user testing-directly with disabled learners.

Why Skipping Disabled Learners Breaks Your Product

Think about this: 26% of adults in the U.S. live with a disability, according to the CDC. That’s one in four people. If your learning platform doesn’t work for them, you’re excluding millions of potential learners. But even more importantly, you’re missing real feedback that could improve your product for everyone.

Take screen reader users. If your course navigation relies on hover menus, they can’t access it. If your videos have no captions, Deaf or hard-of-hearing learners are locked out. If your quizzes use color-coded answers without labels, people with color blindness can’t tell the difference between choices. These aren’t edge cases-they’re common barriers.

And here’s the truth: fixing these issues doesn’t just help disabled learners. Captions help students in noisy dorm rooms. keyboard-only navigation helps people with temporary injuries. Simple language helps non-native speakers and people with dyslexia. Inclusive design lifts all boats.

Who to Include in Your Testing Group

You can’t test with “disabled people” as one group. Disability isn’t a single experience. You need diversity across types and levels of ability.

  • Physical disabilities: People who use wheelchairs, prosthetics, or have limited hand mobility. They may use voice control, switch devices, or adaptive keyboards.
  • Visual impairments: Blind users who rely on screen readers (like JAWS or NVDA), low-vision users who need high contrast or zoom, and people with color vision deficiencies.
  • Hearing impairments: Deaf users who need accurate captions, and hard-of-hearing users who benefit from transcripts and visual cues.
  • Cognitive and neurological disabilities: People with dyslexia, ADHD, autism, or traumatic brain injuries. They may struggle with complex layouts, time limits, or abstract instructions.
  • Temporary or situational disabilities: Someone with a broken arm, a parent juggling a baby, or someone in a bright sunlight environment. These are also real users.

Don’t assume you know what they need. Ask them. Recruit participants from disability advocacy groups, special education programs, or online communities like the National Federation of the Blind or Dyslexia International.

How to Recruit Ethically and Effectively

Don’t just post a generic call for testers. Disabled learners are often over-researched and under-compensated. Treat them as partners, not subjects.

  • Offer fair payment. $50-$100 per session is standard. Many participants rely on this income.
  • Provide multiple ways to sign up. Include text-only forms, phone options, and email contacts-not just web forms that might not be accessible.
  • Be transparent about time, tasks, and goals. Say exactly what you’ll ask them to do.
  • Don’t ask for medical documentation. You don’t need to know their diagnosis. You need to know how they interact with technology.
  • Partner with disability organizations. They often have networks of trusted participants who are used to being treated with respect.

One university team in Oregon recruited 12 participants through a local center for independent living. They paid $75 per 90-minute session and offered flexible scheduling-some tests happened over Zoom, others in person with sign language interpreters. Their feedback cut their bounce rate by 42% in just two iterations.

Designers observing a blind user navigate a course with keyboard and voice commands.

Designing the Test Environment

Your testing setup must be as accessible as the product you’re testing.

  • Use accessible video conferencing. Zoom and Microsoft Teams both support live captions and screen reader compatibility. Test them first.
  • Don’t force participants to use their own devices. Provide loaner equipment if needed-like a tablet with a screen reader pre-loaded, or a switch device.
  • Allow extra time. Some tasks take longer. Don’t rush. Don’t interrupt.
  • Ask participants how they want to communicate. Some prefer typing. Others speak. Some use augmentative communication devices.
  • Have a backup plan. If a screen reader crashes, switch to a different one. If a participant can’t use a mouse, offer voice commands or a keyboard shortcut list.

One learning platform team in Texas learned the hard way: they scheduled a test with a participant who used a head-tracking mouse. They didn’t have a compatible computer ready. The session lasted 10 minutes because the participant had to leave. That’s not user testing. That’s wasted time-and disrespect.

What to Test and How to Ask

Don’t ask, “Is this accessible?” That’s too vague. Instead, give real tasks and watch what happens.

Here are specific tasks to try:

  1. Find the next lesson in the course.
  2. Submit your quiz answers.
  3. Download the transcript for this video.
  4. Change the text size without losing layout.
  5. Pause and replay the audio without using a mouse.

Watch. Don’t guide. If someone struggles, don’t help unless they ask. Record their words: “I didn’t know this was a button,” “I couldn’t tell which option was selected,” “The audio cut out halfway.” These are gold.

Ask open-ended questions after each task:

  • “What did you expect to happen here?”
  • “What was confusing?”
  • “What would make this easier for you?”

Avoid leading questions like, “Was this easy?” or “Did you like it?” Focus on behavior, not opinion.

Common Pitfalls and How to Avoid Them

Even well-intentioned teams make mistakes. Here’s what to watch out for:

  • Assuming screen readers read everything: Screen readers skip decorative images, hidden text, and poorly labeled buttons. Test with real users, not just automated tools.
  • Using too much jargon: Words like “navigation,” “modal,” or “ARIA” mean nothing to most learners. Say “menu,” “pop-up,” or “label for the button.”
  • Ignoring cognitive load: Long paragraphs, flashing animations, and too many choices overwhelm people with ADHD or autism. Simplify.
  • Testing only in ideal conditions: People don’t use apps in quiet, well-lit labs. Test in noisy homes, on buses, with low battery, or with assistive tech that’s outdated.
  • Not documenting feedback properly: Write down exact quotes. Don’t summarize. “I can’t tell if I’m on the right page” is more valuable than “User had navigation issues.”
A student celebrates finishing a course with clear progress feedback and inclusive design.

Turning Feedback Into Action

Testing is useless if you don’t act. Build a simple tracker:

Feedback to Action Tracker
Feedback Quote Issue Type Priority Action Taken
“The buttons are too close-I keep hitting the wrong one.” Physical accessibility High Increased button spacing by 50%, added padding
“I don’t know what the progress bar means.” Cognitive accessibility Medium Added text label: “You’re 3 of 8 lessons done”
“The video has no captions.” Hearing accessibility High Added auto-generated captions + human-edited transcript

Share this tracker with your whole team. Make accessibility part of your sprint reviews. Celebrate wins: “We fixed the tab order-now three users can complete the course without a mouse.”

What Success Looks Like

Success isn’t a compliance badge. It’s when a student with cerebral palsy finishes your course without help. It’s when a Deaf learner laughs at a video because the captions got the joke right. It’s when a parent with dyslexia helps their child learn because the interface is clear and calm.

One nonprofit in Minnesota redesigned their literacy app after testing with 15 learners who have intellectual disabilities. They replaced animated icons with static images, used only simple sentences, and added a “slow mode” that pauses between steps. Their completion rate jumped from 31% to 89%.

That’s not magic. That’s inclusion.

Next Steps: Start Small, Start Now

You don’t need a big budget. You don’t need a team of experts. You just need to start.

  1. Find one disabled learner. Reach out to a local disability group or online community.
  2. Ask if they’d be willing to test a simple feature-like signing up or watching a video.
  3. Pay them. Listen. Take notes.
  4. Fix one thing. Test again.

Accessibility isn’t a project with an end date. It’s a habit. The more you test with real people, the better your product becomes-for everyone.

Do I need special tools to test with disabled learners?

You don’t need expensive software. Start with free tools: use built-in screen readers (VoiceOver on Mac, NVDA on Windows), enable captions, and test keyboard navigation. The most important tool is listening. Real feedback from real users matters more than any automated checker.

What if I can’t find disabled learners to test with?

Start by reaching out to local organizations: disability centers, special education schools, or nonprofits like the National Federation of the Blind or Autism Speaks. Many have participant lists. If you’re still stuck, partner with a university’s accessibility office-they often connect researchers with testers. Don’t wait until you have the “perfect” group. One participant is better than none.

Is user testing with disabled learners legally required?

In the U.S., the Americans with Disabilities Act (ADA) and Section 508 require digital content to be accessible to people with disabilities. While the law doesn’t say “you must test with users,” courts have ruled that compliance means real-world usability-not just technical standards. Testing with disabled learners is the best way to prove you’re meeting legal and ethical obligations.

How do I handle feedback that’s hard to implement?

Not every suggestion can be acted on right away. But every one should be acknowledged. Write it down. Explain why you can’t fix it yet. For example: “We heard you need voice navigation. We’re exploring this for our next update.” Keep a public roadmap. Disabled learners want to know their voice matters-even if the fix takes time.

Can I test with disabled learners remotely?

Yes, and often it’s better. Many disabled learners prefer testing from home where they’re comfortable and have their own assistive tools. Use Zoom or Microsoft Teams with live captions enabled. Send a pre-test checklist: “Please have your screen reader ready,” or “We’ll use keyboard-only navigation.” Offer a practice call to test connections. Remote testing removes travel barriers and often leads to more honest feedback.

12 Comments

  • Image placeholder

    Ian Cassidy

    October 31, 2025 AT 03:46

    Man, I’ve seen so many teams slap on alt text and call it a day. Real accessibility isn’t about compliance-it’s about listening. I’ve worked with folks who use switch devices, and the difference between a ‘kinda working’ UI and one that actually lets them move through content? Night and day. Stop treating accessibility like a checkbox. It’s a mindset.

  • Image placeholder

    Zach Beggs

    October 31, 2025 AT 22:31

    This is spot on. I work in edtech and we did a test with a student who has cerebral palsy. We thought our quiz was fine-until she couldn’t select answers because the buttons were too close. We fixed it in two days. Completion rates jumped. Turns out, making it work for her made it better for everyone. Simple stuff.

  • Image placeholder

    Kenny Stockman

    November 2, 2025 AT 04:03

    Big up to the author for calling out the ‘one in four’ stat-that’s not a niche. That’s your audience. And honestly? The part about not asking for medical docs? That’s huge. I’ve been in meetings where people wanted diagnosis codes like it was a medical audit. Nah. We care how they interact with the app, not what’s on their chart. Also, paying people $75/hour? Yes. Please. Too many researchers treat disabled folks as free labor. Don’t be that guy.


    And the ‘slow mode’ example? That’s gold. I’ve got a cousin with ADHD who uses that exact feature on a learning app. She says it’s the only reason she finishes anything. Simple = powerful.

  • Image placeholder

    Paritosh Bhagat

    November 3, 2025 AT 16:29

    Wow. This article is practically perfect. I mean, really. You’ve covered everything from screen readers to situational disabilities. I’ve been saying this for years: accessibility isn’t charity-it’s good design. And yet, I still see companies using ‘accessible’ as a marketing buzzword while their forms are inaccessible. Sigh. Also, please stop using ‘disabled people’ as a blanket term. It’s not one monolith. We’re talking about wildly different needs here. You’ve nailed that. 10/10.

  • Image placeholder

    Ben De Keersmaecker

    November 4, 2025 AT 07:13

    Technically, the ADA doesn’t mandate user testing-it mandates accessibility. But courts have consistently interpreted compliance as functional usability, not just WCAG compliance. So while testing isn’t codified in statute, it’s de facto required under legal precedent. Also, note that ‘alt text’ alone doesn’t satisfy success criterion 1.1.1 if the alternative text is non-informative or redundant. You need semantic structure, ARIA labels, and proper tab order. But yes-real users are still the best validators.

  • Image placeholder

    Aaron Elliott

    November 5, 2025 AT 08:46

    One must ask: is this not just another performative act of virtue signaling dressed in UX jargon? Accessibility is a legal and technical standard, not a moral crusade. The notion that ‘fixing it for disabled users helps everyone’ is statistically convenient but empirically overextended. Not every user benefits from captions. Not every user needs keyboard navigation. And yet, we are told to redesign entire platforms based on a minority’s needs. The burden of inclusion should not always fall on the majority’s infrastructure.

  • Image placeholder

    Chris Heffron

    November 6, 2025 AT 01:54

    Love this. Seriously. 😊 I’ve tested with a guy who used voice control-he kept saying ‘next’ and the system didn’t recognize it because it was trained on American accents. He had a British accent. We added accent flexibility. Took 3 hours. Changed everything. Thanks for reminding us to listen, not assume. 👏

  • Image placeholder

    Adrienne Temple

    November 8, 2025 AT 00:18

    My sister has dyslexia and she’s the reason I got into this field. She once cried because a learning app said ‘click the blue button’ but everything was gray. No labels. No text. Just color. That broke my heart. We fixed it. Now she finishes courses. And honestly? The app got better. Simpler. Clearer. This isn’t about being nice. It’s about being smart. Start small. One person. One feature. One fix. That’s how change happens. 💙

  • Image placeholder

    Sandy Dog

    November 9, 2025 AT 05:28

    Okay I NEED to say this-this post made me cry. Like, actual tears. 🥹 I’m a mom of a nonverbal autistic kid who uses a communication device. We’ve been turned away from so many apps because they ‘don’t support assistive tech.’ One time, a platform asked us to ‘just use the desktop version.’ But the desktop version doesn’t work with his eye-gaze tracker. I spent MONTHS begging them to fix it. No one listened. Until we found this one nonprofit that actually tested with us. They changed their whole interface. Now he picks his own lessons. He laughs. He learns. He feels seen. Thank you for writing this. I’m sharing this with EVERYONE. 🙏❤️

  • Image placeholder

    Nick Rios

    November 9, 2025 AT 09:31

    Just want to add-don’t forget about temporary disabilities. I broke my wrist last year and tried to take an online course. Couldn’t use a mouse. Had to navigate with keyboard shortcuts. Half the site didn’t work. I was furious. But I didn’t know how to report it. If the team had tested with someone in my situation, they’d have caught it. We’re all just one accident away from being a ‘disabled user.’

  • Image placeholder

    Amanda Harkins

    November 9, 2025 AT 16:36

    It’s funny how we treat accessibility like it’s a separate track. Like, ‘Oh, you’re doing the inclusive version.’ But the truth? Good design is inclusive design. The things that help someone with ADHD-clear structure, no distractions-are the same things that help anyone trying to learn after a long day. We’re not building for ‘them.’ We’re building for people. Period.

  • Image placeholder

    Ian Cassidy

    November 11, 2025 AT 00:26

    And if you’re still waiting for ‘perfect’ participants? Stop. One person with a switch device, one Deaf learner, one person with dyslexia-anyone-is better than zero. I had a test with a guy who used a head mouse. We didn’t have the right setup. He left after 10 minutes. We learned nothing. Next time? We bought the damn equipment. Worth every penny.

Write a comment