The Email Markup Consortium Blog

Announcing the Email Markup Database

Fri, 12 Dec 2025 00:00:00 GMT

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.

The Email Markup Database is a comprehensive, continuously updated repository of how real-world emails are built. By scanning over a million emails, with new emails added daily, it surfaces the patterns, features, and coding techniques that real senders rely on. This is real usage metrics from real emails covering HTML and CSS features, external assets and more.

This insight offers practical value to everyone in the email ecosystem. Email clients, build tools and ESPs can learn what senders really use today, prioritize improvements with confidence and make well-informed decisions that directly benefit both email recipients and the users of their products.

We understand that feature popularity is not a good enough criterion for all products in the email ecosystem to support it. There are other factors and each product has its own constraints and architectural considerations. Nonetheless, usage data helps us ask better questions.

For example, min-width and max-width are the most used media features by a big margin. Yet in some embedding contexts (when the HTML message is rendered by webmail client that directly embeds the HTML within the same page), these media features don’t behave as the author of the code expects. The author of the code here needs container queries instead. Insights like this help highlight the gaps and give us a forum for constructive discussion on how email clients can evolve.

We’re committed to surfacing these findings publicly on an ongoing basis. We’re eager to collaborate with teams across the industry to ensure we collectively use this data wisely and pave the way for better email experiences. It is our mission.

If you work at an email client, build tool, or ESP and think this data could help guide your roadmap, we’d love to talk. We're happy to share findings and insights and hear what would be most useful to your team. Contact us at consortium@emailmarkup.org

Proton Mail rise up the accessibility rankings

Mon, 13 Oct 2025 00:00:00 GMT

Back in May 2025, we released our annual Accessibility Report. In this edition, we included a new section for the first time: Accessibility in Email Clients. The analysis in this section is based on our Email Client Feature Support Rankings, which looks at HTML/CSS feature support using data from Can I Email?.

It took an effort over a long period of time to be able to do a data-based analysis like this. Using a data-backed approach allows us to be neutral when evaluating how email clients are doing, and often allows us to reflect the real state of email clients.

However, in this case, some of the data was outdated. The Proton team have noted a lot of the support data for Proton Mail on “Can I Email?” is outdated. They took the time to update this data themselves and contribute to “Can I Email?”. This is something worth celebrating; it is not common for an email clients to document things for email developers like this, let alone do it publicly in an open source project.

After reviewing the updated data and the updated Email Client Feature Support Rankings, we see Proton Mail scores a lot higher in accessibility and the other categories than initially recorded. As a result, we have updated our Accessibility Report 2025 to reflect this.

We’ve spoken directly with Proton Mail and thanked them for their significant contribution to “Can I Email?”. They confirmed they updated the data after reading our Accessibility Report, which caused a lovely chain reaction here:

Proton Mail finds out the data on Proton Mail on “Can I Email?” is outdated
Proton Mail updates the data on “Can I Email?”
Our Email Client Feature Support Rankings gets updated with more accurate data
We and the world find out there is one more email client (Proton Mail) doing extremely well in regards to accessibility (proving to competitors it is possible!).
Through this practice, Proton Mail identifies other HTML and CSS features they can start supporting which could improve accessibility, performance or internationalisation

It is a good day for the email industry.

How email clients can improve preview text with one simple tag

Fri, 20 Jun 2025 00:00:00 GMT

For over a decade, email developers have relied on a hack to control what appears as the inbox preview text, which is often displayed next to or beneath the subject line. This "preheader spacing" hack involves stuffing hundreds of invisible characters after the desired text to manipulate how preview text is rendered by email clients.

The exact implementation changes over time as email clients change how they generate the preview text, but the concept has remained the same:

Add your preferred preview text after the opening <body> tag and before any other content
Add a few 100s special characters as HTML entities. What these characters are have changed over the years.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <div style="display:none;">
    Desired preview text

    &#8199;&#847; &#8199;&#847; &#8199;&#847; <!-- (100s more) -->
  </div>

  <div>
    <!-- Visible email content -->
  </div>
</body>
</html>

These characters create invisible padding and prevent the rest of the email content from appearing in the preview text.

This hack is just poor for everyone. Email clients try to display a helpful preview text message. Senders want to control the preview text (or add a secondary piece of text besides the subject line).

Next generation preview text

The new approach email clients are taking is to display AI-generated summary of the email message as the preview text. This approach aims to better represent what the email is actually about, but it doesn't give senders control over messaging.

A solution: use `<meta name="description">`

Web developers have long used the <meta name="description"> tag to influence how pages are previewed in search results and social media platforms. Email can do the same. We do not need to invent a new mechanism, and developers shouldn't need to rely on a trick like the preheader spacing hack.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta name="description" content="Desired preview text">
  <title>Document</title>
</head>
<body>
  <div>
    <!-- Visible email content -->
  </div>
</body>
</html>

If adopted by email clients, this method would provide a clear, standardized, and machine-readable way for senders to define preview text without resorting to hacks.

What we're proposing

For email clients:

Disregard invisible characters when generating preview text.
Support the <meta name="description"> tag as a standard developer-friendly alternative.

For senders (after email clients adopt these changes):

Use the <meta name="description"> tag to define your desired preview text.
Stop adding preheader spacing hacks that rely on hundreds of invisible characters.

Why this matters

The preheader hack bloats HTML and provides inconsistent results across email clients. It exists because of sender's needs and the lack of standards. The lack of transparent communication between email clients and developers also plays a role.

Gmail and Yahoo have allowed developers to use industry standard structured data and Schema to explicitly express marketing promotions which influence how the email is presented to the user. This highlights the need to provide developers with a proper mechanism to set the preview text or at least influence it without resorting to a hacky approach.

