Intro to accessible e-mails

Note: This post is older than two years. It may still be totally valid, but things change and technology moves fast. Code based posts may be especially prone to changes...

(Read 649 times)

At the end of the day – an email is just an HTML. But also has plain text version baked into it. And is still using tables for positioning, chances are. So here are some thoughts on how to make them accessible.

E-mail is not mentioned in Web Content Accessibility Guidelines as far as I know, but still it must also be accessible and it must respect at least some accessibility guidelines.

This post is a short introduction to email accessibility that I was missing when I searched the existing webpages.

It all starts with a good subject

Subject is like a title for a page, so make sure it gives meaning and is not too long. Some sources suggest 65 characters but it depends.

As important as the subject is also the preview text. You know – the text that you can get if you enable preview mode in your client. It is like meta description in a way – short summary of email content.

Both are not accessibility only considerations, but add to it as well.

Do not forget to set correct language on the HTML element as it is crucial for the assistive technologies to use and present the email with correct pronunciation. The same goes for encoding. If you use UTF-8, then be sure to set it in the code.

We should not be using tables for grid, but then again we must still use tables for positioning in email

Exactly – it is 2021 now and we are still forced to use tables for positioning and even some responsive design in our emails. Because the email HTML client user agents are still quite frozen in time. Microsoft Outlook, as far as I know the top email client for business use in the world is for example using Microsoft Words engine to render HTML. Therefore we are actually using ancient web browsers to display the HTML of an email.

At the same time it is very security oriented, and that is a good thing, but sometimes means we can not use all the modern CSS media queries and for example JavaScript.

So first important accessibility task is to mark all presentation tables as such – with usage of role=”presentation” on the table elements we are basically telling screen-readers and other assistive technologies to ignore the semantics of table and just treat it as an element needed for presentation alone.

Headings and document outline are as important as in a webpage

As mentioned – assistive tech uses headings for navigation, so they should be valid and their hierarchy should be clear. Do not use them for visual styling, their semantic value should not be abused.

Outline defining logical order should be a logical decision. Linear flow, like on the web applies also in emails.

Images with meaning need alternative text, like in any digital format

First thing first – I would avoid image only emails. Even with good alternative text it is only so much that you can describe. Some assistive technologies are even ignoring for long alternative texts. So it is better to just have a textual email with some images that have alternative texts.

Correct alt tags with meaningful information are even more valuable for emails. Images get blocked by default, maybe even proxied by some online email system and therefore it is crucial to have alternative texts that pass the information. Sending out a link with a huge banner with “90% sale” text inside an image will potentially not be opened if we did not make it clear in the alternative text. I’ve seen a lot of emails with huge banners and no alternative text – a giant mistake – I am sure their opened rates were lowest possible.

At the same time – please use empty alt tags for decorative images – as arrows and other decorative elements. Alt text on those just adds to the noise and does not help anybody!

Also make sure images have good contrast, and can be perceived also if users can not see distinct colors. Use of patterns, good contrasts and other WCAG practices apply here as well.

And – do not forget – you can actually also style the alternative text displayed without images. It does not work in all ancient clients but you can promote downloading of images with placeholders and proper alternative text.

Do not justify or center lines of text

It is like on the web – readability will be better if textual blocks are aligned to left if your language uses left to right text (and the other way around if you use right to left).

You can have headings or short promotions centered though.

Links should have actionable texts and should be visually distinguishable

As for a web site – it is not a good practice to have all of the links marked with text “click here” – as links are used for navigation of assistive technologies and often used totally out of context. So their meaning must be provided within link itself.

At the same time – do not mark links with color only – please underline them or maybe just add some other visual hints, so that even color blind persons will not be in doubt what is a link and what not.

And yes – you will probably using some links as call to action buttons. They are still links, just styled as buttons. So no fancy stuff there – just style the link as a button, do not make it a button.

Never use color alone for emphasis

Click the red button, and as mentioned links in different color but not underlined should not be used, and it goes also for emails. Color alone should not be used for emphasis and we should consider users that are blind or just color blind. Therefore we can use semantic elements that enable us emphasizing with different means as well. For example em tag or strong in combination with color should do the trick.

As mentioned with images – contrast is important as well. So always check color contrast front versus back. For text, all elements and also within images.

Make sure email is also accessible on mobile devices

Test with small screens, change orientation, zoom in and out, and make sure everything is responsive. It is also important that active elements can be easily clicked on – or to say touched. Keep call to actions large enough, at least 44 pixels but more is better.

Also take care of line heights, it has a lot to do with readability.

High contrast and dark mode are also important to consider

Very quickly to forget about dark mode, but it is used more and more, so we should really also consider it. It is not supported on old clients but on mobile it is very likely it is supported. So make sure to adjust mail for it. Same goes for high contrast – it should also be tested and potentially adjusted.

An email is just a HTML at the end of day

So make sure to respect WCAG for emails as well. There are some times your HTML will not be shown at all. If user likes to read text only email then chances are your accessible HTML will not be used at all, so make sure that plain text alternative can get your message out as effective as your rich HTML does.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: