Or: Why You Should Be Talking to Disabled People
You can’t design for people you’ve never talked to. And you can’t assume accessibility works if you’ve never asked someone who actually needs it.
This chapter isn’t about shaming anyone. It’s about reminding ourselves that real people are the point. Not checklists. Not compliance. Not hypothetical use cases scribbled on sticky notes.
You’re already doing user research (or you should be). Adding disabled people into the mix shouldn’t be a special project – it should be part of the process. Because accessibility isn’t extra. It’s essential.
Personas vs. People
Personas are a useful design tool. They help us think through different needs, backgrounds, and behaviors. But they’re also guesses. And when it comes to accessibility, guesses can hurt.
Accessibility personas are often oversimplified:
- “The blind user”
- “The dyslexic reader”
- “The elderly person on a phone”
These flatten lived experience into a checklist. And real people rarely fit into tidy boxes.
A persona can describe a user. A real user can tell you what the persona got wrong.
What Real Feedback Looks Like
Talking to real people gives you real answers – not assumptions.
User research with disabled people:
- Shows you how they actually use your site or service
- Surfaces pain points you didn’t even know existed
- Can shift your priorities, goals, or features entirely
You might think your form works fine until someone shows you that it takes 10 minutes and five tab loops to complete with a screen reader or that it completely breaks when they zoom in on mobile.
If it’s technically usable but functionally exhausting, it’s not accessible.
Mistakes to Avoid
Let’s not beat around the bush. These things happen more often than we’d like:
- Assuming one person’s experience speaks for everyone
- Assuming coworkers who use assistive tech will test things for you
- Turning someone into a mascot or story rather than a collaborator
- Thinking you’re done because someone “figured it out”
Just because someone found a workaround doesn’t mean your site works.
And yes, testing is a job. Your colleague who uses a screen reader already has a job. If they want to contribute feedback, that’s amazing. But don’t “volun-tell” them.
How to Involve People the Right Way
This doesn’t have to be overwhelming. It just has to be intentional:
- Start early: Don’t wait until after launch
- Pay people: Always, always pay for lived expertise
- Offer options: Not everyone wants to be on a call. Let people give feedback in a way that works for them, like filling out a survey, writing notes, or sending a video.
- Make it accessible: Captions, transcripts, alt text, readable forms
- Partner smartly: Work with orgs that connect you to disabled testers
User research is accessibility, too.
Design with, not for
Accessibility isn’t a side quest. It’s part of how we make good things.
You’re not expected to know everything. But you are expected to listen.
There’s no shortcut for listening.
When you talk to real users, you stop designing for imaginary ones. And that’s when everything gets better.