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.

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.

Absolute positioning in email

You can't use absolute positioning in email.

Well actually you can a bit. It is supported in modern email clients; iOS, Android, Applemail, AOL etc. But it still gets stripped from the likes of Gmail,, Outlook 365 and obviously Outlook desktop.

Yahoo mail is a funny one, it supports position:absolute; but not top bottom left or right therefore rendering it useless.

It was actually when testing the below hack that I found Yahoo supports position:absolute; and prematurely shared the news on twitter without realising the debilitating caveat. So by way of apology here's how to do position absolute in Yahoo and almost every other email client.

Absolute positioning that works everywhere

(Except Outlook on desktop pc, but what do you expect from Microsoft Word rendering)

So first of all you need to set a container to position against.

<div style="width:300px;height:300px;">  

Then place an element inside that, set display as inline-block and position it with margin-top and margin-left.

<div style="width:300px;height:300px;">  
    <div style="width:100px;height:100px;margin-top:100px;margin-left:100px;display:inline-block;">

N.B. Unfortunately negative values in the margin won't work in Gmail, or 365.

The element is now behaving similar to position:relative but we want position:absolute so as not to affect the flow of any neighbouring elements. To achieve this wrap the inner element in a div with max-height:0;max-width:0 this now mean that div takes up no space on the page, but the overflow can still be seen.

<div style="width:300px;height:300px;">  
    <div style="max-height:0;max-width:0;overflow: visible;">
        <div style="width:100px;height:100px;margin-top:100px;margin-left:100px;display:inline-block;">

You can now place multiple elements in that container and position them absolute. In this example I've added outlines and semi transparent background colours to clear display the outcome.

<div style="width:300px;height:300px;outline:2px solid black;margin:0 auto;">  
    <div style="max-height:0;max-width:0;overflow: visible;">
        <div style="width:100px;height:100px;margin-top:100px;margin-left:100px;display:inline-block;outline:2px solid red;text-align:center;line-height:100px;font-size:50px;background:rgba(255,0,0,0.2)">
    <div style="max-height:0;max-width:0;overflow: visible;">
        <div style="width:100px;height:100px;margin-top:150px;margin-left:150px;display:inline-block;outline:2px solid blue;text-align:center;line-height:100px;font-size:50px;background:rgba(0,0,255,0.2)">
    <div style="max-height:0;max-width:0;overflow: visible;">
        <div style="width:100px;height:100px;margin-top:50px;margin-left:50px;display:inline-block;outline:2px solid green;text-align:center;line-height:100px;font-size:50px;background:rgba(0,255,0,0.2)">


Ok so it still doesn't work in desktop Outlook but it does work pretty much everywhere else I've test.

But please do use this wisely. Do consider Outlook, perhaps a VML fallback or simply using Outlook conditional comments.


Thanks to JK who pointed out in the comments that the Yahoo overflow update affects this. So I've added overflow: visible; to the above code which fixes that problem.

A new table structure

The Past

For years developers have been building email in the same way, a 2 table structure where the outer table is set to 100% width and the inner table is set to something like 600px wide resulting in a 600px centered container for your content.

The Present

More recently people have been using the spongy/hybrid approach that sets the inner table width a max width of 600px and a width of 100%, so the content will fit the viewport when viewed under 600px. With this method there is also the need for a ‘ghost table’ hidden from everything but Outlook and set to a fixed width of 600px as Outlook doesn’t recognise the max-width property.

More recently I’ve been replacing this inner table with a div as it uses a little less code, but now...

The Future?

My new approach uses just one table. The width is set to 100% and it contains 3 table cells, the center cell has a width of 600px and the other 2 are left blank so they will automatically fill the remaining space and center the content. It's the same concept as setting margin:0 auto; often used on the web.

If the viewport is less than 600px the width of the table overrides that of the table cell so it will adjust to fit, therefor giving the same result as the max-width:600px; trick.

This new technique uses less code and also gives you a couple more design options.

You can now control the background of the left and right side of the email separately, to give this cool flag effect.

Frence flag

You could maybe use background images instead of colours to recreate the classic Smith and Jones head to heads (British comedians from the 80's).

Smith and Jones

You can even add additional empty table cells to offset the content, these will automatically align as the viewport gets smaller.

Offset tables

The Code

So here is the basic code I use.

<table width="100%" border="0" cellspacing="0" cellpadding="0" bgcolor="#333333" role="presentation" style="table-layout:fixed">  
    <td style="font-size:0px">&nbsp;
    <td align="center" width="600" bgcolor="white">
            New Table Structure
    <td style="font-size:0px">&nbsp;

And you can view the code for all the examples here

The left and right table cells both contain &nbsp; as if they are empty they it can break in some clients. This however has the side effect of creating a one character space either side of the content on mobile. This may well be an effect you like but if not simple add style="font-size:0px" to remove it.

As an extra plus this new technique also fixes things like the Yahoo! left align bug.

It's still early days and although I've tested this in a few campaigns already, there may still be some limitations I've not yet come across.

N.B I'm already working on a new structure that uses no tables at all. Just need a little more testing on that one first.