2018 Email Accessibility

Email Accessibility Best Practices


This post was updated on May 29, 2018. It was originally published in January 2017.

There’s never been a more exciting time to be part of the email world; we’re bombarded from all sides with technological advances and new ways to engage subscribers. However, there’s still something 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.

There are many adaptive technologies available to help these people use computers, tablets and smartphones, such as screen readers and screen magnifiers, or the more advanced sip ‘n puff devices and eye-tracking technology. Because these tools exist, many users can now access the internet and email.

Aside from these adaptive tools, email developers and marketers can further assist these users by making emails more accessible with a few code and design adjustments. Here are some tips and guidelines you can follow:

Making Email Code Accessible

Many accessibility issues in email marketing stem from development. One great place to start is having a solid email code foundation. After that, there are a few quick code changes we can make to fix these problems.

Once you make these changes – don’t forget to test your email with a platform like Email on Acid. Even the slightest tweak to code can affect how your email renders.

Use Semantic Code

Using semantic code is a basic fix that developers can apply to code, although most people overlook it. It’s important to use header (<h1>) and paragraph (<p>) tags, so screen readers can easily digest your content. These tags allow the screen reader to differentiate between headings and paragraphs, which creates a more pleasant reading experience and allows the user to better navigate through your emails.

Set the HTML Language Attribute

Setting the language attribute is a simple fix made in the head of the email. You can set this by using lang=”” with the correct language code. This code tells screen readers and other non-human systems, such as search engines, to expect a certain language and pronounce or display the words a specific way.

You can set the language by using the two letters that correlate to the language the email is written in, such as “en” for English. For an English email, the code would look like lang=”en”. If the email was written in Spanish, you would use “es.” Here’s a handy list of HTML language codes.

Set the Title of the Email

Proper use of the <title> tag has two benefits email subscribers. First, this tag will set a title on the tab of the webpage when viewing the email in a browser. It also 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! Simply add:

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

Content-Type plays a major role in the way an email displays.This code lets the browser or email client know which type of characters to expect in the subsequent code. It also ensures nothing breaks the reading pattern for a subscriber, whether he is reading the email himself or using a screen reader.

Don’t Set Titles on Links

A lot of people still like to use title=”” to add titles to links. Where possible, avoid setting titles on links. Instead, 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 make the content harder to understand.

Set and Style Alt Text

Most email developers and marketers know the importance of alt text; you should set it to ensure your email is still readable before the images load.

Alt tags also serve a purpose in accessibility. Setting the right alt text will enable screen readers to accurately describe images. However, not all images need alt text. If you’re using an image 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 tells the screen reader to skip over these images.

Fix Your Tables

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

role=”Presentation”

This uses Assistive Rich Internet Applications (ARIA) to tell the screen reader that this isn’t a data table, which is the intended use of tables in HTML, but a presentation table. This makes reading email 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 email easier for those dealing with visual and hearing impairments.

Consider Color Contrast

There are no specific rules for contrast but it’s something to consider. This is especially important for subscribers who may suffer from color blindness. For example, white text on a yellow background may be difficult to read.

There are a few different tools out on the web for checking contrast but one of the best is from webaim.

Keep Fonts at a Minimum of 14px

A good rule of thumb is to have your fonts at a minimum of 14px in size. Anything less than 14px can be tough for people to read. That being said, this is only a general rule and may change depending on the type of font you are using. For example, if you’re using a light font, consider bumping the size up to a minimum of 16px.

Maintain a Logical Reading Structure

When possible, keep a logical reading order to your email. In general, screen readers will read left to right before dropping to the next line. Keeping a logical reading order can also help users with dyslexia to maintain reading flow.

Avoid Center-Aligned Paragraphs

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. Yes, even on mobile! 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 the World Wide Web Consortium (W3C) with the goal of adding extra descriptive information to HTML elements to enhance the experience for people 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 you can wrap onto the code.

How Does ARIA Work?

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

role=”presentation”

role=”article”

role=”img”

role=”listitem”

Check out more ARIA examples here.

So, Is ARIA the Answer to Accessible Email?

In short, not yet. Although it’s making its way into web development, the email marketing world hasn’t quite caught up.

As Mark Robbins says in this Rebelmail blog post, many different email clients already use ARIA elements in questionable ways. For example:

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

So, with this in mind, our suggestion (for now) is to avoid using ARIA roles. If webmail clients are already adding incorrect roles, the ARIA would add to the confusion. That being said, it’s important to still use role=”presentation”. Although ARIA roles aren’t ready for production, this exception benefits of screen readers.

Resources

If you’re looking for more information on email accessibility, check out these resources:

Email accessibility best practices infographic
Click here to tweet this infographic.

It’s All Down to You

Whether you’re a developer, designer, email marketer, email accessibility comes down to you. Even though ARIA is not yet an option, you can take steps to ensure you give users the best possible email experience, regardless of visual, hearing, or other impairments.

If you have additional accessibility resources, important fixes, or any other thoughts and questions, please feel free to leave a comment below or reach out to us on Facebook and Twitter. We’d love to discuss email accessibility with you.

Test your Accessible Code!

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 email, every time. Even the slightest code change can affect how your email displays. With Email on Acid, you quickly can see how your email looks in more 70 different kinds of email clients and devices.

Start Testing Today!

7 thoughts on “Email Accessibility Best Practices”

  1. Hi Alex. Great article! Don’t forget to insert style=”margin:0;” inside the opening semantic tags, to prevent email and webmail clients bloating the space around the headline and subheadings in particular. This is a key reason why developers have avoided using them in the past, and one that I sought to find a solution for in my work on accessible email, resulting in my discovery of this technique. Type E: 04. The Accessibility Issue outlines this technique in more detail: http://createsend.com/t/d-ABFFF5F25EC93A19.

  2. Hi Alex,

    Great article! Do you have any additional sources on not setting titles on links? We’re developing some internal best practices and I’d love to cit a few sources for this information.

    Cheers,
    Carolyn

  3. Will providing a plain text alternative get the user past most of the screen reader problems that aria attributes would normally solve?

  4. @Ryan K

    We always recommend including a plain text alternative, but it all depends on what the subscriber has set their inbox to receive.

    Great Question!

  5. Hi,

    I’ve started building our emails with accessibility considerations.

    However, I’m not sure what’s the best approach to handle “terms and conditions” or fine prints.

    Just to give it some context. We normally have these long terms and conditions at the bottom of the email but I’m not sure if I should be using tags or just plain text (with Double to handle paragraphing) and also, because it’s a top-down fashion, there would be no issues with hierarchy and importance, it should get past screen readers okay, I presumed.

    Any thoughts, anyone?

Leave a Reply

Your email address will not be published. Required fields are marked *

Free Email Goodies