Email accessibility in production: Why it still breaks in 2026 and what teams can do about it
On May 21, the world marks Global Accessibility Awareness Day, which celebrated its 15th anniversary this year. The day is dedicated to starting conversations around digital accessibility, inclusion, and the experiences of people living with disabilities.
To mark the occasion, Stripo hosted a discussion featuring experts who dedicate their efforts to the development of email accessibility:
- Mark Robbins, Developer Advocate at Customer.io; Email Markup Consortium admin;
- Mike Paciello, Chief Accessibility Officer at AudioEye;
- Paul Airy, Accessibility & Usability consultant; founder of Beyond the Envelope;
- Dmytro Kudrenko, Founder & CEO of Stripo.
In this article, we will look at how the numbers in the Email Accessibility Report are changing over the years, how accessibility breaks down, why it happens, why email clients strip accessible code, how to live with it, and the growing impact of AI on accessibility.
The full webinar recording is available on the Stripo YouTube channel:
Key takeaways
- The main reasons why accessibility breaks are a lack of time and a perception of accessibility as the final stage in the process, a lack of knowledge inside the team, a lack of division of responsibility, and the stripping of code by email clients.
- Email clients strip code, and ESPs don’t always generate clean markup. Marketers can’t control all of that, but they can build emails that stay readable even when parts of the code don’t make it through.
- AI summaries require many of the same conditions as accessibility, so teams that previously did not prioritize accessibility may now improve it to help AI better scan and interpret their emails.
- If the team is limited in resources, fix one component at a time: a button, a heading, or a CTA. Make it accessible, save it to the library. That’s how accessible systems get built without burning out the team.
Where email accessibility breaks down in production
Making an email accessible is always a balancing act. Working under tight deadlines, with small teams, and often with limited accessibility knowledge, marketers are expected to create emails that are clear to recipients, visually appealing, consistently rendered across email clients, and accessible to everyone. The team fixes one thing, only to break another.
There are four main reasons why accessibility still breaks in email production:
- time pressure and late involvement: Accessibility is often treated as a final QA checkpoint instead of being considered throughout the production process;
- a lack of accessibility knowledge across the team: Designers, copywriters, developers, and QA specialists may all understand accessibility differently, or not at all;
- single-person responsibility instead of a team effort: Accessibility is frequently assigned to one specialist rather than embedded into the team’s workflow;
- tooling limitations and email clients that strip accessible code: Even well-built emails can lose accessibility features because of inconsistent support across email clients.
In many cases, this happens because companies still do not treat accessibility as a business priority.
Accessibility as a discipline, as an attribute, as a feature, and more importantly, as a user interface design, is very low in the prioritization. And that’s because it is perceived as a cost of doing business as opposed to something that is really recipient-centric and recipient-focused.
The needle that barely moves: Three years of email accessibility data
For several years in a row, the Email Markup Consortium has published its Email Accessibility Report, analyzing how many marketing emails are fully accessible or contain accessibility defects.
There has been very minimal positive change over the past three years:
- 2026: 99.88% of emails contained “Serious” or “Critical” accessibility defects;
- 2025: 99.89% of HTML emails tested contained accessibility issues categorized as “Serious” or “Critical”;
- 2024: 99.97% of tested HTML emails were found to have “Serious” or “Critical” accessibility defects.
Most of the detected issues are basic, can be identified with automated accessibility checkers, and are easy to fix. The most common accessibility errors include missing dir and lang attributes.
At the same time, the report also shows improvements in the use of basic accessibility attributes. However, the report measures presence rather than quality. Teams may add these attributes simply to pass the accessibility checker, but the email will still be inaccessible if the content is unclear or unhelpful.
There are three categories involved in making an email accessible: senders, ESP tools, and email clients:
- Senders should use automated accessibility checkers to catch errors before sending an email.
- ESPs should validate generated markup, add fallbacks, and include built-in accessibility checks to make it easier for customers to create accessible emails.
- Email clients need to properly support the HTML and CSS features required to build accessible code.
It’s everybody’s responsibility. It’s the tools, it’s the senders, it’s the email clients.
The email client problem: What gets stripped and why
The problem of some email clients stripping accessible code still exists and is unlikely to disappear anytime soon. Teams need to work with this reality in mind. Let’s look at what gets stripped, why it happens, and what can be done to work around it.
Why email clients strip accessibility code
There is a common misconception that if the code is written correctly, it will work properly across all email clients. In reality, it’s not like this for many reasons: different rendering engines, different operating systems, recipient settings, and inbox environments all affect how emails are displayed.
Developing accessible emails means planning fallbacks for a large number of unpredictable environments and scenarios.
For security reasons, every email client “sanitizes” the HTML code before rendering it. During this process, tracking pixels and other potentially harmful elements are removed. This may include disabling CSS features that the client does not support, either for security reasons, performance, or other technical reasons.
Often, accessibility code is stripped along with other “risky” elements because the email client does not recognize or support it. Email client limitations cause most of these accessibility issues, not the code that marketers or developers write.
Marketers can’t fix email clients, but they can make sure that the most important parts of the code survive the most extreme conditions, so that the email remains understandable and readable for customers.
This also raises questions around responsibility and compliance risks. In many countries, accessibility regulations apply to digital communications and emails, such as the European Accessibility Act.
Who becomes responsible if a customer has configured accessibility preferences related to colors or motion, but the email client strips the sender’s code that was intended to support those settings?
And we can’t just say, “My code is accessible in the browser, and it’s the email client’s responsibility when it hits the inbox. Now it’s their fault that it’s not accessible.” But if you’re aware that the email client is making changes, it’s your fault because you’re sending it anyway. So you’re making it not accessible.
Mark Robbins,
What specifically gets stripped
Here’s which accessibility features get stripped and in which email clients this happens.
Many clients don’t fully support ARIA labels. In Outlook, accessibility-related CSS styles may break because the client uses the Microsoft Word rendering engine to display emails. Gmail strips some HTML and CSS that can affect both layout and styling.
Some email clients remove the lang= attribute from the <head> tag. CSS media queries such as prefers-reduced-motion and prefers-color-scheme, which are used to support accessibility-related HTML and CSS features, are also frequently stripped or ignored.
Not every accessibility gap in email is equally important. Some are annoying and inconsistent, like dark mode weirdness or styling differences between clients. Those can be frustrating, but they don’t always stop someone from understanding the message.
The bigger issue is when the email becomes harder to understand or navigate. If the reading order gets messy because the layout is too complex, if key content is trapped in images, if links are vague, or if the hierarchy falls apart when styles fail, that’s where it becomes a real barrier, especially for screen reader users. In email, the most important accessibility wins are usually the ones that protect clarity.
The most frequently stripped accessibility features
In its Accessibility Report 2026, the Email Markup Consortium noted that in 2026, the most frequently unsupported or stripped accessibility features were:
- ARIA attributes such as aria-label, aria-labelledby, and aria-describedby, which are important for screen readers;
- CSS pseudo-classes such as :hover, :focus, :focus-visible, :active, and :default, which are used to improve keyboard navigation, visible focus, and interactivity;
- CSS media queries such as @media (prefers-color-scheme) and @media (prefers-reduced-motion), which help adapt emails to recipient settings and accessibility preferences;
- other CSS such as color-scheme, light-dark(), cursor, and font-size-adjust.
There’s a lot that’s stripped, things like role attributes, ARIA attributes, which do cause issues, but also you don’t need them. You can build your emails without those, just using the semantic markup, and not have those issues.
Mark Robbins,
The per-client cheat sheet
Using data from “Can I Email?” and the Accessibility Report 2026, we created the following table showing which accessibility features are most often stripped in specific email clients:
|
Feature |
Gmail |
Apple Mail |
Outlook |
|
lang attribute |
full support |
full support |
full support |
|
aria-label attribute |
full support |
full support |
partial support |
|
prefers-color-scheme |
strips |
full support |
partial support |
|
prefers-reduced-motion |
strips |
full support |
partial support |
|
HTML5 semantic tags (<article>, <aside>, <details>, <figcaption>, <figure>, <footer>, <header>, <main>, <mark>, <nav>, <section>, <summary>, <time>) |
partial support |
full support |
partial support |
The above table shows that emails can create uncomfortable experiences for recipients who rely on specific accessibility settings, and in many cases, the problem lies with the email client itself.
For example, developers cannot turn off animations for customers who have reduced-motion settings enabled because the email client strips the relevant code. Similarly, developers cannot always adapt an email’s color scheme to match the recipient’s preference if the email client ignores or removes the necessary CSS.
What the recipient actually experiences
Most marketers don’t experience their own emails the way recipients with accessibility needs do. However, it’s worth imagining what it feels like to receive an email that’s hard to read or that behaves differently from what your settings should produce.
Consider this scenario. The customer has set the “reduce motion” feature in their operating system. They receive an email that contains an animated GIF. The marketer or developer disabled the GIF inside a prefers-reduced-motion media query, but Gmail stripped that media query, so the animation still plays. The recipient ends up with an uncomfortable experience they explicitly tried to avoid.
Or imagine this. A client in France receives an email written in English. The marketer correctly added the lang=”en” attribute to the <html> tag, which tells the screen reader to read the email in the correct language.
But the email client strips the <html> tag before rendering the message. The screen reader, configured for French, is trying to pronounce the English text using French pronunciation rules. The message sounds like gibberish.
This affects subscriber experience, brand reputation, and compliance.
Why is the needle moving so slowly? Because some of the challenges require a bit more thought and a bit more consideration.
But my confidence is that we can break through those things and establish new standards. We are using paragraphs where we weren’t before. We are using headings where we weren’t before. We’ve moved a long way from 15 years ago.
How to overcome it: The survival approach
The easiest and most reliable approach is that simple semantic code works across the board. If you send an email without any styling, just a few heading tags, and a few links, it will usually work well. Such emails will be accessible in all email clients and will survive in light mode, dark mode, everywhere. So do things as simply as possible. Most accessibility problems start to arise when you add design.
Here are several additional practices that can help:
- Duplicate key accessibility attributes where possible.
- Replace unsupported HTML5 semantic elements with <div> + role.
- Test emails after sending emails, not just before deployment.
- In Gmail, place the most important styles inline to reduce the risk of styles being stripped.
The patterns I trust most are pretty simple: use live text instead of image-based text, keep layouts simple, make link text meaningful, write alt text intentionally, and make sure the message still makes sense when the inbox strips out some of the polish. If the email still communicates the offer, the action, and the structure after the client mangles part of the code, you probably did it right.
Ryan Phelan,
I try to avoid workarounds where I can. I’d rather build something that works reliably for most cases and degrades acceptably where it doesn’t, than maintain a bunch of fragile client-specific hacks.
Data tables are a prime example. Table IDs and headers aren’t well supported across email clients, but that doesn’t mean you throw them out; it means you focus on getting the underlying table structure as semantically clean as possible so screen readers can still make sense of it even when the fancier stuff gets stripped.
The same logic applies to aria-label versus alt text. Aria-label support in email is inconsistent enough that I don’t treat it as a primary solution. Alt text isn’t glamorous, but it works, and that predictability is worth more than a clever workaround.
Paul Airy also suggested a “dark mode survival” approach. If a company has a specific brand color palette used in digital marketing, it may be worth creating an alternative palette optimized for email clients that aggressively modify colors in dark mode.
This will be a small change, for example, using off-white instead of pure white or dark gray instead of black. Customers may notice slight visual differences, but it’s still better than readability issues caused by dark mode rendering changes.
There will be a continued need for human oversight, someone to guide, refine, and advocate for better experiences as tools and teams scale. Ultimately, accessibility won’t be solved by email clients alone. It will be shaped by the people designing and building the experiences.
Accessibility is a team sport: The role-by-role breakdown
The first step is building a company-wide accessibility culture. Everyone involved, from sales teams and marketers to executives and leadership, should understand what accessibility means, what role they play in supporting it, and where their responsibility begins.
Accessibility cannot depend on a single specialist or QA checkpoint. Teams need a shared knowledge base and clear internal standards to embed accessibility at every stage of email production. This model should work from top to bottom.
That also means creating structured processes and documentation and specifying the “definition of done” at each stage: what is accessible content, accessible design, accessible code, and so on. The clearer these standards are, the easier it becomes for teams to build accessibility into their daily workflows instead of treating it as an afterthought.
We need to get people responsible for their areas, and every area needs to be responsible for making things accessible. If it’s not accessible, it doesn’t work.
Mark Robbins,
To make accessibility sustainable, teams should build a system in which accessibility exists by default rather than relying on manual fixes at the final stage.
That starts with clearly distributed responsibilities across the workflow:
- Copywriters own readable content, meaningful alt text, and descriptive link text.
- Designers own contrast, visual hierarchy, and typography.
- Developers own semantic implementation.
- QA teams own accessibility validation and testing with assistive technologies and real recipient scenarios.
The next step is adopting modular design and building an email design system: a set of rules, tokens, and pre-tested accessible components that make every email campaign more consistent.
Instead of rebuilding every email element from scratch, teams can assemble campaigns from reusable modules that already meet brand requirements and have been tested. This reduces production time, minimizes errors, and helps teams scale accessibility more efficiently.
A good email design system makes it very hard to create a bad email.
Mark Robbins,
And that is what every marketer is trying to do.
Accessibility is now an AI problem too
With the rise of AI summaries and AI-powered inboxes, AI is effectively becoming another participant in email communication. To fulfill its function and generate a useful summary, AI has to “read” and interpret the email correctly. And in order for AI to be able to “read” the email, it needs a clear hierarchical structure, semantic code, semantic markup, and meaningful alt text. That is, the same things that make emails accessible. In other words, what makes an email accessible also makes it AI-readable. Teams that may not prioritize accessibility for human users will fix it for AI summaries.
As inboxes become more AI-mediated, clean structure and understandable content won’t just help people using assistive technology; they’ll help the systems increasingly decide what gets surfaced, summarized, or prioritized before a human ever reads it. That makes accessibility both the right thing to do and a smart strategic investment.
Ryan Phelan,
Regarding whether AI can meaningfully help teams solve email accessibility issues today, we can say the following: human expertise is still necessary for both accessibility analysis and proper implementation.
AI is not great at creating raw HTML for emails because it learns from examples, and as the EMC report showed, the vast majority of marketing emails still fail accessibility checks.
But AI becomes more useful when combined with frameworks, accessible components, and email design systems. In those environments, it can help teams scale production faster while following predefined accessibility rules. Even then, human oversight remains essential.
AI can also support accessibility testing workflows. It may detect certain issues or patterns that automated checkers miss, helping teams identify potential problems earlier in production. But this still does not replace manual testing with assistive technologies and real-world recipient validation.
I tend to refer to AI as “artificial insights” rather than “artificial intelligence” because it can help, can prod, can nudge you. You can actually learn from AI, but don’t rely on it.
Paul Airy,
Where to start
Mike Paciello recommends starting with copy. Once teams begin adding alt text to all images, writing proper link text, and making descriptive CTAs instead of “click here” and “find out more,” other accessibility issues often become easier to identify and address step by step.
Paul Airy advises starting with the structure and heading hierarchy. The correct sequence of H2, H3, and H4 headings will help structure images and the text that flows around them. A clear heading hierarchy also helps recipients quickly understand what the email is about and navigate through it more efficiently. So structure first; everything else hangs off it.
Dmytro Kudrenko recommends simplifying whenever teams are limited in time or resources. Simple solutions are easy to maintain and keep accessible over time, so do it as simply as possible and build a system that allows teams to reuse components instead of recreating everything for every campaign.
Progress over perfection. Focus on making progress incrementally. It’s a win.
Mike Paciello,
But don’t stop there. Take the next step. Once you create and test a component, for example, a button with proper color contrast and accessible interaction states, add it to your email design system so it can be reused in future campaigns. That way, you won’t have to waste time and resources doing the same thing over and over again.
Apply the same approach to every new component, and over time, you will build a growing library of accessible content and reusable email modules.
There are two important things to keep in mind:
- If you build accessibility into your solutions at every stage from the very beginning of the production process, teams can avoid a lot of work down the road.
- Combining the Brand Guidelines kit with a template library helps companies survive team changes, simplifies knowledge transfer, and reduces the number of errors during transition periods.
Wrapping up
Email accessibility has come a long way in 15 years. Many things have improved thanks to specialists in this field, who raise awareness of existing problems and find practical ways to solve them.
Accessibility issues still exist, and there’s a long way to go. However, everyone involved in email production can take a step toward making emails more accessible starting today. After all, accessibility serves not only people with disabilities but also benefits people reading on the go and customers who browse in dark mode by default, as well as AI.
Check whether your alt text is actually meaningful. Replace vague button labels like “click here” with clearer calls to action, and save this button to your library for future reuse. Test your brand colors for color contrast. Every small improvement is another step toward creating emails everyone can engage with.
Subscribe to our YouTube channel to stay updated on the latest email marketing trends and insights.
FAQ
1. Which email clients strip ARIA attributes?
Yahoo! Mail, AOL, Mozilla Thunderbird, and a few other email clients strip ARIA attributes. You can check this on the “Can I email” website.
2. Does Outlook support prefers-color-scheme?
Outlook partially supports prefers-color-scheme. Outlook for macOS, iOS, Outlook.com, and Outlook for Android 2023 support them, but Outlook for Windows and Windows Mail don’t. You can check a specific email client on the “Can I email” website.
3. Is alt text legally required in email?
Yes. WCAG success criterion 1.1.1 “Non-text Content” requires alternative text for all non-text content.
4. Can AI generate accessible email code?
AI is not very good at creating accessible code because it learns from examples, most of which are not fully accessible. But you can achieve good results if you combine AI with an email design system and ready-made accessible components.
5. Does WCAG apply to emails?
Yes, as the global technical accessibility standard, WCAG does apply to emails because they are HTML-based. However, of the 86 WCAG success criteria, only some are directly relevant to email.
0 comments