Blindness and other degrees of vision impairment are more common than many would think. 285 million people worldwide are considered to be visually impaired, with 19 million people in the US (or, 8.8% of the population over the age of 18) reporting trouble seeing, even with glasses or contact lenses. In addition, 4.5% of the population are color blind, which can also be a significant impediment when color is used to convey meaning or action in messages, both in email and on the web.
People spend a lot of time worrying about email clients with 1% usage; accessibility is a much bigger issue
– Mark, Rebelmail
In this guide co-published by Vision Australia, we’ll largely focus on best practices for designing email campaigns for the vision-impaired and those relying on screen reading devices, including audio prompts (such as synthesized speech) and keyboard-only access. Included are accessibility requirements, practical advice on coding and testing, as well as a pre-flight checklist for determining your campaigns are accessible, prior to sending.
Vision Australia is Australia’s leading national provider of blindness and low vision services. They work in partnership with blind or low vision individuals to help them achieve the possibilities they choose in life.
Digital Access at Vision Australia is recognised internationally as an industry leader in the provision of digital accessibility services, equally addressing the needs of all disability groups. A member of the W3C since 2002, Digital Access significantly contributed to the creation of WCAG 2.0.
First of all, what constitutes an accessible email? To meet basic accessibility requirements, an email message must:
Many of these points may be unfamiliar to you, so let’s go into each of these requirements in detail.
Unlike web pages, HTML email newsletters and templates are commonly coded using tables, as these are the most reliable way to create layouts that work across desktop, webmail and mobile email clients.
If not planned and built thoughtfully, people who rely on keyboard-only access might not receive the content in the order intended. Screen readers, for example, read aloud tabular content from left-to-right and from top-to-bottom.
The image below shows the order in which each text paragraph would be read aloud if assembled in a table of two columns and two rows:
To preserve logical reading order, a better layout would be a table of two columns and one row, as shown in the image below:
This requirement is particularly important to keep in mind when creating responsive email layouts, especially where images and content are repositioned to allow for a comfortable reading experience on mobile devices.
Maintaining a single-column layout on all screens – regardless of size – reduces the likelihood of content being parsed and read aloud by screen readers in either an incorrect order, or in a way in which the context of the content is unclear. However, when using multiple column layouts, you can change the order in which content columns are stacked by using the align or dir HTML attributes.
HTML heading elements – like <h1>, <table> etc – are critical to ensuring hierarchy is conveyed to screen reader users, who may not be able to see them. Keep in mind that simply styling text to stand out, or look more important is not sufficient when creating a content hierarchy for assistive devices.
People with moderately low-vision or color deficiencies can be less sensitive to luminosity or color contrasts when viewing text and images in an email message. Therefore, it’s important to incorporate sufficient contrast between text and the background of an email message. According to a UK study, almost 5% of people were reported to have some form of color-blindness, which shows the importance of ensuring you choose colors not only for aesthetic reasons, but for accessibility reasons, too.
Apps like Color Oracle for OSX can be used to simulate a variety of color deficiencies and ensure you are providing enough contrast – not to mention, non-color based cues – for all email recipients to understand your email messages.
All informative images must have an appropriate text alternative that conveys the meaning, or purpose of the image. Purely decorative images – such as ‘spacer’ images for preserving layouts – should carry an empty or null alt attribute (alt=””) to inform screen readers that the image is decorative and should be ignored.
For example, a company logo is an informative image and should feature a text alternative. In HTML email code, this can be done using the alt HTML attribute, to convey its meaning to screen reader users:
<img src="https://h2.campaignmonitor.com/assets/uploads/logo.png" alt="Vision Australia: Blindness and low vision services" />
It’s also important to convey the purpose of links using link text. This text informs the reader as to what will display when the link is followed and are often used for document navigation purposes by screen reading devices.
As a result, it’s recommended that generic text such as “click here” or “read more” be avoided, as these will offer little meaning, especially when read out of context by a screen reader. Instead, we recommend links in code like:
<a href="http://.../link-recommendations.html">read our recommendations for better links<a>.
Superfluous and “spaghetti” code can impact load times, as well as produce unexpected results both in email clients and accessibility devices. Tools like HTML Tidy Online (based on the W3C Tidy project) and Dirty Markup can be used to remove empty and unclosed tags, as well as spot common code validation issues.
The subject line is the first text people will read, or have read to them by a screen reader. It should be meaningful, descriptive, concise and shouldn’t repeat the sender name. More so than many of us, people with vision impairments rely on subject lines to determine whether an email message is relevant to their needs.
To test email campaigns extensively for potential issues, it’s important to use a combination of both accessibility testing tools and live device tests. In this section, we’ll go through how to test as to whether keyboard access, heading markup and the other built-in accessibility factors work as desired across a variety of email clients, using both freely available apps and services.
But before we get started, what tests should we be running on our email campaigns? We have selected a variety of email-relevant tests, based on W3C’s Web Accessibility Guidelines 2.0 (WCAG 2.0). Here’s how each of the tests maps to WCAG’s Success Criterion:
|Email Test||WCAG Success Criterion|
|Keyboard access and visual focus||2.1.1, 2.4.3, 2.4.7|
|Image alt text||1.1.1|
In cooperation with the Web Accessibility Tools Consortium (WATC), a variety of tools to assist with the above tests and make recommendations. While the devices and platforms you focus your testing on should ultimately map to what your email subscribers are using to read your email campaigns, many HTML email accessibility tests can be quickly and conveniently performed in your browser of choice using one of WATC’s recommended tools. Our favorites are:
After installing these tools, you should be able to perform the following tests:
The purpose of this test is to see if it’s possible to reach all email content using only a keyboard. This can be tested in the desktop or webmail clients of your choosing, preferably ones which are used commonly by your email subscribers.
The purpose of this test is to make sure that all informational images in an email campaign have an alt attribute. You can test this in your browser of choice using either Vision Australia’s Web Accessibility Toolbar (WAT) for Internet Explorer or Google’s Accessibility Developer Tools extension for Chrome.
The purpose of this test is to ensure headings are marked-up according to a suitable hierarchy.You can perform this test using Vision Australia’s Web Accessibility Toolbar, or by visually reviewing the HTML email code.
The purpose of this test is to ensure that all lists are marked-up properly. You can perform this test using Vision Australia’s Web Accessibility Toolbar, or by visually reviewing the HTML email code.
The purpose of this test is to check that screen readers can read the content of the email in a logical order. This can be done either using Vision Australia’s Web Accessibility Toolbar, or the WAI HTML Table Linearizer.
The purpose of this test is to ensure that page content can be zoomed to at least 200% without loss of content or function. This can be tested in the desktop or webmail clients of your choosing, preferably ones which are used commonly by your email subscribers.
Given the popularity of smartphones and tablets, it’s important to check that email campaigns can be read and responded to on these devices. Apple iOS devices like the iPhone and iPad have a in-built VoiceOver screen reader, which provides audio prompts to help read and navigate the device interface and displayed content.
If your email campaign displays as desired in iOS Mail under default conditions, then there are two further tests that we recommend you try. They are that the email is:
Resizable using the pinch-to-zoom gesture:
Available using VoiceOver:
Use the following checklist based on W3C Web Content Accessibility Guidelines to make sure your email campaign is accessible prior to send.
Subject line is concise and descriptiveYes
|Tables are optimized to preserve logical reading order||Yes|
|Heading elements used||Yes|
|Text colour contrast is sufficient||Yes|
|Images have suitable alt attributes||Yes|
|Headings summarize content that follows||Yes|
|Link text is meaningful (not “read more” or “click here”)||Yes|
|Images have meaningful alt attributes||Yes|
Email content is zoomable to 200% without losing content visibility or functionYes
|Content is fully keyboard accessible and demonstrates visual focus||Yes|
|All images retain alt text||Yes|
|Headings, lists and structural HTML markup is retained||Yes|
|Reading order is logical and as intended||Yes|
|Email content can be resized using a pinch zoom gesture||Yes|
|All content can be read using a device screen reader (e.g. VoiceOver)||Yes|