By moving to a standard meta tag, we make email more predictable and maintainable while giving senders a proper mechanism to explicitly set the desired content for the preview text.

Whether email clients display the text provided in the meta tag as the preview text or generate an AI summary is a product choice. Regardless, the future doesn't need the preheader spacing hack. It needs to go.

Email clients are stripping out accessibility at the expense of user needs

Wed, 28 May 2025 00:00:00 GMT

Respecting user preferences isn't a nice-to-have. It is a basic accessibility principle.

Many people rely on system-level settings, such as reduced motion or color scheme preferences, to make digital content safer, more readable, and less physically or cognitively taxing. These aren't just personalizations; they're assistive mechanisms that reflect a user's needs and sometimes their medical requirements.

But for users reading email messages in many email clients including Gmail, these preferences are ignored. Worse: these emails clients strips out the code that developers use to respect these preferences.

Email clients should support accessibility preferences

Modern browsers and operating systems allow users to set their preferences such as:

Reduced motion: important for some users to avoid triggering vestibular motion disorders
High contrast / light or dark color scheme: helps improve readability for those with certain vision conditions

On the web, developers can adapt to these settings using CSS media queries. This ensures the page's experience aligns with what users have told their devices they need.

In email, the situation is different. Many email clients, including major ones such as Gmail, fail to support these media queries and choose remove them entirely.

What the 2025 Accessibility Report shows

In our 2025 Accessibility Report, we tested several widely-used email clients for support of user preference CSS media queries. Many email clients do not support CSS media queries for prefers-reduced-motion and prefers-color-scheme, stripping them completely from the email before rendering.

This means:

Developers cannot disable animations, transitions or animated images for users who opt out of motion.
Developers cannot adjust the colour scheme of the email message to the user's preferred color scheme.
Emails may cause discomfort or harm to users who rely on these settings.

Other email clients like Apple Mail and SFR Mail show that it is possible to support these features in a privacy and security-conscious way.

Why this matters

Disregarding these user settings doesn't just result in a poor user experience, but it could also be a compliance risk. In many countries, accessibility regulations (such as the Americans with Disabilities Act and the European Accessibility Act) apply to digital communications, including email.

If a user has explicitly chosen reduced motion and an email client makes it impossible for the sender to adapt to that preference, who's responsible for the harmful experience: the sender or the email client? If the email client strips out the developer's attempt to honor that preference, the answer becomes more complicated.

A call to Gmail and other email clients

The web has set the standard: user preferences must be respected. It is an accessibility rule of thumb.

Gmail and other email clients need to rethink their approach. Their sanitization layers shouldn't disable the very features developers use to make email messages more inclusive and accessible.

We're asking for:

Support for accessibility related HTML and CSS features, such as prefers-reduced-motion and prefers-color-scheme CSS media queries
Transparent documentation about what features are allowed or stripped from HTML emails as well as recommendations for workarounds when features cannot be supported (e.g. for security or privacy reasons).
Collaboration with standards bodies and developer communities to close these accessibility gaps.

Until these features are supported, developers are stuck and recipients are left behind.

Let developers build inclusive email messages

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.

If you're working on Gmail, or any major email client: help us make this better.

Read the full 2025 Accessibility Report
Get involved and work with us on our Shared Sanitizer solution. Contact us at consortium@emailmarkup.org

Exploring using the ping attribute for click tracking

Fri, 05 Jul 2024 00:00:00 GMT

Tracking any user behavior in the digital space is a controversial topic. Nonetheless, click tracking is a widely used practice in email marketing. There are clear downsides to how click tracking is currently implements, and it is worth exploring an alternative implementation that prioritizes the user.

What is click tracking in email?

Click tracking is the practice of replacing the final destination URL with a click tracker URL in emails. Each visit to the click tracker URL counts as a click. The click tracker then redirects the user to the final destination URL.

Most ESPs do this automatically for their users. If the code contains an anchor tag like this:

<a href="https://emailmarkup.org">Email Markup Consortium</a>

It is automatically replaced with a click tracker link:

<a href="https://click.example.com?id=....">Email Markup Consortium</a>

The user first lands on the click tracker page before they are redirected to the actual page. This is often seamless and most recipients are not aware of it.

Problems

Opting out (privacy)

It is tricky for the recipient to opt out of click tracking. A lot of effort is required to prevent senders from tracking clicks. One solution is the use of email privacy protection services, such as DuckDuckGo’s Email Protection, that replaces click tracker links with the final destination URL - basically undoing what the ESP did with the links.

It is not just us who think this is a privacy concern. One of the main goals of Yahoo’s performance feeds is to provide senders with insights, such as link clicks, in a privacy conscious way.

Transparency

Given that the actual URLs are replaced by click tracker URLs, there is less transparency provided to the recipient. It’s not that the page path is different; often the whole domain is different. It makes it harder for the recipient to verify whether it is safe to follow a link.

Delays

Not all click trackers load and redirect quickly. And not all users have fast internet connections.

I personally have seen many click trackers take 5+ seconds before they redirect to the final destination URL, which may also take just as long to load or even longer. This is a perfect example of putting data collection ahead of the user experience: a user stairs at white blank screen for 5 seconds, then waits a further 5 seconds before they can interact with the page they want to visit.

In fact, this is probably a good example where senders are putting data collection ahead of conversion.

Dead URLs

Click trackers URLs are not always under the sender’s own domain. In many cases it is a domain the ESP owns. If the sender deletes an account with an ESP which they had used to send emails, what happens to the click tracker links in the inbox of the sender’s audience? In some cases, they cease to exist. This hurts both the sender and the recipients.

