Email Accessibility

Email Accessibility Best Practices


This post was updated on January 11, 2019. It was originally published in 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.

One development we’re especially excited about is accessibility. We’re passionate about helping email developers and marketers create and send emails that every subscriber can read and understand, regardless of whether they have a visual impairment or disability.

Setting the Scene

According to the World Health Organization (WHO), 1.3 billion people worldwide live with some form of visual impairment, with 217 million living with moderate to severe vision impairment. Approximately 36 million people worldwide are blind.

To put that into perspective, the population of the U.S. is 325 million (2017).

WHO also estimates that more than 1 billion people worldwide – or 15% of the global population – live with some form of disability.

There are many adaptive technologies available to help visually impaired and disabled 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 visually impaired and disabled people can better 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. With Email on Acid’s Campaign Precheck, you can easily scan your email for these important accessibility elements and adjust your code instantly to make your email more accessible. Give it a try today or update your subscription to test it out

If you want to get started with accessible emails, 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 make emails more accessible.

Once you make these changes – don’t forget to test and preview your email. 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 reader users 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 listener to better navigate 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 in 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.

If you’re using Campaign Precheck’s accessibility check tool, however, you just need to choose the language from the drop-down menu and we’ll get the code sorted for you.

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! To do this, you’ll add the following code:

<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 they are reading the email themselves or using a screen reader.

If you need some help converting special characters to HTML, we’ve got a handy, free tool that will do it for you.

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 text also serves a purpose for accessibility. Setting the right alt text will enable screen readers to accurately describe images.

Related: 5 Tips for Writing Alt Text in Email

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.

Campaign Precheck will help you with alt text by scanning your email code and finding and fixing mistakes for you. It’ll look for missing alt attributes and repeated alt text.

Fix Your Tables

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


This uses Accessible Rich Internet Applications (ARIA) to tell the screen reader that this is a presentation table, not a data table (which is the intended use of tables in HTML). This makes reading email content a lot more intuitive for screen readers.

Related: Why Should I Set My Table Role As ‘Presentation’?

Our Campaign Precheck tool will check your tables and make sure they are set to “presentation.” 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

Contrast ratio is especially important for subscribers who may suffer from certain visual impairments. For example, white text on a yellow background may be difficult to read.

Related: Why Email Colors Matter

An email design should have a minimum contrast ratio of 4.5:1 to meet level AA standards outlined by the Web Content Accessibility Guidelines (WCAG) 2.0. For text larger than 23px or bold text larger than 18px, the contrast ratio should be 3:1. To give those numbers more context, the same color (white on white) has a contrast ratio of 1:1 while white on black has a ratio of 21:1.

Color contrast examples

Email on Acid’s Campaign Precheck has a contrast ratio tool built into the workflow that will check your email design for color contrast issues. The tool will flag anything below the standard and adjust the coloring, so it is easier to read.

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.

Related: How to Develop Emails for Subscribers with ADHD

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.

Make Links Accessible

Links are another email element to consider for colorblind subscribers. Depending on the type of color deficiency a user has, he or she may not be able to easily see link or CTA button. Be sure indicate a link with bold font, an underline, or a symbol (>), so you don’t lose out on a click.

Is ARIA the Answer?

What Is ARIA?

ARIA, or Accessible 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:





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.
  • (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.

Email Accessibility Resources

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

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.

Campaign Precheck: Accessible Emails Made Easy

With Email on Acid’s Campaign Precheck feature, you can test your email against some of the most important accessibility guidelines and fix any issues with just a few clicks. The tool will scan your email HTML and design elements and make changes to the code for you – no need to send designs back to your developer or start from scratch.

Try Campaign Precheck today!

This post was updated on January 11, 2019. It was originally published in January 2017.
Author: Alex Ilhan

Hailing all the way from England, Alex brings his email development expertise along with an endless stream of cups of tea and British cynicism. Follow him on Twitter: @omgitsonlyalex.

Author: Alex Ilhan

Hailing all the way from England, Alex brings his email development expertise along with an endless stream of cups of tea and British cynicism. Follow him on Twitter: @omgitsonlyalex.

15 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:

  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.


  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?

  6. Awesome write up. In the world of email not everything is cut and dry, so having extra information like this around is fantastic.

  7. On some other blogs on email accessibility, I’ve read that it’s recommended to use heading tags (h1, h2, h3…) to make email content scannable. This makes sense in the context of a standalone web experience but given that emails are always read within another application that potentially has its own content hierarchy, I wonder if adding in headings may actually cause the opposite effect. Would you make the recommendation to add heading tags?

    1. Hello Marie. Thanks for reading our blog. From what I understand from my coders, if there are multiple

      tags the screen reader will scan them out of context, so depending on the application and your ESP, you may run into the problem you’re suggesting. My coders also suggested checking out some accessibility articles on how to handle this issue. Penn State has one on Heading Tags (H1, H2, H3, P) in HTML that is very helpful. Hope this gives you the information you need. Happy coding!

Leave a Reply

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