
Email Accessibility Best Practices
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:
role=”Presentation”
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.
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.
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.
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:
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"
insiderole="list"
, but only a single list item. - Yahoo! uses
role="presentation"
on a div and that is insiderole="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.
Email Accessibility Resources
If you’re looking for more information on email accessibility, check out these resources:
- 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 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.

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.
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.
Paul, thanks for the reminder. I will add this in!
Cheers!
Hi alex,
after checking your contrast, you could use Tanaguru Contrast Finder to assist you finding a good contrast ratio. http://contrast-finder.tanaguru.com/
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
Will providing a plain text alternative get the user past most of the screen reader problems that aria attributes would normally solve?
@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!
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?
Awesome write up. In the world of email not everything is cut and dry, so having extra information like this around is fantastic.
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?
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!
Yes! Finally something about Carl Smith.
Glad you liked the article Leonard!
Based on Unspam results https://unspam.email/ the 90% of emails are not accessible optimized.
It’s sad.