Exploring a native solution: the `ping` attribute

The HTML spec for the anchor tag includes a ping attribute. The attribute value accepts a valid URL. When a user clicks on an anchor tag, the browser takes the user to the URL in the href attribute, but also makes a second request to the URL in the ping attribute.

<a href="https://emailmarkup.org" ping="https://click.example.com?id=....">Email Markup Consortium</a>

This solves all three problems:

The email client can provide a privacy setting. If enabled, it is easy for the email client to strip the ping attribute.
The user is taken directly to the final destination URL. This puts the user experience ahead of data collection and minimizes the time during which the user stares at a blank screen.
If the URL of a click tracker in the ping attribute no longer exists, the user can still reach the final destination URL.

Pushback

We realize many in the marketing world would probably not favor this approach because it affects a key metric they currently track. However, we cannot tie ourselves to old practices at the cost of users privacy. Open rates was once a key metric for most email marketers is no longer accurate. Similarly, click tracking would still exist, but it wouldn’t give you the full picture either as some users may choose to disable it.

The proposed solution does not prevent the sender from adding query string parameters to the URLs (e.g. UTM parameters). This means some level of tracking would still be possible and user actions can still be attributed to specific email campaigns.

Enforcing the solution

We know it is naive to think ESPs and senders would choose to simply switch to the proposed solution. History shows us that ESPs and senders adopt new practices when major email clients announce penalties if they are not follow. If we want to see this change in the industry, major email clients will probably have to:

support the ping attribute
penalize senders who use click trackers in the href attribute of anchor tags

Support

Browser support

All browsers support the ping attribute with the exception of Firefox which has the feature behind a flag due to privacy implications.

We believe user’s privacy preferences should be respected. A major reason why people use Firefox is because of its privacy features. So unless the user has enabled the flag on Firefox, the sender should not be actively looking for ways to track what the user does not want to be tracked.

Email client support

At the time of writing only the following email clients support the ping attribute on anchor tags:

Apple Mail
T-Online
Mail.ru

A check-in on our progress with email clients

Wed, 26 Jun 2024 00:00:00 GMT

It’s always been our goal to be as transparent and open as possible. We think we owe you an update on how our efforts on getting email clients onboard our vision is going, the positives that reignite our motivations and the challenges ahead of us.

Since EMC was established we have spoken in various depths to a number of people at various roles at companies that have at least one email client as a product. These companies include Yahoo, Mailbird and IONOS (previosuly known as 1&1).

Discussed in the article:

The positives

A lot of the people we’ve spoken to agree that our vision is a good solution to the problem we are aiming to solve. That is, they welcome the idea of having a specification to follow on how HTML and CSS features are handled and/or having a open-source sanitizer any email client can use.

We also had the chance to discuss our accessibility browser extension, the Email Reader View, with some but not all of these email clients. The idea was also welcomed and some pointed out that it is a feature their audience may need.

The challenges

None of the companies we spoke with could commit to working towards this at the moment. A common theme that has come up in these conversations is if Google/Gmail are involved, then they are more likely to get involved. It is unfortunate that this is a blocker at the moment, but understandable given Gmail’s marketshare. However, we are very optimistic: email clients collaboratively work on projects such as AMP for Email and adopting standards like BIMI shows us that different competing vendors in the email space can indeed work together.

Another unexpected challenge some of these companies face, which can affect how they handle the rendering of HTML emails, is their goal to keep their users satisfied. Users often complain about how the rendering of an email message on this email client does not match how it is rendered on a major email client they also use. As a result, the company may try to match how this major email client renders email messages to some extent. We suspect there could be cases where an email client follows the EMC’s shared sanitizer specs, but also have some additional ad hoc handling on top of it and we would love to avoid that. We believe when major email clients are onboard with EMC’s shared sanitizer such issues will be minimized.

Looking ahead

We are still actively reaching out to email clients and discussing our vision as well as their pain points. We realise this is a long process and we are still committed to our vision.

If you work at (or know someone who does) a company that has an email client as a product, we would love to chat with you particularly if you are on the relevant team. Please reach out to us at admins@emailmarkup.org

Impact of accessibility work by EMC

Wed, 13 Dec 2023 00:00:00 GMT

The Email Markup Consortium launched an annual accessibility report to bring awareness to the state of accessibility within the email industry. We aim to do more than just support end subscribers who would benefit from improvements or educate marketers and email creators on crafting with better detail. Our goal is also to demonstrate to vendors the need for enhancements to the tools that marketers use to create emails. This, in turn, will provide greater value to their subscribers.

When initially releasing the report, we heard from email creators that they felt their ESPs, or email building tools, either altered their code to change the structure (which resulted in accessibility issues) or prevented them from creating an accessible email to begin with.

We are committed to using this data to advocate and push for change in our industry for the better. Since launching the report, we’ve seen a number of large vendors such as Beefree, Stripo, and Customer.io taking on feedback, engaging in discussion, and making improvements.

Beefree

The team at Beefree has been incredibly open to conversation and collaboration. Accessibility is an ongoing line of development in each of their product cycles and they continue to work on making the HTML that is generated with their builder more and more accessible with each release.

Their work is not just exclusive to the code that the tool produces, but also the accessibility of their email builder itself.

Although Beefree already offers creators an input to manually add alt-text, they understand how important this tag is on an image, and have worked on a feature with AI to automatically write the alt-text for images and ensure it is added as a tag on the image source. They are committed to not just notifying the user that they are missing an alt-tag, but also providing a proactive fix.

