Email Accessibility in 2017


It’s 2017 now, if you haven’t heard, and email marketing is still not dead. In fact, email is flourishing! There’s never been a more exciting time to be part of the email world. We’re bombarded from all sides with technological advances. However, there’s still something basic we’re not doing enough of; accessibility.

Setting the scene

According to the World Health Organization 285 million people are estimated to be visually impaired worldwide and over 5% of the world’s population – 360 million people – has disabling hearing loss. To put that into perspective, the population of the USA is 325 million.

The range of adaptive technologies available to these users is truly astonishing, ranging from tools we’ve heard about such as screen readers or screen magnifiers to the more advanced sip ‘n puff devices to eye tracking technology. The fact these tools exist means many users who otherwise wouldn’t be able to access the internet and, by proxy, their emails now can.

More good news! We can actually further assist these users by making our emails more accessible. This is my New Year’s Resolution for this year; create more accessible email. Let me show you how I’m going to do it.

Fixing the code

A lot of accessibility issues in email marketing stem from development. There are quite a few quick, actionable code changes we can make.

Use Semantic Code

This is one of the most basic fixes that can be applied to code. It also happens to be one of the most overlooked ones. Ensuring the use of <h1> and <p> tags will help screen readers digest your content. Allowing the screen reader to properly differentiate between headings and paragraphs not only creates a more pleasant reading experience, it allows the user to navigate through your emails.

Set the HTML Language attribute

Another very simple fix we can apply to our emails is in the head of the email. By setting lang=”” with the correct language. Although a very minor fix it will ensure that words are being pronounced correctly by screen readers.

Unsure of how to use lang=””? You can read more here.

Set the Title of the email

Proper use of the <title> tag has two benefits for our emails. Firstly, it’ll set a title on the tab of the webpage when viewing the email in a browser, rather than an email client. More importantly, it provides a title and some context for users with assistive technology, such as screen readers.

Encode your characters

Don’t forget to encode your characters in the HTML! It’s really simple, just add:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

All this is doing is letting the browser or email client know which type of characters to expect in the following code. We’re simply making sure nothing untoward slips in, breaking the reading pattern for both people reading or using screen readers to read the email.

Don’t set titles on links

A bit of myth busting with this one, a lot of people still like to use title=”” to add titles to links. Where possible, we should avoid setting titles on links altogether. Stick to including the key information either as part of the text or the link itself. Screen readers will break their reading pattern to read the title and it can cause issues.

Set and style alt text

I’m sure most readers of this blog are aware by now of the importance of alt text. You should already be setting it to ensure your email is still legible before images load.

Alt tags also serve a purpose in accessibility! Setting the right alt text will enable screen readers to accurately describe images to those using them. However, not all images need alt text. If your image is purely for the aesthetics of the email, such as a spacer gif or shadow, be sure to set an empty alt=”” on the image. This simply tells the screen reader to skip over these images.

Fix your tables

Fixing our tables is another very quick fix that, arguably, makes the biggest difference to email code. This fantastic piece of code was shown to me by Mark Robbins and it makes a world of difference. Simply add the below to your tables.


This uses ARIA (more on that later, I promise) to tell the screen reader that this isn’t a data table, which is the intended use of tables in HTML, rather it’s a presentation table. This makes reading the content a lot more intuitive for screen readers.

It’s worth noting that if you’re using a table for showing data you should leave this off those specific tables as you still want them to be read as data tables.

General Email Considerations

There are also some general email marketing points to consider when discussing accessibility, which don’t necessarily relate to code but can still make life easier for those dealing with the aforementioned visual and hearing impairments.

Be wary of contrast

There are no specific rules for contrast but it’s something to be wary of. This is especially important for subscribers who may suffer from color blindness. There are a few different tools out on the web for checking contrast but one of the best is from webaim.

Keep fonts legible

A general good rule of thumb is to have your fonts at a minimum of 14px in size. Anything less than 14px can be very tough for people to read. That being said, it’s only a general rule. Around the web we’ve seen an increase in popularity of fonts being used with a light font weight. If using a light font, please consider using 16px as a minimum font.

Maintain a logical reading structure

You should try, where possible, to keep a logical reading order. Consider the fact that screen readers will, in general, read left to right before dropping to the next line. Keeping a logical reading order can also help those with dyslexia to maintain reading flow.

Avoid center aligned paragraphs

Yes, even on mobile! Although it can be aesthetically pleasing to have your text in the center it can be much harder for people with dyslexia to read center aligned text. Try and keep large bodies of text left aligned.

Is ARIA the answer?

What is ARIA?

ARIA, or Assistive Rich Internet Applications, is a web spec created by W3C with the aim to add extra descriptive information to HTML elements to enhance the experience for those using screen readers.

It’s worth noting that ARIA has zero effect on how your email looks or renders, it’s simply a descriptive layer we wrap onto the code.

How does ARIA work?

ARIA allows us to use HTML to tell screen readers what a HTML element is. The following are examples of ARIA roles:


If you’d like to see more ARIA examples, view them here.

So, is ARIA the answer?

In short, no. At least, not yet! Although it’s making its way into web development, it’s still being left behind a bit in email marketing.

As Mark Robbins correctly says in this fantastic blog many different email clients already use ARIA elements in questionable ways. The examples he includes are:

  • Gmail wraps your code with role=”listitem” inside role=”list” but only a single list item.
  • 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.
  • (newer version) uses role=”document”.

So, with this in mind, my suggestion for now is to avoid using ARIA roles. If webmails are already adding potentially incorrect roles we would further add to the confusion. That being said, please still do heed my advice to use role=”presentation”, although ARIA roles aren’t ready for production, this is an exception to the rule for the benefit of screen readers.


Accessibility in email is something that isn’t always the first topic on our minds. I do, however, have some fantastic resources if you’d like to do some further reading on accessibility.

  • Rebelmail – Accessibility in Email Part 2
  • Campaign Monitor – Accessibility and Email Campaigns
  • The A11Y Project
  • The A11Y Project – Getting started with ARIA
  • Mailchimp – Accessibility in Email Marketing
  • The Type E: Newsletter

It’s all down to us

Whether you’re a developer, designer, email marketer, or are otherwise involved in the creation of emails the burden of good accessibility falls to us. Even though we can’t use ARIA, we can take steps to ensure we give the best possible email experience, regardless of visual, hearing, or other impairments.

If you think I’ve missed a resource, an important fix, or anything similar or you have any general thoughts or questions, please feel free to leave a comment or reach out to us on Twitter. I’d love to discuss email accessibility with you.

When making any sort of changes to your email, whether it’s code based or simply changing the reading order of your articles, it’s important to ensure you re-test every iteration of your email. Email on Acid’s rendering tests can show you how your email looks in over 70 different kinds of clients in seconds.


Original Source