An Alternative Theory

As we strive to maintain and build more accessible content, we are sometimes required to build what is functional first and focus on accessibility second. However, in order to create new guidlines around email accessibility, we must be willing to break the status quo. This raises the question: Where do we draw the line, and if it’s not accessible, can it be considered functional?

As we continue to learn ways to implement accessibility into email, it’s still great to discover and share new hacks. Because that is what makes email so much fun. This idea is all about an alternative to alternative text.

What is alternative text?

Alternative text has been around since the beginning of grunge music, or somewhere around that era, and quickly became the easiest attribute to misunderstand and improperly implement. Most commonly, it functions to provide a textual alternative to non-text content, which helps optimize for SEO, and situations when images do not not load. It also plays an important role with screen reader interactions.

One misconception about alt text, is that it must be presented within the alt attribute of the img element. While this is the most common placement, it can also be presented within the surroundings of the image itself.

Alt text and email

Styling alt text with CSS is becoming a standard part of the email developer's workflow, and offers an opportunity to add a professional touch that that can elevate customer satisfaction.

. .. .but what if we want to serve different content in lieu of these images, and the beautifully written alt text? With a few lines of HTML and CSS, we can. While still incorporating images to present information in a visual manner as usual, this method will display completely different content for those who opt out of the visual experience.

The basic markup

Create the main container and apply dimensions to match the natural width and height of the image, and don't forget to set overflow:hidden. This will act as our viewport.

<div class="main-container" style="width:300px; height:300px; max-height:300px; overflow:hidden;">  
 <!-- content -->

When adding the image, it's important to follow a few recommendations:

  • leave out width and height attributes
  • set alt as an empty value
  • include aria-hidden="true" to ensure screen readers ignore the element
  • use title to provide a meaningful link description

This example uses one image. However, you may choose to stack images, or even incorporate different content types.

<a href="" title="Link Description">  
 <img src="" style="display:block;" alt="" border="0" aria-hidden="true">

<!-- alternative content container here -->  

Everyone hides in their own unique way, here's how we do it

Since overflow:hidden is not supported 100%, and it's necessary for .main-container, we'll want to restrict the alternative content from rendering in certain email clients. This can be accomplished by using the checkbox hack, wrapped in a MSO conditional statement. Combined with a few lines of CSS, this will work just perfectly.

Applying role="img" informs the screen reader that the contained elements represent an image.

<!--[if mso]><!-->  
 <input type="checkbox" id="alternative" lang="x-alternative" class="hide-input" style="display:none !important;mso-hide:all;" checked>
  <div class="alt-content" lang="x-alt-content" style="display:none; overflow:hidden; mso-hide:all;" role="img">

   <!-- alternative content here -->


Next, add the content that you want to display when image is disabled into its own containing element within .alt-content, and set the width height dimensions to match the image.

<div style="width:300px; height:300px;">  
 <a style="color:#e83634;" href="">
  Alternative link / Content

Finally, add the corresponding CSS to ensure the alternative content is displayed where it is supported.