Another win we’ve seen with Beefree is the ability for email creators to define the language of their email, which results in the content inside the email body being wrapped in a lang attribute. This was the top-most common error in the accessibility report, with 96% of emails missing this key detail that screen readers must rely on.

We are continually grateful for this tool that provides a means for creators to build emails easily, but also with best practices in mind.

Stripo

The team at Stripo has maintained a strong interest in improving Accessibility standards — including setting a target of decreasing the failure rate from 99% to 97%. They have made a number of fixes to improve their code output, including setting a language direction and ensuring tables that require role="presentation" have the value included on it.

We’re looking forward to a continued relationship with them, and updates around changes to the platform that enable creators to build accessible emails.

Customer.io

At Customer.io, they have integrated Parcel’s Accessibility Checker into the email building experience, enabling creators to seamlessly check their code for errors.

We have also worked with the team to identify changes to email code post-send, and remediate a fix that now declares a language direction on the preheader text that previously wasn’t able to be controlled by the end user as, well as setting an empty alt attribute on the tracking pixel. Ultimately, this solved for an Accessibility issue that was previously failing.

Future vendor relations

Commonly, we see drag and drop tools present similar issues such as not assigning tables a role attribute, not assigning a lang attribute, defining a text direction, or excluding discernible texts on links. We’re grateful to the two companies above for being open to collaboration and conversation. It shows that not only email developers are interested in these improvements, but also that the companies that own building these email tools are keen to make accessibility improvements as well.

You can use the latest 2023 report as an overview in understanding what issues most commonly arise, and use Parcel’s Accessibility Checker to review presenting issues of your own.

Again, we are committed as a group to working towards improving emails standards for the industry. If you are a vendor reading this, and would like to chat about ways in which your tool may be impacting email accessibility, please reach out!

How container queries could help email

Tue, 31 Oct 2023 00:00:00 GMT

Using @media queries in email has been commonplace for the last decade or so. Although they aren’t supported in every email client, where they do work they can really help enhance the experience for users viewing the email in a variety of viewport widths among other things. Even when they are supported they don’t always preform exactly how we need them to.

Email clients embed our emails in one of 2 ways. Either the email message will be embedded in an iframe or embedded directly into the flow of the page.

When embedded in an iframe, a media query in the iframe queries the width of the iframe, not the full window. So if we set @media screen and (max-width:600px) the styles within this media query will be applied when the iframe width is 600px or less.

However, when an email is inserted directly into the page, the media query will query the width of the full window and the email message is only one small part of that. So that same query @media screen and (max-width:600px) will only trigger when the page width is 600px or less regardless of the width of the email message. Most likely, it will not trigger at all.

We could try some complex calculations to work out when the page width = X then the email wrapper width = Y but that varies for each email client and also depends a lot on the users settings and layout preference. This is not a reliable or future-proof approach.

Container Queries

Container queries address this issue, as rather than referencing the size of the viewport, they reference the size of a container that we can define in the CSS.

Now that container queries have landed in all major browsers, email clients have the choice to add support. This would allow developers to create more reliable layouts giving a better experience to the end users.

Here is some stripped back code to show how it works

<!DOCTYPE html>
<html>
<head>
  <style>
    .wrapper{
      container-type: inline-size;
      container-name: myemail;
    }
    @container myemail (max-width: 600px) {
      .wrapper h1 {
        background-color: red;
      }
    }
    @container myemail (min-width: 600px) {
      .wrapper h1 {
        background-color: green;
      }
    }
  </style>
</head>
<body>
  <div class="wrapper">
   <h1>container query test</h1>
  </div>
</body>
</html>

Here we have a <div> with a class of wrapper, in the CSS we set a container-type and container-name. Then where we would normally use @media we can instead use @container myemail referencing the name that we set on the container. This will look at the size of that <div> and trigger when our query (min-width: 600px) or (max-width: 600px) matches.

Query units

Along with container queries there are also now container query units. These are similar to viewport units but instead of being relative to the viewport size they are relative to the container size.

cqw 1% of a query container’s width
cqh 1% of a query container’s height
cqi 1% of a query container’s inline size
cqb 1% of a query container’s block size
cqmin The smaller value of cqi or cqb
cqmax The larger value of cqi or cqb

Some email clients, such as Gmail and Outlook.com, currently support container units but not containers. In this case these units will be relative to any container used in the email client, or if no container are used there are relative to the viewport.

Current support (as of October 2023)

Container queries are now supported in all major modern browsers. In email there is some support

On Android: K9, Samsung, QQ, 1&1, GMX, Web.de
On iOS: AppleMail, Edison
Webmail: Ionos, Comcast, Libero, iCloud

Seeing this support starting to come into email clients is great. However, where we really need it is in email clients that embed the email code in a webpage rather than using an iframe. These include some of the biggest names; Gmail, Yahoo, AOL, Outlook.com. All of which are yet to add support.

So things are looking promising for the future, but it’s maybe still a little too soon to have a real impact on your emails.

Current Issues

One major issue that is preventing developers from using container queries in email at the moment is with Appel Mail desktop app. When setting container or container-type the whole email is hidden. This happens both when setting this style inline or embedded.

When can we start using container queries

Currently the issue with Apple Mail is really holding developers back. Once that is fixed, then it’s certainly worth starting to experiment with container queries.

As support grows early adopters may have to start duplicating styles inside both media and container queries, but I believe most sizing media queries can be eventually replaced by container queries as they are a more appropriate format, whilst media queries will be used more for user preferences such as prefers-reduced-transparency, prefers-reduced-motion and prefers-color-scheme.

We think the case is very clear for supporting container queries and would like to ask any email clients to start looking into adding support, and to contact us for any question.

