28% of your audience can’t read your emails – Here’s why

Think accessibility is just a checklist? Sarah Gallardo knows better.

In her sharp, candid, and refreshingly funny Unspam 2025 talk, Sarah, an accessibility expert and email strategist, walks the audience through the common myths that keep email stuck in the past. Drawing from personal stories, real-life audits, and years of hands-on testing, she makes one thing clear: accessibility is not just about compliance, it is about connection.

With data, humor, and hard truths, Sarah urges teams to move beyond performative efforts and start building email for everyone. Because when 28 percent of your audience is being left behind, there is no excuse to wait.

TL;DR:

• Accessibility is not a feature. It is a fundamental.
• Twenty-eight percent of your users live with a disability. If you're not designing for them, you're not designing for reality.
• Compliance alone is not enough. True accessibility means usability.
• Most common email myths come from outdated assumptions, not facts.
• Testing matters more than tradition. Web practices do not always apply to email.
• You do not have to be disabled to advocate for accessible design. You just have to care.

Get ready to unlearn what you thought you knew about accessibility and rebuild with everyone in mind.

Sarah Gallardo: So, I wanted to start with a bit of a question. How many people here have had a really great idea that ended up being completely misguided? Okay.

Storytime. When I was in fifth grade, we had a science fair, and I was super excited to submit a project. I spent a lot of time thinking about it. Then I was struck by this idea, as an artsy kid who loved to draw, that people without hands can't draw. Which is ridiculous. Please laugh, because it's a funny joke. This is a real thing I did. I decided to create a device that people without hands could use to draw. And yes, it was completely ridiculous. I was 11, so that feels like an important part of the premise.

I worked with my dad, who is really into woodworking, to build this device. The idea was that people without hands could use it to draw. Yes, that is fifth-grade me. And that is also a ChatGPT recreation, because nobody photographed this in 1991. Even though it was supposed to break barriers. It was going to be amazing. But no.

So here I am, with my project. I go to the science fair, and I’m super excited to present it to the judges. I walk him through my idea, and he completely shuts it down by pointing out that you needed hands to use the handles in my drawing box.

Yeah. I was ashamed and devastated. It was a terrible thing to realize in that moment. 

There are a couple of ways we could look at this story. The first is that we need to include people with disabilities when we’re creating something for them. That should be obvious. It would have taken just one person with an upper limb difference to point this out. Another way we could look at it is to say that maybe it could have been useful for folks with low dexterity or something like that. If we want to be really generous to 11-year-old Sarah.

But I’d like to focus on the idea that we all make mistakes. We often think we understand something, but we don’t fully get it. That’s what we’re doing here. We’re learning, unlearning, and working together to figure out reality. 

So, I’ll start with my first big myth: that accessibility only affects a small group of users.

I hear this all the time, especially from people who make decisions.

Email is all about numbers—open rates, click-throughs. Allison’s whole presentation was about numbers, and it was great. That’s what we do. Numbers are our entire thing. Everything we work on revolves around them. But does it make sense to leave out people with disabilities? No, not at all.

Twenty-eight percent of adults in the U.S. live with some kind of disability. That’s not a small number. That’s more than one in four. That’s 72 million people in the U.S. alone. And those numbers carry over to the rest of the world. It varies slightly, but the story is the same. There are a lot of people living with disabilities that you might not even be aware of.

So, my action for you on this one is to go ahead and take a picture of it. I want you to send it to your boss, or whoever sent you to Unspam today. Just send it and say, “Hey, we're going to talk about accessibility next week. It's happening.”

Alright. My second big myth is that disabled users don’t read my content.

I hear this all the time. Variations of this include, “People with disabilities don’t buy my product,” or “They don’t use my service,” or even, “I don’t see them, so they don’t exist,” which is pretty horrible. Don’t say that. People with disabilities do exist, and they are most certainly reading your emails.

There’s actually a name for this effect. It’s called the inaccessibility cycle. It happens when we create a product or service that is inaccessible. As a result, people with disabilities can’t use it. We don’t see or count them in our segments, so we assume they don’t matter or aren’t worth prioritizing. So, the product or service stays inaccessible.

Let’s reframe it. If 28 percent of your emails went to spam, you’d be on it immediately. There would be no sleep until it got fixed. But right now, 28 percent of the population is not getting your email. So yeah, let’s solve this. Let’s figure it out.

The third myth I hear, especially if the first two don’t stick, is: “Oh, we don’t need to be compliant. We’re fine. That doesn’t apply to us.” There’s this idea that HTML emails can’t be accessible, and that’s just not true. They absolutely can meet WCAG (Web Content Accessibility Guidelines) criteria. Every single day.

Also, we like to pretend that the business communications we send out aren’t covered by the ADA (Americans with Disabilities Act) or the EAA (European Accessibility Act). But they are. Just because there haven’t been many high-profile lawsuits doesn’t mean the laws don’t apply. Yes, you do need to follow them. I included a little primer for you. Feel free to take a photo and save it. It’s not from Oracle, but it has a lot of useful information to help you get started.

My fourth myth is that we “make our content accessible to disabled people.” This one is a bit harder to unpack. Because we all want to be good people, I believe that making emails accessible creates a positive outcome. But accessibility is not a gift.

We help our clients avoid lawsuits and stay within the law. I don’t know about you, but no one has ever congratulated me on not murdering someone, though maybe they should have a few times. Okay, thanks. Likewise, we’re not doing some heroic deed by helping clients follow the law.

People with disabilities already fought for and won these rights through the 504 sit-ins, the Capitol Crawl, and a whole series of civil rights actions—many of which happened before some of us were even born—which made these laws possible. It has nothing to do with us. So no, we’re not being nice. We’re not doing a favor. We are helping clients meet legal obligations.

Of course, please don’t stop. Please keep doing the work. We are making a lot of progress. Just remember why we’re doing it. We are meeting a need in our industry. We are making email better — but we’re not saving anyone.

Alright. Now that we’ve covered some of the big-picture accessibility myths, I want to get into a few email-specific ones.

The first one is this: “People with disabilities use the 'view in browser' link.”

This was one of the first things I was told when I started as an email developer. I asked my boss, “What is the 'view in browser' link for?” And they said, “Oh, accessibility.” And I said, “Oh, okay.” So then I told the next person who asked, and they told the next person, and so on. That’s how these myths keep going. We just keep repeating them.

But when I actually talked to people with disabilities about the 'view in browser' link, they almost always said something like, “Why would I use that?” Some of them might just not realize it's intended for them. Maybe if we changed the name, it would be more obvious. But I don’t think that’s the real issue. Because when you click on that link, you're loading the exact same code that’s in your email. There’s no difference. So if your email is inaccessible, it’s still inaccessible in the browser.

In fact, in some cases, the email client actually helps solve some accessibility issues for you. Things like not reading your layout table as a data table, or being able to pause animated GIFs — email clients often handle those things better than the browser does. So, in reality, the email client may be more accessible than the browser version.

That means the 'view in browser' link is not a get-out-of-accessibility-free card. We still have to do the work, and we still need to make our emails accessible. I do have a quick caveat: the "view in browser" link is still very important. I recommend using it. There are enough combinations of screen readers and email clients that provide a horrible experience, no matter how good our code is, that it's worth including.

Closely related is email myth number two, which is the idea that people with disabilities get the plain text version of your email. Before I dive into that, here’s a quick note. We usually talk about plain text emails in two different ways. One is the kind Naomi talked about yesterday: a mostly text-based HTML email, maybe with a header or footer. She had lots of great examples.

