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

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.

Outlook.com (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.

Outlook.com (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.com, Outlook 365 GMX, Web.de 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.