Backward compatibility in email

Wed, 18 Oct 2023 00:00:00 GMT

Due to the different ways email clients process HTML emails, developers resort to using various targeting techniques to display/hide different DOM elements or conditionally enhance certain elements for specific email clients. This is typically done with CSS by using selectors that only match elements in specific email clients. Developers may even rely on how an email client processes invalid HTML/CSS code or how they handle HTML/CSS features they do not support.

This is how the email industry ended up with a big stack of hacks only known to a niche of web developers; email developers.

Besides the unideal situation, this is contributing to a bigger issue; backward compatibility. These email client targeting hacks eventually stop working even though they may be present in hundreds of email messages in your inbox. As a result, HTML emails that make use of these hacks may look broken and their accessibility and usability could be affected.

Based on how developers build their emails today, the most common issues caused by the lack of backward compatibility are:

duplicated content
missing content
broken rendering

The current state of the industry does not allow developers to properly practice progressive enhancement. Instead, they have to follow the dark, impractical path of hacks to provide the recipient with the best experience possible.

Standards for the future

The Email Markup Consortium’s vision of a standard way of processing and sanitizing HTML emails (which does not impose identical feature support across all email clients) helps this issue.

While this does not introduce true backward compatibility, it empowers developers to drop the email client targeting hacks and allows them to progressively enhance their code with confidence.

Even as email clients change their level of support for different HTML/CSS features, HTML emails built following the progressive enhancement methodology will still render a fine and presentable version. Hence, this takes the burden of backward compatibility off the email clients’ plates.

Reader mode for the past

We fully realize how introducing a new standard way of sanitizing HTML emails is potentially introducing big breaking changes and may have a big impact on how old messages in your inbox will render. This is expected with a big fundamental change like this.

One way email clients could help their users to still view potentially broken old email messages is by introducing a reading mode that simplifies and declutters HTML emails for the reader (similar to Microsoft Edge’s Immersive Reader). This would remove all of the layout and design of the email and just keep the default semantic HTML values, styled with some user defined settings. Meaning that the email may look quite different but the content will be fully readable.

The Email Markup Consortium has published “Email reader view”, a browser extension for this as a proof of concept. Email clients can introduce a built-in one that better serves their users.

Email Reader View browser extension

Mon, 07 Aug 2023 00:00:00 GMT

We’re excited to launch our new Email Reader View browser extension. You can install it from Chrome Web Store now.

You should also be able to use that link to install it on any Chromium based browsers such as Edge, Opera, Brave, etc.

What is reader view

Email Reader View is a browser extension that allows the user to view an HTML email without all the clutter and distractions that can make reading difficult. It reduces the content to its most basic form of text but unlike a plain text email it keeps it’s semantic structure. Users can then apply their own styles to the text to suit their own preferences on things like font, text size, spacing and colors.

This is inspired by web reader view features have become popular over the last few years, with built in versions in many browser as well as a number of browser extension.

Why we built it

There are a number of goals we had with this project.

Help users with consuming content

Accessibility is a big goal for us at the EMC. This tool could help a number of users consume email content more easily. If a user struggles to read a certain font, or if the text is too small to read, or if they experience glare or halo effects on text with certain color combinations these can all be fixed. We also have an option to replace images with their alt text so text in images can now be more readable (assuming the sender has added good quality alt text).

Personally I use reader view on webpages a lot and since working on this project, I’ve started using it in email often too.

Help with email client rendering issues

Sometimes HTML email messages are badly displayed due to various issue in different email clients or badly written code from the sender. Applying reader view removes all of the styling, simplifying the content and should mean the content is always readable despite these potential issues.

A common issue is an email that isn’t built to be responsive, can now be scaled much better using reader view. Another issue is unexpected changes in email rendering, at the time of writing we recently saw a Gmail bug remove support for background image along with all other styles around it. This caused a number of emails to be unreadable. The browser extension provides the user with a way to still consume the content easily when rendering unexpectedly breaks like this.

If you find an example where an email is displaying poorly when using reader view, please let us know.

Encourage developers to use semantic markup

We’re always trying to get email senders to use semantic code, this tool helps emphasise the importance of semantic structure and hierarchy in a very visual way. When viewed in reader view, well written semantic code, simply looks better. If developers write code to optimise for reader view, the benefits should also apply more widely to the accessibility of the email.

Additionally using the block images option makes checking alt text much easier, allowing you to easily read it in the flow of the email content, much like how a screen reader would.

Encourage email clients to build their own

We think this would be a very valuable feature to build directly into the email clients. We’re hoping this project will help encourage the email clients to follow suit and build their own. Outlook does already have Immersive Reader however, I've found it to be unintuitive to use and it can be quite hard to find in the user interface.

A few of the benefits we see, with a native reader view inside the email clients include;

Users can consume content when rendering unexpectedly break because of an email client bug.
Users can consume content when rendering break because sender included a bug in their code.
It would be available on native mobile/desktop apps rather than just in the browser.

The code is all open source so if you are from an email client, please feel free to read over it.

What next

This is a free and open-source project, and updates can be slow. In the future we are hoping to add support for more email clients as well as looking at any feedback we get from users.

However if you are interested on working on this project or have more ideas for it, please check out the Email Reader View Github page and get in touch.

Introducing the Email Client Feature Support Rankings

Tue, 06 Jun 2023 00:00:00 GMT

Can I Email? is an invaluable resource to email developers. In 2022, we brainstormed what we can do to use this data to shed a light on the level of support of features from the perspective of what impacts the end user.

When looking at Can I Email?, we frequently see certain clients supporting, or not supporting features, but how do we visualize this from a high level, and what is the impact?

