Jay Oram
Head of Dev
10 Apr 2023
There are a million different ways to code an email, with over 15,000+ possible renderings, in different languages, using images, using live text, using a built in ESP editor, hand coding, using a framework like Maizzle or MJML - any way that you send HTML emails, one thing we can all agree on is that we want as many recipients as possible to get our message and take an action, whether buying a product or finding out more information about the services you are offering.
This is where Accessibility comes in! If you are based in the UK, 1 in 5 people have some form of disability, that’s 20%, that’s not taking into account temporary situations. Accessibility isn’t only about making your emails come over well using a screen reader (it is that as well though), or about making sure your colours have enough contrast (again this is still important), it’s about making sure however you want to receive that information you can:
Using a screen reader
Bright sunshine outdoors
Dark mode on as your battery is low
Lost/slow connection (commuting and entering a tunnel or visiting somewhere remote on holiday!)
Images are blocked on your work PC Y
our holding a baby and you can’t reach your phone
Color blindness
Dyslexia
Plus so many more… Taking accessibility into account when you are creating emails, not only from a design point of view, but also in the building with HTML is well worth your time, get a higher Return on Investment (ROI) per email, make your recipients happy and if you still need a reason - don’t get sued for not having accessible communications.
Where to start?
We are going to break down some simple code practices that will help you make your emails more accessible, with some quick wins and include some really helpful links - but to start we are going to break down the information currently available to see what you should be trying to achieve.
WCAG
The Web Accessibility Initiative, has put together some Web Content Accessibility Guidelines (WCAG) which is widely used as a basis for accessibility on the web, including all communications. From an app, email or on a web page.
There are three levels as defined by the guidelines:
A - This is the most basic level with no specific adjustments for Accessibility, other than a link to a more accessible version somewhere.
AA - Where most emails and websites sit, the content is accessible but without the restrictive design and styling that is needed for the highest level.
AAA - As accessible as possible, including simpler layouts, higher color contrast and other techniques that would need to be considered from the outset. The two we are most interested in are AA and AAA which are both achievable when creating HTML emails. Outlined below are the basic points that need to be achieved to say an email reaches that level.
AA
Accessible and semantic
HTMl alt tags for all images
Colour contrast of at least 4.5:1 for all text on background colours
Simplified layouts where possible
Minimal text in images
AAA
All of the above in AA
Strict link styling - all links have the same colour and style to allow for easy identification
Colour contrast of at least 7:1 for all text on background colours
Simple layouts with clear hierarchy
No text in images
The Code
The language tag should be included in all of your email builds, and should contain the correct language abbreviation, these match the language codes in the ISO 639-1, you can find a list online here.
This global language attribute should be included in the tag at the beginning of your html document:
In some email clients the tag is stripped, most notably in webmail clients, so to ensure this is carried over, as Mark Robbins described in his email template, you can include it in a wrapping div around all of your content inside the body tag:
Semantic HTML
What is semantic HTML? HTML elements that clearly describe what they are to both the developer and the email client. If you see a <table> - you know and so does the email client that inside this element is a table. Using semantic markup can make emails more navigable by keyboards and also when read by screen readers.
When creating emails using either <div> or <table> elements, the parts inside should be marked up with the correct semantic element. If you are writing a heading, it should be wrapped in <h#> tags - with <h1> being the first major title, and only having one, followed by <h2> for subheadings and then increasing, <h3>, <h4> etc.
All email clients and browsers have preset styles for these elements and in some cases we may want to override them with our own. Below are the most common elements you would use whilst creating emails and the resets needed.
<h#>
Heading tags will have a font-size slightly larger, a bold font-weight and a preset margin. You could reset them using the inline styles below:
<p>
Paragraph tags should be used around all text that is not a heading, this only has a preset margin. A tip for controlling space around your paragraphs is to either use margin, as this is supported across email clients, or to set the padding on the surrounding element.
<article> or <div role="article">
Article denotes an independent section of HTML - your email will be an independent section within a webmail or email client and should be labelled as such. Either by wrapping all of your content in a <article> element or by using a <div> as shown above in Mark’s example to wrap your whole email.
role="presentation"
Currently to support some email clients we need to include <table>, <tr> and <td> tags to add width or padding, particularly in Outlook for Windows desktop. Screen readers will read out a table of contents as if it was full of data, for example:
“Row 1, Column 1, Name. Row 1, Column 2, Email address, Row 1, Column 3, City.”
This is the correct and expected way a table would be used on websites, but when we use a table to create a layout, a screen reader would still attempt to read it out in this way, so to stop that, we can include role="presentation" on all tables, if used for a layout and it will be treated as normal content.
To hear how a screen reader changes with role="presentation" - I’d encourage you to download one yourself (links below) - but a quick recording can be found on Rémi Parmentier’s accessibility breakdown article Point #3.
alt attribute
The alt attribute allows you to set an alternative text description of an image. Although not mandatory it is definitely considered a must-have when using images. Every image in your HTML should have an alt attribute, this should be as descriptive as possible.
The consensus is that even if you think a user doesn’t want to know what is in the image or doesn’t need to know - put the alt attribute in with as much descriptive information as possible anyway!!
If an image is purely for decoration, such as a divider or transparent spacer image, you should still include an alt attribute, but leave it empty, alt="" , so screen readers know to skip it. Otherwise some will read the URL - and with some ESP hosting images with random letters and numbers: src=".../%7B899c1297-b44b-4b66-9690-ac566f604e7b%7D.png" your don’t want to inflict that on anyone.
Rémi Parmentier’s article also has some recordings of good and bad alt text being read out: accessibility breakdown article. In the context of email it is also worth remembering that some email clients block images, some companies also set up work accounts to not show images, slow connections, interrupted connections and more could mean your image isn’t shown when a recipient opens your email - so alt text is even more valuable in this instance.
What can you do now?
Starting with the above you can start making your emails more accessible straight away, armed with this information you can look for more detail around other parts of the code. Dive into a whole bunch of resources compiled by Wilbert Heinen on Github and keep an eye on our blog for more in depth guides on coding and designing accessible emails.
At ActionRocket we can help you to understand more about accessibility and how it affects your email audience. Our aim is to get every brand to be creating emails with accessibility in mind. If you think your emails could be more accessible we’d love to help, get in touch with us at hello@actionrocket.co.