What I’m talking about is the plain text MIME type that your ESP usually auto-generates and sends alongside your HTML email. People can choose whether they receive the plain text or the HTML version. So, in this fictional myth, we assume people with disabilities just get the plain text version. We don’t need to think about accessibility because “they're not seeing” the HTML anyway. There are two problems with this. First, have you ever read that plain text message? It’s genuinely horrible. And on top of that, users have to do a lot more work just to get to the link you're trying to send them. It is not a good experience for anyone, especially someone using assistive technology. That adds extra steps and effort.

Second, 28 percent of the population is disabled. Your open rates for those plain text messages are probably way below that. Which tells us that people with disabilities are getting the HTML version of your email. There’s also this idea that screen reader users get the plain text version. Let me be super clear: they don’t. Many videos online show how screen readers work, and they clearly demonstrate users interacting with the HTML version. So yes, your HTML emails absolutely need to be accessible. There are two parts to this. First, make your HTML accessible. Second, make sure your plain text version is as equitable as possible. Clean it up, test it, and make sure it works.

Now, my third email accessibility myth is one I hear all the time, and it makes me roll my eyes. It’s the idea that alt text is all you need to make your email accessible. Right? How many of us have heard that? All the time. There’s a widespread assumption in the email marketing community that the only users we’re making things accessible for are people with low vision or no vision who use screen readers. But that’s not true. If 28 percent of the population had low or no vision and used screen readers, you’d know. The world would look very different. In reality, that number is closer to 5.5 percent.

So yes, alt text is super important, and you absolutely must write alt text for every image in your email. Even the tracking pixel. It matters. But alt text alone does not equal accessibility.

I shared an example on LinkedIn a few months ago—some of you may have seen it. It was a screenshot from my oldest kid’s inbox. They use a plugin that converts all text into a dyslexia-friendly font. If you’re a designer, you probably cringed when you saw it. It’s not pretty, and Apple’s design team would not be thrilled. But it works. That’s the goal: emails flexible enough for people to adapt them using their assistive technologies. And many assistive technologies have nothing to do with alt text.

Some people use zoom tools or increase the default text size on their device to read more easily. What happens when you zoom in on an image of text? It gets blurry. You can’t read it. You’re pinching and scrolling. It’s a frustrating experience. There are also plugins for colorblind users that adjust background and foreground colors. Again, this has nothing to do with alt text. Speech-to-text tools read all the text on the screen, but they don’t always read alt text. So if your content relies on alt text, that information may not reach them.

Of course, continue writing good alt text. But the best thing you can do is use live text whenever possible. I talk about this all the time because it's so important.

Alright, the next email accessibility myth surprised me the first time I heard it. I’m sure some of you have heard it, too. It's the idea that people with disabilities get the fallback version of a kinetic or interactive email. Let’s go back a bit. The iPhone came out in 2009. Today, iPhones are the most widely used assistive technology. You may not think of them that way, but that’s what they are. Many people with disabilities use their iPhones to interact with the digital world. Apple started building accessibility features into iPhones in 2009. Which means that people with disabilities have been receiving your kinetic emails since then.

But here’s the problem: they can’t use them. If your video doesn’t have closed captions, people with disabilities aren’t getting that content. If your carousel isn’t keyboard-navigable, it’s not usable. If your interactive email relies on inaccessible hotspots, those features are broken for them. They are getting those emails just like everyone else—on iOS Mail, which, by the way, is the most supportive client for kinetic content.

The only people getting fallback versions are those using email clients that don’t support kinetic content. That includes some users with disabilities, but not all. So you need to make sure your fallback version is also accessible. No one loves me when I say this, but aside from an accessible slider I built, most kinetic content used in emails today is not accessible. If you’re going to use kinetic content, do everything you possibly can to make it accessible. And if it’s not high-impact, consider skipping it. I did a deep dive on this on my blog, which you’re welcome to read if you want all the details. But the short version is: if it’s not accessible, it’s not worth it.

This is another one. Back in 2019, someone stood on a stage like this one and said that bulletproof buttons are accessible. They said, “It uses live text, there’s no reason to question it, and no need to test it.” That person was me. And I’m so sorry. It wasn’t just me, though. Pretty much everyone in 2018 and 2019 said the same thing—before we actually tested it.