Categorizing HTML/CSS features

We decided (with the blessing of Can I Email’s maintainer; Rémi Parmentier) to categorize the tested features, which would enable us to visualize the data in new ways. A category would indicate whether the support of an HTML or CSS feature is beneficial for something such as accessibility, or performance. You can now view the categorized features on the Tags page on “Can I Email?”

As a start, we are categorizing features under the following categories:

Accessibility: features under this category are key to enabling assistive technology such as screen readers to be able to ingest email content. Email clients that support a majority of these features give email creators all opportunities to create accessible emails for their subscribers.
Performance: features under this category are key to the success of email rendering and loading.
Internationalization: This category of features outlines those that are beneficial to internationalization which would allow for developers the freedom to create semantic HTML in languages aside from English.

The Email Client Feature Support Rankings

The categorized HTML/CSS features enable us to look at the “Can I Email?” data in a different way. For example, we can now see which email clients do a good job of supporting HTML/CSS features that impact the accessibility of an HTML email.

Based on this data, we created the Email Client Feature Support Rankings in which we rank email clients in these categories based on what features they support. We hope this to become a reference not just to us, but also to email clients to evaluate whether their level of HTML/CSS features support aligns with their goals of providing their users with the best user experience possible.

How to deal with email accessibility issues outside of your control

Tue, 30 May 2023 00:00:00 GMT

At the Email Markup Consortium our mission is focused on improving email markup. However, off the back of our accessibility reports we hear from a number of people who are not able to make their code accessible, either because they don’t write the code themselves or because their code gets edited before it hits the inbox.

It’s rare for one person to be able to have full control of everything that goes into an email, and if you want to make your emails more accessible there can be a number of things blocking you. So we’re going to look at a few of these situations and what you can do to help.

Nobody can do everything, but everybody can do something.

How to deal with accessibility issues

Treat issues with accessibility the same way you’d treat other issues you find. Think what would you do if you found your content wasn’t displaying properly in a popular email client? The steps are the same, test to find the issues, report the issues, request fixes.

Finding the issues

For the accessibility report we use the Parcel accessibility checker to test the emails. This is free for anyone to use and gives a lot of detail of the errors it finds. Other email accessibility tools are available, as well as numerous web accessibility tools, however be careful using web tools as some of the accessibility requirements can be different to email and these may give you incorrect information.

Getting more information

If you unsure about any of the errors found, there are a number of great resources to learn more about them

Parcel.io provides links with more information on issues it finds.
If you have any questions you can ask for help in the #email-accessibility channel on email.geeks.chat Slack workspace.
You could also ask for help on Twitter, using hashtags like #EmailGeeks #Accessibility

Built by someone else

If the issues come from markup provided by an agency or freelancer, give them feedback asking them to address the issues.

Run the code through an accessibility checker and gather the results.
Give as much detail as possible, how and where you found the issues.

It’s best to set these expectations at the start of a project. You might say you want an email to render well in Gmail and Outlook, you can also say you want it to pass certain accessibility tests.

Generated or modified by a third-party tool

This could be markup created by an email build tool or framework, or maybe your markup is passing all accessibility tests but it’s getting changed at send time to start failing.

Open a support ticket, talk to your account manager or submit a contact form.
Give as much detail as possible, provide a code sample, links to any relevant accessibility documentation and explain what actions you took that produced this issue.
If there is a user community, ask other users if they are experiencing the same thing and have a work around.

You may be directed to workarounds for the issues you are having, but if there aren’t any then you can ask for a change to be made.

When asking for these things, it can sometimes feel like nobody is listening, but even if you don’t get a reply, the number of requests really do get noticed and the more requests they get, the more they take notice so it’s always worth doing.

Using generic content

Sometimes you can see the issue but you don’t have the necessary resources to address it fully. In some cases there may be a generic solution you can use while you’re working on a long term fix.

Title element

Ideally you’d have a unique <title> element placed in the the <head> of each email, with text describing detail about what’s inside. This could be the subject line, but if you don’t yet have a way to edit that easily you can use a generic title while you work on a longer term solution. It’s much better than leaving it blank.

But as a partial solution you can use a generic title, such as;

“Email from MyBrand”
“MyBrand Newsletter”
“MyBrand Order Update”

Language and language direction

It’s important to set a language and direction. This helps with a number of assistive technology tools as well as translation tools.

If you are using one main template for sending in multiple languages, and you don’t yet have a solution to be able to change it each time to match the content, you can set an undetermined language and automatic direction lang="und" dir="auto".

Without a lang or dir attribute the language and direction will inherit from the email client language settings. If the language is the same that works well but a lot of people in the world are multilingual and may receive emails in languages different to their email client settings. Setting undetermined, will allow the user agent to take a guess at the language rather than assume it’s the same. And dir="auto" will allow it to apply the appropriate direction to the assumed language.

There is room for error here as the user agent might make the wrong guess, so setting an exact language and direction is always best. But setting lang="und" dir="auto" is far better than setting nothing and works as a good solution while you’re working on a longer term fix.

Content added by sending tools

Sending tools often add additional content to emails, this content doesn’t always meet accessibility standards. It’s understandable as It can be hard to match the requirements of the specific email. But there are a number of things sending tools can do to help this.

Preview text

This is the text that can appear just below the subject line in the inbox. Some sending tools will add preview text to the email, making it easier for the user. The user can just type the text they want into an input and it gets added to the code. It’s really helpful however this code is often added directly after the opening <body> tag so may not be included in the wrapping element used for adding language and direction.

There are a few options here to work around this issue;

