Forem: Accessibility @ Asurion

Who Counts as ‘Human’ in Human-Centered Design?

Katrina — Wed, 09 Jul 2025 02:54:17 +0000

I’ve always thought of myself as an inclusive designer, but during Asurion’s A11y Maven Cohort 2 training, I started to realize there’s still more I need to learn and more I could be doing. While attending Axe-Con virtually this year, two talks stood out to me. One approached accessibility from a philosophical angle, and the other from a practical viewpoint. Together, they reframed how I’m thinking about inclusion and raised a question I keep coming back to:

Who do we actually mean when we say “human” in human-centered design?

This question, along with A11y accessibility training, pushed me to reflect on my own background and on the many winding paths that lead people into product design.

What we don’t talk about when we talk about the path to product design

One of the things I love most about product design is how many different paths lead here. Some designers started in art school, studying graphic design before realizing they wanted to solve more than visual problems. Others studied engineering, only to discover they missed seeing the human impact of their work. Still others came from psychology, journalism, or marketing—fields rooted in curiosity about how people think, feel, and make decisions.

I’m sure you get the point, but indulge me a bit: some of the most seasoned designers started back when the web was a playground for hobbyists and niche interests. They’ve grown with the field and now lead teams of recent grads who went through UX-specific programs.

Despite these wildly different starting points, one thing is consistent:

Everyone in this field is drawn to understanding human problems—and driven to solve them.

Ironically, though design is increasingly made up of people from diverse academic and professional backgrounds, one area remains consistently overlooked: digital accessibility. And I have a theory why.

If you do a quick search of the most common fields people leave to become designers, I think you’ll see the pattern.
For transparency, I asked ChatGPT for this list and to cite sources which I've linked at the bottom. However, anecdotally, this aligns with many of the backgrounds of designers I've come across during my time in the field.

Common Fields People Transition From Into UX or Product Design

Graphic Design / Visual Communication
Psychology / Cognitive Science
English / Journalism / Writing
Marketing / Business / Communications
Computer Science / Engineering
Anthropology / Sociology
Architecture / Industrial Design
Health Sciences / Education
Law / Political Science / Philosophy

Now ask yourself: which of these regularly teach digital accessibility?

Despite the variety of backgrounds that feed into product design, most of them don’t explicitly teach accessibility, let alone push us to question who we’re centering or leaving out. We may enter the field through different doors, but we often inherit the same blind spots.

Personally, if I reflect on my own studies in the late 2000s-early 2010s, I can’t recall a single marketing or PR class where we discussed making a press release or social media post accessible. Sure, that was a different time, but in 2025? There really shouldn't be any excuse.

We might not have flying cars, but we do have the tools to make accessibility something more than a checklist—or worse, an afterthought. It should be part of how we design, build, and test from the start. This is where Maya Sellon’s talk at Axe-Con really hit home for me.

Considering the ‘Human’ in Human-Centered Design”

In her talk, titled “Considering the ‘Human’ in Human-Centered Design” Sellon questioned the designation of “human” in human-centered design. She goes on to explain how mainstream definitions of HCD frame it as a “problem-solving method,” but rarely specify which humans are centered. And here is the problem that many other designers and I face without being aware of it. While we may be considering our users, we rarely consider which users we’re leaving out.

“Harvard Business School says HCD is a problem solving technique that puts real people at the center of the development process. I wonder who these real people are…. It wasn't until I checked the Interaction Design Foundation, co-founded by Don Norman, the father of UX, that I came across a definition that started to resonate with me. Human centered design is a practice where designers focus on people and their context…..Norman was helping designers understand their responsibility to the people they were designing for….The problem was that the designers kept overlooking the human limitations of the people who had to use their designs. As the article put it, the trouble with users is they're only human.”

Through stories, Sellon reminds us: accessibility isn’t just regulation. It’s about people. Stories like watching her Japanese mother struggle with pronunciation in a U.S. drive-thru only to be met with muffled laughter or her own struggles with a foreign language when she moved to the Netherlands — illustrating how designing for one user without considering who you’re leaving out can create real exclusion, not just theoretical.

And that’s the point. With technology increasingly shaping our lives—from AI assistants to healthcare portals—designers need to rethink who they’re building for and who they might be leaving out.

“Accessibility is not a checklist—it’s about people.” — Maya Sellon

Practical Strategies for Accessible Design

That human-centered framing sets the stage for the next talk I want to touch on, where Eric Zirlinger shifts from intention to implementation. While Sellon challenged us to reconsider who we center, Zirlinger showed us how to make accessibility more actionable in day-to-day design work.