But the problem isn’t just bulletproof buttons. The issue is VML, which is the coding language we use to make bulletproof buttons and background images render correctly in Outlook. Even though it’s a Microsoft language designed for Microsoft products, VML in Outlook creates serious issues for screen reader users.

Let me explain a few combinations of screen readers and Outlook. In some cases, users can’t read any of the content inside that VML. Sometimes the content is read twice. Sometimes you can navigate to the links, but you can’t activate them. Other times you can’t even reach them. And in some cases, it just reads out a bunch of ugly, irrelevant formatting code that has nothing to do with your actual message.

This is one of the most common failures I see when I’m doing accessibility audits. It’s a big deal, and I can’t stress that enough. If you’re not sure whether you’re using VML, here’s a clue: if your buttons have rounded corners in Outlook, or if you’re using background images in Outlook, you’re probably using VML.

Unfortunately, it’s everywhere. But it does cause real problems. So here’s my biggest piece of advice: don’t use VML. We can build really beautiful emails without it. We just need to embrace flexible design and flexible rendering. Our goal should be that every email looks a little different depending on the email client. That’s the point. We want users to be able to engage with the content in the way that works best for them.

Here’s another one I hear a lot: that web accessibility solutions work in email. I wish that were true. If I could just apply the first WCAG solution and be done, my life would be so much easier. I wouldn’t have this weird hobby that no one understands. Unfortunately, they don’t work. Most web accessibility solutions don’t translate well to email, some cause major problems, and some break rendering completely. The list is long. Things like HTML landmarks, ARIA labels, and other go-to strategies from the web accessibility world require a ton of extra research and testing in email.

Now, I love my fellow email developers. But when I share something I’ve discovered, a lot of them do two seconds of Googling, grab the first result, and treat it as gospel. That’s great for quick answers, but if you’re not testing or digging into the real behavior, you can’t confidently stand up here and tell people what works. Take bulletproof buttons. I told everyone they worked. But I hadn’t tested them. When I finally did, I found out they were a mess.

We have to test all the time. Web developers have it easier than we do. But we already know that. We’re in email. We work ten times harder to get the same result, and we live with that. I want to call out another great resource: caniemail.com. I’m sure many of you use it. It’s great for looking up attribute support across email clients. It works really well, except when it comes to accessibility attributes. Those vary a lot depending on the context and the client. So as much as I love that site, treat it as a starting point, not the final word. You still have to test.

Zooming out from email myths, I have two final myths I want to share. The first one is the belief that accessibility only needs to be solved once. I wish that were true.

I’ve trained more than a hundred designers and developers on accessibility best practices. It’s part of my job at Oracle. And even though we have some of the best talent, things still fall through the cracks. Don’t tell them I said that.

But really, it takes a lot of effort to get an entire organization aligned on building accessible content from start to finish. It’s a big lift. You bring in one new person, and suddenly your alt text gets ignored. You end up with line breaks in the wrong places or headings that are totally out of order. So yes, we have to keep checking in and making sure we’re on track. And since this is still email, email clients change what they support all the time, so we have to keep testing and adjusting.

Now, my last myth—and this is the one I think is the most important—is the belief that you have to be disabled or know someone with a disability to talk about accessibility. I think there’s this idea that only really passionate people can talk about it. And I mean, I’m passionate. I like talking about it. But honestly, I want you to be able to talk about accessibility like it’s just another Tuesday in the office. Because that’s what it should be.

This work is important. We need all of you to stay involved, keep moving this forward, and make more of our emails accessible. You don’t need to be disabled, know someone with a disability, or say it perfectly. I don’t care if you say “disabled people” or “users with disabilities.” Just say it. Just keep talking about it. That’s how things change. It doesn’t matter what you thought before you came in here. What matters is what you do next.

So thank you so much. You can find me on LinkedIn. I post a lot of my blog content there if you want to read more about what I’m working on.