Allow a user to add the preview text themselves with a merge tag. This will allow the user to place the preview text in exactly the right place. This is a great option but not every user will know how to edit the code to put this in.
Place the preview text inside the wrapping element with the language and direction set. This can be tricky to detect accurately, also there is a chance there is no wrapping element at all.
Set generic language and direction on the preview text

<div style="display:none" lang="und" dir="auto">preview text</div>

Tracking codes

Most marketing emails include some kind of open tracking. This is usually an <img> tag, sometimes with a <style> block for some more advanced tracking.

Sometimes this <img> doesn’t have an alt attribute. This image isn’t adding any meaning of function to the content. So it can be fixed by adding an empty alt="" attribute on the image.

The tracking code can also get inserted automatically so again, like the preview text it may not be included in the wrapping element used for adding language and direction.

The options for sending tools to fix this are similar to the solutions to preview text;

Allow a user to add the tracking code themselves with a merge tag. This will allow the user to place the it in exactly the right place. This is a great option but not every user will know how to edit the code to put this in.
Place the tracking code inside the wrapping element with the language and direction set. This can be tricky to detect accurately, also there is a chance there is no wrapping element at all.
Set a language and direction on the tracking code

<div lang="zxx" dir="auto" aria-hidden="true">
  <style></style>
  <img src="[trackingcode]" alt="">
</div>

Here we’re using lang="zxx" to say that this is source code, also we’re also adding aria-hidden="true" to say this should not be read out by assistive technology.

Empty links

Some tools will add in a honeypot link to help track bots. The idea is a link is hidden from the user, but bots will automatically click on it. However if the link is included in the DOM then it’s going to be found by assistive technology, like keyboard inputs and screen readers.

The options for fixing this could be

Make it optional, allow the users to choose weather to prioritize accessibility or tracking bots.
When an email address has been flagged as a bot, it’s likely they will be removed from the list. There is an opportunity to use similar logic, so once an address has been flagged as legitimate, remove this link.
We can try and hide it from assistive technology by adding aria-hidden="true" and also removing it from the tab order by adding tabindex="-1". This may flag as an accessibility issues itself as the user won’t be able to access the link.

<a href="trackinglink" aria-hidden="true" tabindex="-1"></a>

Ask for help

If you are facing an issue and don’t know how to fix it ask for help:

EmailGeeks Slack #Email-Accessibility channel
On social media use the hashtags #A11y and #EmailGeeks

The new Outlook for Windows

Mon, 13 Mar 2023 00:00:00 GMT

On 17 May 2022, Microsoft announced the new Outlook for Windows, a version that will have a huge positive impact in the email space.

Now

For years, the Outlook for Windows desktop apps relied on proprietary technology to render HTML emails: their own Microsoft Word. The historic and business reasons behind that decision is not the topic of today, but its impact is.

Besides proprietary features that only work on Outlook for Windows, the rendering of HTML and CSS features is not always identical to the W3C specification. The Microsoft Word rendering engine had not kept up with the HTML’s living standard.

The result? Given the wide use of Outlook for Windows globally, email developers stuck with patterns only needed to ensure their HTML emails render well on Outlook for Windows. Because these patterns are not needed for emails to render well elsewhere, it’s an Outlook-first approach and not a user-first one.

The new Outlook for Windows

The new Outlook for Windows brings a fundamental change. It no longer uses Microsoft Word as a rendering engine, but a normal web browser engine.

Based on the initial testing of developers in the email community, it is reported to have an almost identical handling of HTML/CSS features to the web version of Outlook. This aligns with Microsoft’s goal to “bring consistency across our Windows and web codebases”.

It has been a multi-year effort to reach this point, and Microsoft has been betting on web technologies when developing new features for their Outlook apps across all operating systems for some time now. Finally, it’s now time for the HTML rendering to catch up with the rest of the app.

Availability

At the time of the announcement:

The new Outlook for Windows is available to Beta Channel users running Version 2205 (Build 15225.20000) or later.

However, it seems Microsoft is making the new version more accessible to more users as it can be downloaded and installed via its Windows App store.

The path forward

“Code like it’s the 90s” - an eternal joke that is reaching its expiry date. October 2026 is the month when Microsoft is ending support to the last version of Outlook that uses the Microsoft Word rendering engine. We can anticipate users to start using the new Outlook for Windows well before that date.

The step Microsoft is taking here makes the goal of enforcing some email standards more feasible. One of the key reasons we started the Email Markup Consortium last year was we believed the timing is right. This is a huge milestone in the email industry and we believe it is going to help us realize our vision.

Collecting Data

Wed, 08 Jun 2022 00:00:00 GMT

A number of projects we are working on require us to analyze real emails being sent on an on-going basis. We could not find a single data source that meets our criteria. That’s why we have recently started a new project to collect email data with the help of our good friends and sponsors at Parcel.

We are now in the process of collecting emails from as wide a range of industries, countries and languages as possible. We have already collected more than 10,000 emails from over 840 unique root domains. We intend to continue collecting more as this data will help us in providing real insights on a regular basis. This is where our other projects can take advantage of this data.

Data Diversity

A lot of data we see used in email reports is often skewed to a western audience. Collecting emails from the west alone is not going to give us the full picture of the real state of HTML emails. That's why we are making an effort to diversify our data.

Sender tools play a big role in the final HTML code sent to end users. We realize different sender tools are used in different industries and in different areas around the world. This could be by choice, or due to availability.

In addition, coding practices and what is considered important could vary in different parts of the world. For example, while there has been a big push for accessibility in the west in recent years, this may not be considered important everywhere. We cannot make many assumptions at this stage, but we should have a better understanding soon as we move closer to the analysis stage.

