Email Markup Consortium

For the first time, the 2026 Email Accessibility Report audited newsletter and marketing platforms with built-in email builders. We analyzed: • 6,909 #Substack emails • 2,189 @beehiiv.com emails • 1,468 #Shopify Email campaigns

100% triggered at least one automated accessibility failure. These findings indicate that platform defaults and generated markup have enormous influence over accessibility outcomes at scale.

The 2026 Email Accessibility Report is now live! We analyzed 376,348 HTML emails across industries, geographies and platforms. mremail.dev/3PFRAR8 #GAAD #EmailGeeks

The result: • 99.88% triggered Serious or Critical accessibility issues • Only 8 emails passed all automated checks • Most failures were basic, machine-checkable issues

In 2022, we began our Data Collection project with a clear vision for how this data could benefit the ecosystem starting with our annual accessibility reports. Today, we’re excited to announce the next major step in that vision: The Email Markup Database emailmarkup.org/en/blog/2025...

Proton Mail (@proton.me) noticed that some of their data on "Can I Email?" was outdated, and took the initiative to update it themselves. As a result, our 2025 Accessibility Report now reflects a much more accurate picture of Proton Mail’s strong accessibility support.

This kind of openness and collaboration benefits everyone in the email ecosystem. We’d love to see more email clients follow Proton Mail’s lead in sharing accurate, transparent data with the community. emailmarkup.org/en/blog/2025...

For years, email developers have relied on invisible spacing hacks to influence what appears alongside the subject line in the inbox. But there can be a cleaner, more consistent approach: a simple meta tag.

Our latest blog post explores how preview text could be standardized using a metadata-based solution, which aligns with how Google's Gmail and Yahoo Mail already support Schema structured data in emails today. emailmarkup.org/en/blog/2025... #Interoperability #standards #EmailClients

Accessibility in email is hard enough. When email clients block even the most basic accessibility features, they’re not limiting creativity; they’re limiting access.

Respecting user preferences is non-negotiable for inclusive digital communication. It's time email clients enable developers to build more accessible HTML emails.

Respecting user preferences is a basic accessibility principle, but Google's Gmail makes it nearly impossible for developers to do this. Email clients should enable developers to query the user's system or browser-level settings, like reduced motion or color scheme.

This isn't just a missed feature; it's a barrier. It may even have legal implications. Email clients are disregarding OS-level accessibility settings, and forcing users to endure experiences that may be uncomfortable and harmful. Impacting the sender's the ability to communicate with their audience

Respecting user preferences is a basic accessibility principle, but Google's Gmail makes it nearly impossible for developers to do this. Email clients should enable developers to query the user's system or browser-level settings, like reduced motion or color scheme.

Every government email message in our dataset failed to comply with accessibility requirements. This creates significant barriers for users who rely on assistive technologies. Governments have a responsibility to ensure communications, including email, are accessible to as many people as possible.

We urge public sector teams to audit their email templates, adopt accessibility best practices, and build emails with inclusion in mind. When accessibility is overlooked, critical public information becomes inaccessible to the people who may need it most.

In this article, Sarah Gallardo discusses how different the accessibility challenges between web vs email dev are: a11y.email/the-accessib...