Adding accessible code to your email campaigns is essential for contacts who use screen readers to access the contents of their inbox.
The majority of these subscribers are people who are blind or have a severe vision impairment.
Accessible email code might be used by your contacts for various reasons:
Visual impairments such as blindness or colour blindness.
Impairments such as dyslexia or age-related issues.
A requirement to use screen readers to read emails.
Tables for presentation
A piece of code is automatically added to every table by EasyEditor. The code must be on the outer table and every table within a table too.
Example
<table role="presentation">
This code tells screen readers to ignore table code tags and only to read the table's content.
Limitation
Role=presentation does not work on tables with borders.
ARIA code
You can add ARIA code to hide certain parts of your email from screen readers, such as decorative graphics and duplicate content.
aria-hidden="true"
Use aria-hidden= "true" to make the email experience cleaner. Do not use it on focusable elements in an email – these are interactive sections which contacts can interact with using keyboard navigation, for example, buttons, links, or anything a contact clicks or selects.
Inbox preview text
Apple Siri
Siri can read emails to the recipient. It tells them who sent the email, what the subject line is, and then reads the inbox preview text.
Siri reads 500 characters. If the inbox preview text is too short, it will read the following items in the HTML code. These could be tags or links. This gives a very bad user experience.
For this reason, either make sure your inbox preview text is long enough or use clearspace lengthening code.
Editable hidden preview text with clearspace
Insert this code as the first item in the body of your email. Add it to a single-column block at the top of the build.
Learn how in Create an invisible preheader for a campaign.
<table cellpadding="0" cellspacing="0" class="col-font-reset ee_element
ee_textelement ee-hide-on-desktop ee-show-on-desktop" width="100%" ee-
type="element" data-title="Text" style="table-layout: auto;"><tbody><tr>
<td valign="top" align="left" class="element-pad element-bord root-
element-pad"><div class="ee_editable"><p style="line-height: 18px; text-
align: center; font-size: 11px; color: rgb(195, 194, 196);">Editable
hidden inbox preview text</p></div><div style="display: none; max-height:
0px; overflow: hidden;">  
; &
nbsp; &nb
sp;  
; &
nbsp; &nb
sp;  
; </div></td></tr></tbody></table>
The spacing ensures that the next item of text in the email does not appear after the inbox preview text, as this could be confusing and look bad. For example, the next item could be the alt text of a logo.
The above can also be used with non-hidden editable preview text, whenever you want to stop unwanted content showing in the inbox preview text. You need to copy the below div and paste it after the div containing your editable inbox preview text in your template (like in the example above).
<div style="display: none; max-height: 0px; overflow: hidden;">  
; &
nbsp; &nb
sp;  
; &
nbsp; &nb
sp;  
; </div>
Images
ALT text
Always include ALT attributes on images. This is because screen readers need something to read so they can describe images.
ALT attribute has no negative impact on deliverability.
TITLE attribute
It's recommended to use ALT text in addition to or instead of a TITLE attribute for the following reasons:
Someone who uses a keyboard to navigate websites, such as a person who lacks the fine motor control required by a mouse, will never see your title attributes because they have no way to hover over elements.
People who use a screen reader because they are blind or have poor vision will likely never have the title attribute read to them. Some screen readers don't support the title attribute, and those that do don't read the title attribute by default. It requires changing a setting for the title to be read, which not all users do.
Touchscreen devices such as phones and tablets don't support title attributes, creating an accessibility issue for everyone, not just those with a disability.
Design and code tips
Zoom in
Always test content scaled at 200% in the browser. As visually impaired people may view their devices zoomed in.
Testing should happen in a test send and not in EasyEditor, which should always be used at 100%.
Font sizes
Minimum regular font-size 14px.
Minimum light font-size 16px.
Disclaimer copy can be smaller, as screen readers will still read it.
Ease of visibility
Check contrast ratio. Use an accessibility contrast checker such as https://webaim.org/resources/contrastchecker/
Keep links underlined or use a visual identifier such as bold.
It might not be aesthetically pleasing to underline links, but it is helpful for visually impaired users.
Header tags for titles
Only use one
<h1>heading per email.Always follow a logical downward hierarchy for subheadings: h2, h3, h4. Avoid skipping header numbers, as screen readers follow them.
You can use multiple
<h2>and<h3>tags as long as there is a sensible hierarchy within email sections.Recipients using keyboard navigation can jump between sections to find what they need. You can adjust the size and styling of header tags in the CSS to meet visual needs, but to support accessibility and avoid screen reader confusion, only use them as headings and not as a way to format text.
Language tag
<html lang="en">
This attribute is very important for accessibility in multilingual email campaigns. If you have an international audience or are segmenting your list based on language, it helps screen readers, as well as browser and email clients, determine how to interpret and render the content correctly.
Add the language tag to the top header of your source code, for example:
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" lang="en">
Reading
Avoid centre alignment with large bodies of text as people with some learning difficulties –such a dyslexia– might struggle to scan text when reading.
Graphics vs live text
Buttons added as graphical elements aren’t as accessible as buttons which use HTML and CSS with live text for the calls to action.
Use
<H>tags rather than including headers as part of images.