In his talk, “Practical Strategies for Accessible Design,” Zirlinger offered tangible methods for addressing common accessibility issues—specifically around color contrast, reliance on color to convey meaning, reading order, and link text. These are areas where designers have direct influence, and his talk made them feel much more approachable, which is probably why I found his talk so impactful.

“Accessibility is complicated. If it weren’t, all designs would already be accessible.”– Eric Zirlinger

Making accessibility actionable

Rather than asking designers to memorize WCAG contrast ratios and rules, Zirlinger offered a simpler decision-making lens:

Is this element needed, helpful, or not needed to complete the user’s goal?

Needed → contrast ratio of 4.5:1

Helpful → 3:1

Not needed → no requirement

Example: Text label on a button = needed → must meet 4.5:1
Decorative icons = not needed → no contrast requirement

This avoids the overwhelming WCAG decision tree and focuses instead on intent and clarity.

He also shared a quick way to test whether you're relying too heavily on color to communicate meaning:

Use the "luminosity blend mode" in Figma.

Then, ask someone to identify all the interactive elements. If they struggle, your users will too.

Demonstration of using luminosity blend in figma

Example of 3 duplicate UI screens displaying the differences of color with and without the luminosity blend layer applied and with an added underline for accessibility links

Beyond colors and visuals, he emphasized a frequently overlooked issue: screen readers follow reading order—not layout. To ensure that assistive technologies interpret your designs correctly:

Start by defining the user’s goal.
Annotate your design components in the intended reading sequence.
Document variations at different breakpoints (desktop, tablet, mobile).

Use link text that makes sense out of context—for example, “Learn about accessibility” instead of “Learn more.”

How designers think everyone will see 'Learn More' CTAs VS

How assistive technology users actually see/hear 'Learn More' CTAs

His ultimate test:

If someone could only hear your interface, would they still understand it?

Where these talks intersect

Both Sellon and Zirlinger, in my opinion, land on the same truth:

Accessibility isn’t about checking boxes. It’s about designing with people in mind—especially those often overlooked.

Maya Sellon challenges us to question our assumptions about who we're designing for.
Eric Zirlinger shows designers how to build in accessibility without getting overwhelmed.

When those perspectives are combined, the work becomes not just compliant but truly human-centered.

The takeaway

So, after all that, what do I want you to walk away with?

A reminder to double-check who you're centering—and who you might be unintentionally excluding.
A few practical ways to build accessibility into your workflow, like:
- Using luminosity blend mode to test if interactive elements are still clear without color.
- Asking whether an element is needed, helpful, or unnecessary for the user’s goal to guide color contrast decisions.
- Defining and annotating reading order based on task flow, not just layout—especially across breakpoints.
- Writing link text that makes sense out of context, so users know where it leads even if they only hear it.
And lastly, a question that emerged as I wrote this post—one I don’t have a clear answer to yet: What role does accessibility play in AI-centered design?

As human–AI interaction and delegation become more common, how do we ensure those systems are designed to include everyone? What does accessibility look like when the “interface” is no longer a screen, but a conversation?

Again, I don’t have an answer, but I think it’s a question worth asking.

Bonus

Pick one idea from each of their talks:

Maya’s talk: Who are you centering?
Eric’s talk: What practical fix could improve the next thing you design?

Let it shape your process this week. Because accessibility isn’t just one person's job, it's everyones.

Sources:

Maya Sellon. “Considering the ‘Human’ in Human-Centered Design.” Axe-Con 2025, Deque Systems - https://www.deque.com/axe-con/sessions/considering-the-human-in-human-centered-design/
Eric Zirlinger. “Practical Strategies for Accessible Design.” Axe-Con 2025, Deque Systems - https://www.deque.com/axe-con/sessions/practical-strategies-for-accessible-design/ (I believe all talks from Axe-Con 2025 are available to watch for after creating a free account.)

The below were pulled and synthesis via ChatGPT

Springer: Accessibility and Digital Competencies of Psychology Students (2023) — https://link.springer.com/chapter/10.1007/978-3-031-62846-7_44
arXiv: Faculty Practices Around Teaching Accessibility in CS (2024) — https://arxiv.org/abs/2407.15013
Teach Access: New Accessibility Curriculum Modules (2024) — https://www.teachaccess.org/2024/10/teach-access-releases-two-new-free-online-courses-to-incorporate-concepts-of-digital-accessibility-into-existing-higher-education-curriculum/

Designing for Inclusion: Why Accessibility Personas Matter

Remi Ibekwe — Tue, 10 Jun 2025 17:02:11 +0000

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.