Our Accessibility Report Project

We're running this project alongside the team at Parcel.

The goal of the Accessibility Report project is to provide us with insight into the current state of email accessibility. We aim to track changes over time to see how it progresses, similar to the WebAIM Million report for websites.

Join the accessibility report discussion

The Email Platform Status project

We are working on this project alongside EMC member Rémi Parmentier and his team at Tilt Studio. The Email Platform Status project is an existent project that EMC is contributing to.

The Email Platform Status project evaluates HTML emails and calculates the use of HTML/CSS features within these emails. This will help answer questions on what coding techniques people are using? At what rate is modern code being adopted? And looking at how the industry is changing over time.

Join the email platform status discussion

Other Projects

We may use the same data source in other projects as well. If you have an idea on how we can utilize this data further, please get in touch.

How can you help?

Our main priority with this project at the moment is gathering data. We need as wide a range of emails as possible. So please, add this email address to your email lists along with any other lists you can think of. We want as many languages as possible and as many industries, both big and small.

Field	Value
Email address	collect@collect.emailmarkup.org
Name	Email Markup
Birthday	January 1, 2000
Address	1600 Pennsylvania Avenue NW, Washington, DC 20500

Introducing the Email Markup Consortium (EMC)

Wed, 25 May 2022 00:00:00 GMT

What is the Email Markup Consortium?

The Email Markup Consortium (EMC) is a community-led group of industry professionals working to improve the email experience for everyone.

Senders, recipients, and email clients share the common goals of improving user experience, accessibility, performance, consistency, and reliability. However, currently there is a lack of cooperation in trying to achieve these goals leading to inconsistent results.

Recipients should be able to easily access the content of every email sent to them, regardless of their device, email client, assistive technology or internet speed. The EMC collaborates with developers, creation and sending tools, and email clients to drive this vision forward at every step of the email journey.

Why is this needed?

As stated above, there is a lack of cooperation between the relevant parties to work towards these shared goals.

EMC is not the first project to attempt to address this. There have been several efforts in the past including:

This highlights to us that there is indeed a gap and an on-going need for a project like EMC to help bring the relevant parties together and collaboratively work with them.

Why is this different to previous projects?

Previous projects gained good support and helped move things forward. However, most of them have now been shut down or just left mostly unused.

Longevity

One of the goals of the EMC is longevity. We are structuring the EMC so that when the current members have moved on, the project will still live and be supported. To achieve this, we’re making the project as open as possible. Everything is posted publicly on GitHub where anyone can contribute.

We’re also thinking about long term solutions for the continuing challenges of email markup as well as new challenges that may arise with new technology. We’re not looking to only fix a few bugs. Instead, we’re looking to develop standards and maintain those standards moving forward.

Timing

We think the timing of this project is better in comparison to previous attempts. In recent years the email community has grown massively and collaboration has hugely increased. There are new projects coming up all the time, built by the community for the community, such as the huge EmailGeeks Slack group, Women of email, CanIEmail, How to Target Email Clients, and many more.

Evidence of productive collaboration

Seeing email clients collaboratively work on projects such as AMP for Email and adopting standards like BIMI shows us that different competing vendors in the email space can indeed work together.

How can people get involved?

The project is open source and you can find us on GitHub where anyone can contribute:

You can start or join an existing discussion
Contribute directly by opening a PR
Open an issue like you would on any open source project

If you would like to publicly show your support for the project, you can apply to become an EMC supporter as an individual or an organisation.

If you would like to be more involved in EMC projects and the organisation’s direction, you can apply to become an EMC member as an individual or an organisation.

If you represent an organisation and you would like to sponsor EMC, please get in touch.

EMC Administrators Mark Robbins, Hussein Al Hammad, Alice Li

The Email Markup Consortium Blog

Announcing the Email Markup Database

Proton Mail rise up the accessibility rankings

How email clients can improve preview text with one simple tag

Next generation preview text

A solution: use <meta name="description">

What we're proposing

Why this matters

Email clients are stripping out accessibility at the expense of user needs

Email clients should support accessibility preferences

What the 2025 Accessibility Report shows

Why this matters

A call to Gmail and other email clients

Let developers build inclusive email messages

Exploring using the ping attribute for click tracking

What is click tracking in email?

Problems

Opting out (privacy)

Transparency

Delays

Dead URLs

Exploring a native solution: the ping attribute

Pushback

Enforcing the solution

Support

Browser support

Email client support

A check-in on our progress with email clients

Discussed in the article:

The positives

The challenges

Looking ahead

Impact of accessibility work by EMC

Beefree

Stripo

Customer.io

Future vendor relations

How container queries could help email

Container Queries

Query units

Current support (as of October 2023)

Current Issues

When can we start using container queries

Backward compatibility in email

Standards for the future

Reader mode for the past

Email Reader View browser extension

What is reader view

Why we built it

Help users with consuming content

Help with email client rendering issues

Encourage developers to use semantic markup

Encourage email clients to build their own

What next

Introducing the Email Client Feature Support Rankings

Categorizing HTML/CSS features

The Email Client Feature Support Rankings

How to deal with email accessibility issues outside of your control

How to deal with accessibility issues

Finding the issues

Getting more information

Built by someone else

Generated or modified by a third-party tool

Using generic content

Title element

Language and language direction

Content added by sending tools

Preview text

Tracking codes

Empty links

Ask for help

The new Outlook for Windows

Now

The new Outlook for Windows

Availability

The path forward

Collecting Data

Data Diversity

Our Accessibility Report Project

The Email Platform Status project

A solution: use `<meta name="description">`

Exploring a native solution: the `ping` attribute