Let me tell you something I’ve seen happen more than once.

A product is almost ready to launch. The designs are finished. Development is wrapping up. Then someone finally brings up the question no one asked earlier: “Wait… is this accessible?”

And just like that, everything slows down.

Bug tickets start coming in. Teams scramble to fix things that could’ve been avoided. Tensions rise. Timelines get tight. And something that could have been handled early on turns into a stressful last-minute cleanup.

That moment, right there, is what happens when accessibility isn’t built in from the beginning. It becomes an afterthought. Something we try to squeeze it in when it’s already too late.

As a user researcher at Asurion, I’ve been thinking a lot about how to shift that. How to help teams move from reacting to accessibility to planning for it. And one of the simplest ways to start is with something we already know how to use, personas.

This year, I attended a talk at AxeCon called User Personas: Designing for Users with Disabilities by Madison Russell and Nicola Richardson from Elsevier. It was one of those talks that just made sense. They broke down the power of accessibility personas in a way that was clear, real, and very much needed.

In this post, I want to share what I took away from that talk and why this work is going to matter across our teams at Asurion.

First, What Are Personas?

Personas are fictional profiles that represent real types of users. They’re based on real user research and help teams understand who they’re building for.

When we’re talking about accessibility personas, we’re talking about making sure users with disabilities are included in that process, not as an afterthought, but from the beginning.

What Makes Accessibility Personas Different

Accessibility personas include all the usual stuff like goals, behaviors, and frustrations. But they also help us see how someone’s disability affects the way they experience a product.

For example, they may use a screen reader, rely on voice commands, or navigate with just a keyboard. They might face barriers that others don’t even think about, like not being able to fill out a form because it doesn’t have proper labels, or struggling to understand content that’s too cluttered.
(I actually experienced this firsthand a few days ago when I accidentally turned off Bluetooth on my Mac — my mouse and keyboard stopped working, and VoiceOver kicked in. Let’s just say it was not the easiest thing to navigate.)

They also show us what does work. What helps that person feel confident, seen, and supported when they’re using a product?

The truth is, when we design with these needs in mind, we often end up improving things for everybody. More thoughtful layouts, better navigation, clearer content, things that help all users, not just those with disabilities.

Why This Matters

Accessibility personas help shift the way we think.

They remind us that accessibility isn’t just about checking a box or passing an audit. It’s about building something that works for more people, not just the majority.

These are a few ways they help:

1. They break down stereotypes. A lot of people still assume folks with disabilities don’t use tech the same way, or at all. That’s simply not true.
2. They improve user experience. When we solve for a wider range of needs, our products become more usable for everyone.
3. They lead to better ideas. Constraints spark creativity, and designing for different abilities can unlock smarter, more flexible solutions.
4. They keep inclusion front and center. Accessibility becomes something you think about from the start, not something you scramble to fix later.

What Accessibility Personas Include

A solid accessibility persona paints a clear picture of a user and their experience. It usually includes:

1. A name, age, and short backstory
2. Their goals and motivations
3. Their disability or access needs
4. Tools or assistive tech they use
5. Challenges they face when using products
6. What helps them feel supported or included
7. Quotes or phrases that reflect their voice

Adding a visual can also go a long way. It makes the persona feel more real and easier to remember. It also helps represent people who often don’t get reflected in design visuals, whether that’s race, age, mobility, or assistive devices.

How This Will Show Up at Asurion

This isn’t just a one time blog. It’s part of a larger effort I’ll be leading: creating accessibility personas for different product teams across Asurion.

Each one will be grounded in research and shaped around the real tools and features your team is building. The goal is to help bring clarity, spark better conversations, and make it easier to design with inclusion in mind.

This work will grow over time, but it starts with something simple: understanding that the people we often overlook are real. Their experiences matter. And we can design better when we center them from the beginning.

What You Can Do to Support

No matter what team you're on product, design, engineering, research there’s always a way to support accessibility and make things better for more people. Here’s how:

1. Talk about it early. Don’t wait until the end of a project to bring up accessibility. Start thinking about it from the beginning.
2. Share what you’ve got. If you have any feedback, research, or stories from users who’ve had a hard time using a product, pass it on. That stuff matters.
3. Include more voices. If you’re able to, bring people with lived experience into the conversation. Real stories help teams design better.
4. Ask the simple questions. Can someone use this with just a keyboard? Is the text easy to read? Would someone using a screen reader get what’s going on?

I’ll be building out accessibility personas for different products as part of my work at Asurion, but this kind of thinking goes beyond just one company. Whether you’re working on a small side project or a big platform, accessibility belongs in the process.

It’s not about being perfect. It’s just about caring enough to include more people.

And making sure no one is left behind in the products we build.