.hide-input {
 display:none !important;

#alternative:checked + .alt-content,
* [lang="x-alternative"]:checked + [lang="x-alt-content"] {
 display: block !important;
 max-height: none !important;

Where do we go now?

This method can be used in a variety of scenarios. Which may be for custom link tracking, or changing a message completely based on environments.

Either way, used or not, let this spark your imagination to keep experimenting and innovating, while expanding on great ideas to build greater ones.

Here is a complete example, that incorporates srcset for retina image support.

Accessibility in email: Part II

Coding email for accessibility

We recently posted an introduction to accessibility in email. This post if a follow up to that.

Accessibility is not often talked about in relation to email but it should be. As email developers we spend hours getting an email to look just right in a client with less than 1% market share but very few of us will spend a few minuets making the email accessible. I'll admit, I've been guilty of this too in the past. So I've put together a quick guide to get you started with some basics.


Tables are not meant for layout, they are designed to be used for displaying tables of data, so assistive technology will treat them as such, giving context to each cell in the table. This makes navigation slow and complicated, you need to navigate to each cell, enter the cell to read the content, then leave it then move to the next one. Whereas with a div based layout you can simply move from one piece of content to the next.

There is one simple and quick fix to this issue. Add role="presentation" to each <table> and it will be treated like a div based layout.

You only need to add it to each <table> element not every <td> so it’s a very quick and simple change to make. Go and do it now, you’ll dramatically increase the accessibility of your emails.

I made this video to show the difference role="presentation" makes to a screen reader.


N.B If you do have a table used as for it’s intended purpose, as a table of data, then don’t add this role.

Alt text

You’re hopefully already using alt text to describe images for people who have images turned off in their email client. Well that’s just the same for screen readers, simply use the alt text to enhance the experience by replacing the function of the image. Remember to be descriptive.

There are however times when you don’t want alt text, a spacer gif for example. Simply leaving the alt attribute off the img tag isn’t good enough, in this case the screen reader will read the full URL of the image, not good. So instead use alt="" to let the screen reader know this is intended to be blank.

HTML1 Semantic tags

There is often a bit of debate about whether to use <p> and <h> tags in email. I’ll settle that for you now. Do it!

Ok so you may have to add some additional styles to get the layout you want but that’s not hard.

So why use them? If you look at this article you can see there are a few heading, if one of these interests you, you read it, if not skip to the next one. If you’ve already read the article and just want a recap on one section you can quickly and easily find that. This can be done easily with a screen reader too but if there are no heading then the user will have to read the entire article.

HTML5 Semantic tags

When HTML5 came out, they introduced a series of new semantic tags to give better context to the code.

<article> <aside> <details> <figcaption> <figure> <footer> <header> <main> <mark> <nav> <section> <summary> <time>

This means the user can have clear context of weather they are navigating in the <header> <footer> or <main> part of the page for example.

Unfortunately it’s a bit too early to start relying on these in our email code as some clients will strip them completely (more details on support below) so instead we can use the role attribute. For example role="header" role="footer".

So when and how do we use these? This is quite an in depth topic so I’d say use sparingly to begin with, you don’t want to end up confusing people with misuse of these attributes.

One thing I should point out though is avoid using role="main". The accessibility spec says there should only be one main element per page so this could end up being confusing as we'd hope the webmail page or email app has already defined a main element.

So if not main what do you define your email wrapper as? I’m still undecided. I would think role="article" or role="section" would make the most sense but webmail clients are already wrapping your content, so maybe we should avoid any double wrapping.

Gmail wraps your code with role="listitem" inside role="list" but only a single list item in the list which seems odd to me.

Yahoo! use role="presentation" on a div and that is inside role="main" which is also odd. There should only be one main per page and a div is presentational by default. (older version) doesn’t appear to use any HTML5 tags or roles anywhere in the page, but this site is nearly phased out so I'll forgive them. (newer version) uses role="document" this probably makes the most sense but I'm still on the fence here.

So as you can see there is no agreement between the major webmail clients on the best structure to use, so I’m going to hang back on this until I’ve done some more research. I'll try and update this section as I learn more.

Email client support

Well we’re off to a good start as <h> tags, <p> tags and alt text are supported everywhere, so if you’re not using them already, please start.

I ran a quick test on some HTML5 elements and found Inbox, AOL, Yahoo,, Outlook 365 GMX, and Alto, all strip HTML5 elements. They remove the tag completely so you’ll loose any class, id, role or inline styles applied to these but do leave the content. Out of that list, they all also strip role from a div, with the exception of Inbox.

But remember role won’t affect the visual appearance of your email in anyway, it will only enhance it for assistive technology so there’s no reason not to use it.

Gmail supports most HTML5 tags but removes, main, nav details and summary.

iOS, Apple mail, Outlook Mac, Android, Samsung, BB10, all look like they have great support for HTML5 tags and the role attribute. So if you are a user of assistive technology these are probably the ones to use.

In summary

Accessibility it is a very big and complex issue but making one small change today can have a huge effect. So go and put role="presentation" on all your presentational tables right now, you don’t even need to retest anything it just works. If you use snippets or modular build then this is even quicker.

Then moving forward in your next build start thinking more about semantic elements, maybe just use a few <h> and <p> tags to begin with if you're not already using them.

Small steps can have a big impact. You don’t need to strive for perfection at your first attempt, do something small today, then add a little something extra next week and so on. It should become a part of your day to day workflow.

Litmus Microsoft Partnership

I'm hopeful but a little sceptical

Last night I logged on to watch a live feed of the Litmus, Email Design Conference in Boston. There Caitlin Hart, Program Manager from Outlook announced a partnership with Litmus to improve the rendering of Microsoft email clients. More details of that partnership here.

My thoughts the day after the announcement:

The Good

Firstly it's a great step in the right direction, a few years back the IE team reached out to web developers and ended up with a much better browser, better for developers, better for users. So lets hope Outlook can follow suit and do the same.

Outlook has recently been reducing the number of email clients. Live mail is gone and Outlook 365 and have sort of merged from a rendering and UI perspective. This means less testing on our side and less to maintain and therefore more time for bug fixing and improvements on their side.

This is also setting precedent for other email clients to follow. There is already good communication between developers who build website and those who build the browsers, hopefully this is the start of that relationship for email.

The Bad

However I am a touch sceptical. Back in 2009 (before I got into email) there was a campaign, the site is no longer with us but you can read more about here.

The campaign seemed to gather some good momentum and even got a huge poster put up in the Outlook office. But then Outlook 2010 came out with the same bugs as 2007 and if anything it's got worse since then with a number of 120dpi rendering issues coming in recent versions.

But that campaign was focused at the desktop client. I don't think we can do much there. Outlook 2016 STILL uses the Word rendering engine so they seem set on it and even if they do change to HTML rendering, people will be using 2016 for a number of years. We still see a few people using 2007!

The Ugly

Ok so a quick note on Outlook desktop and why I don't like it. Yes it's a pain to code for but it's quite predictable and most fixes are well documented.

My issue with it is it dramatically increases the code weight and dramatically reduces accessibility for every single email we send, no matter where it's opened. Yes you can fix your design for Outlook desktop but in doing so it means a worse experience for every other person receiving that email.

Billions of emails are sent every day that could be half the file size, millions of those are opened by people who struggle to access the content because of the way they are coded.

At Rebelmail we've done a lot of work to improve the accessibility of our emails and reduce the weight of our code but it's very complicated. Being able to use semantic HTML would lead to a dramatic improvement.

Sorry bit off topic there, rant over.

But I'm staying positive

We can all agree the Outlook desktop app is bad for people developing HTML email and I doubt anything will be done to fix that soon. What we should be focusing on now is the webmail clients and the apps, those can be fixed and those fixes can be rolled out across every account.

I'm sure the Outlook team will be inundated with bug reports from email devs, I hope they are ready for that. I know a few people including myself have already reported a number of bugs to Caitlin and before her to her predecessor Julia, so I'm hopeful to see some fixes rolling out soon.

And Finally

Remember the big difference between this drive for better rendering and the campaign is Outlook is involved with this from the start. You could even say they initiated it when they reached out to Justin Khoo last year.

I'm hopefully but I'm not going to let myself get too excited until I see the first bug fix roll out.

Introducing Johnny and Derek

Say hello to the newest members of the Rebelmail team, Johnny Mejias and Derek Jacobi.


Johnny is from La Isla del Encanto, otherwise known as Puerto Rico. He's been a software architect for six years and comes to us from CometaWorks. When he's not reinventing email, he's playing tennis or getting lost in the world of DarkSouls 3. It's not an addiction, it's a lifestyle.

You can follow Johnny on twitter.

Fun fact

He says he's only accidentally funny. (We'll see about that!)

Favorite song


Derek graduated from Penn State University (#WeAre) in 2015. He was previously the sole developer at Bar & Club Stats Inc, but now, he's excited to bring interactive emails to life at Rebelmail.

He loves fishing and boating.

Fun fact

He's been to bull riding school. (Our very own rodeo star!)

Favorite song

We're excited to have them on board! Say hello in the comments :).

Accessibility in email

An introduction

I started writing this the day after I got back from Amsterdam where I was speaking at the brilliant CSS Day conference. I learned a lot, I met some amazing people and I did a talk on interactive email, which can be scary in front of a few hundred web developers (who notoriously hate writing email code) but it went down really well.

Out of all the things I learned at the conference, one thing really stuck with me, accessibility. Léonie Watson did a great talk on the subject, I also had a chat with her in the bar afterwards about accessibility in email and the lack there of.

What is accessibility?

Not everyone can easily use a monitor, keyboard or mouse, some people use what's classed as 'assistive technology'. For example people with visual disabilities may use screen reader software to read the text on the screen, or a magnifier to dramatically enlarge it. People with physical disabilities may have to navigate using alternative input devices such as joysticks, eye tracking, a sip 'n' puff device or specialist keyboards.

Accessibility in email is simply about building emails in a way that can be accessed by these assistive technologies, allowing more people to access the content being sent.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, W3C Director and inventor of the World Wide Web

You're probably already writing code so people using Outlook, Gmail and other clients with poor rendering can read your emails, think of this as an extension of that. It's just increasing support to get your message to more users.

What can we do?

Email accessibility is bad because of two factors. Email developers not writing accessible code and email clients not supporting accessible code.

I often spend my days working out better ways to write email code so now I'm focusing my attention on making that code accessible too. Once the code is built and being sent it'll hopefully be easier to convince the email clients they need to catch up too.

I will then share my findings and encourage others to do the same.