Table of contents
Accessibility as a new trend?
It shocks us to talk about trends when we talk about accessibility. Accessibility is a duty and it's a good practice in its own right in the designing your HTML templates. Paul Airy and Litmus both reminded us of this in 2017.
"Doing nothing is not an option. Email accessibility is our job."
Paul Airy
And pioneers like EmailOnAcid were already talking about this topic two years ago. However, it seems that the email marketing world is finally making good resolutions for 2019. So much the better, when we know that 1.3 billion people worldwide live with some form of visual impairment according to the WHO. The articles bloom from all sides on this subject. The hashtag #a11y has never been better (although it is difficult to talk about accessibility when the same hashtag read by a screen reader evokes "a eleven y"...). First of all, let us note the Github documentation on accessibility in email. We, at Badsender, had the opportunity to glimpse a part of the work to be done during our participation to the Litmus Live from London August 2018. This was just the tip of the iceberg. But we can all, at our level, participate in improving the accessibility of our email marketing campaigns.
"People spend a lot of time worrying about email clients with 1% usage; accessibility is a much bigger issue."
Mark Robbins
Does accessibility require changes in our graphic and technical design methods?
Accessibility calls for new technological tools: Screen readers (VoiceOver for iOS, TalkBack for Android)screen magnifiers, eye-tracking technology, or more simply, personal assistants (Google Home, Apple HomePod, Amazon Echo). These use voice instructions to act. We could therefore, potentially, ask a personal assistant to read our e-mail. What we would call an "auditory call to action". (in English, The Auditory Call-to-Actionaka ACTA). While the tech doesn't yet allow it on Google Home, others do, such as a support on iOS with Siri enabled. And you may think that a personal assistant will choose the plain text version to read the contents of an email? You'd be wrong. A personal assistant will read the HTML version.
Who should act?
It is then up to us, designers and emailing integrators, to adapt our HTML and our design. Currently, making emails more "accessible" is not so complicated in itself. Small changes in design or development techniques can make a big difference to the audience. Here is a non-exhaustive list that will undoubtedly grow and evolve over time.
Tips'n Tricks Accessibility" to know and implement as soon as possible in our emails.
Specify language in which the content of the email is written.
Add the attribute lang="" to the tag html HTML code. If the text is in Frenchfill in the lang attribute as follows: lang="en". In English, lang="en". In Spanish, lang="es"and and so on...
<html lang="fr">Without this indication, a screen reader will use the language in which it is configured by default.
Encode HTML characters correctly
To do this, add the following HTML code:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">This code tells the browser or email client what type of characters are expected in the following code.
Provide a title via the title to the HTML code.
This allows a title to be set on the web page tab when viewing the email in a browser, but also provides context for users of assistive technologies such as screen readers.
Ensure correct rendering of an email on 120 DPI
And especially when using background images. Why? Because DPI scaling is actually an accessibility setting in Windows. As a general rule, the DPI is set to 96 (or a zoom of 100%). However, this has changed as high resolution displays are now set to a default value of 120 (125% zoom) or sometimes 144 (150% zoom). But users themselves can also set the DPI value to a value of their choice. It is therefore important to respect their choice, as it may depend on a visual impairment. The steps :
Add an XML Namespace on the tag html.
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:o="urn:schemas-microsoft-com:office:office">Correct DPI for images
This part of the code is added just before the closing of the head.
Use CSS instead of/in addition to HTML attributes
It should be noted that any value specified other than with the unit px will be converted into points. In other words, the values included in the width and height attributes must be filled in via the corresponding CSS properties.
<!-- Option 1: -->
<table border="0" cellspacing="0" cellpadding="0" role="presentation" width="600" style="width:600px;">
<!-- Option 2: -->
<table border="0" cellspacing="0" cellpadding="0" role="presentation" style="width:600px;">
<!-- Option 1: -->
<td width="300" style="width: 300px;">
<!-- Option 2: -->
<td style="width: 300px;">Summarize the content of the message in the preheader.
A possible alternative practice was raised by John Ties in two articles (1|2) consists in concentrating the message content in the email preheader and making the preheader invisible on the screen. With this technique, the preheader does not appear, but will be read by a screen reader or a personal assistant, allowing quick access to the entire offer and message of the email. The little extra: Siri will conclude the reading of the preheader with "Would you like to reply to this email?". So it's up to us to write something relevant. John says that the results on their tests were interesting.
Every image, whatever it is, must have an attribute alt.
If no attribute alt is not indicated, screen readers will read the file name. This can quickly become an unpleasant experience. Alt text plays a major role and must be configured so that your mail is always readable before the images are loaded. Setting the right alt text will allow screen readers to accurately describe the images. However, if an image is used solely for the "aesthetics" of the email (like a spacer or a shadow), ensure that a alt="" (empty) on the image. This tells screen readers to "skip" these images. On the other hand, in the case where an image has an empty alt attribute but a link encompasses that image, a screen reader will read the url included in the link. It is then preferable 1/ to delete the link or 2/ to fill in an alternative text.
Beware of animated gifs
Animated gifs too "violent", unstabletoo fast, for avoid epilepsy (It's funny because I'm the first one in my articles to make a probably too intensive use of stupid animated gifs, but I draw the conclusions).
Need help?
Reading content isn't everything. The best way is to talk to us.
Make sure that the content of the message included in an animated gif is accessible/understandable from the first slide
It's no longer a surprise, Outlook blocks animated gifs on the first image included in the gif. It is therefore essential to propose an understandable content/offer from the first slide. This first slide or status can very well be displayed 0 milliseconds, so that it does not appear on mail clients that correctly display the animated gif.
Add the attribute role= "presentation " on the boards present in an email
HTML tables are not originally made for presentation, except for emails, where tables allow to get an identical result on most email clients, and especially to use some style properties on Outlook (width or padding). Adding this attribute will indicate to screen readers that this is a presentation table, not a data table. This will make reading the content much more intuitive for screen readers, since they will not read the number of rows and cells in the table. On the other hand, if a table present in your HTML code is really present to display data, it will not be necessary to add this attribute. It seems, according to a webinar proposed by EmailOnAcid in collaboration with Net Atlantic, that the role="presentation" attribute has no effect on tables with a border.
Use of semantic tags.
The tags h1, h2, h3, pAlthough semantic tags provide a better understanding of the hierarchy of email content, they are often discouraged or avoided because some email clients or webmails apply their own styles to these elements, which can cause poor rendering. External margins (margin) are for example one of the graphic formatting applied by default on these tags. To solve this problem, it will sometimes be necessary to apply CSS resets to these tags.
Insert text in HTML instead of images
Not only to optimize the text/image ratio of a campaign, but especially to guarantee a maximum of information when displaying an email without downloading the images.
A paragraph of text must have a font size greater than or equal to 14px
A minimum of 16px for "light" fonts and a line height of at least one and a half times the font size. For optimal readability, it is possible to specify a line-height of at least 150% to each text in an email.
Take into account and improve the contrast of texts or data in the email.
White text on a yellow background can be difficult to read. The Litmus Builder tool allows, among other things, to consult a rendering for "colorblind". Other tools, such as TanaguruThe following table shows the ratio between two colors. It is necessary, as far as possible, to apply a minimum ratio of 4.5:1 on all texts in an email. For texts bigger than 23px or bold texts bigger than 18px, the minimum ratio is even stricter, going down to 3:1. A list of tips for create an accessible color palette can be useful, as well as a tool for to know quickly the ratio between colors, font sizes, etc...
Maintain a logical reading structure (from left to right).
It also helps recipients with dyslexia to maintain their reading pace.
Align the texts on the left.
The eye at a reference point to start reading each new line. While it is acceptable to center text for titles or buttons, it becomes more complex to read when it comes to paragraphs of text. It is therefore not recommended to center or justify paragraphs of text.
The content of the links must be meaningful and descriptive
For example, "Contact Us" is preferable to "Click Here". The text in the link should inform the reader what will happen when he clicks on the link.
Do not specify an attribute title to the links.
They make it difficult for screen readers to read. Instead, fill in relevant content directly in the link text, or in the link itself.
Links do not depend on color to be identified as such.
They can be indicated by an underline or followed by a symbol (>) .
Using the border-bottom CSS property
Rather than the CSS property text-decoration:underline on the links to improve the readability of the informationfor people with dyslexia. However, it is advisable to continue to keep the links underlined.
Buttons and links can be easily clicked
By offering a wide and high click zone (area of at least 44px wide by 44px high according to Apple, but opinions differ).
Text can be enlarged without being cut
(and by cut, I mean invisible because it goes under another element for example). To do the test, display an email in the Firefox browser. Press the Alt key to display the taskbar. Click on View > Zoom > Zoom Text Only. The text should zoom in to 200% without being cut off.
Ensure that text sizes are consistent for mobile display.
A title on two lines for the Desktop version with a 64px typeface may be moved to five or six lines on some resolutions (this is just an example) not to mention the breaks that a word that is too long could cause if nothing is done via media queries to change the size. On the other hand, a 12px text will be (perhaps) still relatively readable on desktop, but will it be as much on mobile? Will a 160px wide by 40px high Call to Action be as easily "clickable" with a finger? Also propose the right texts, on the right media: "clicking" for a mobile that only understands "tapping" may seem incongruous. Media queries are also there to avoid these problems.
HTML is correctly structured, without errors
And when mail clients allow it, use ARIA roles. These roles allow to describe the structure of a document, such as titles, regions (banners, menu...)Today, unfortunately, some mail clients add incorrect roles to some HTML tags. It is therefore not recommended to use them for the moment, except for the role="presentation" on the table.
Keep the code concise. As light as possible.
Codes that are too heavy, or superfluous, can impact loading time. Tools like HTML Tidy Online (based on the W3C Tidy Project) or Dirty Markup can be useful to remove empty, useless, or badly closed tags. This also contributes to an error-free code. To note (thanks Laurent Depoorter) that Tidy seems to have a tendency to remove some tips'n tricks for Outlook or other mail clients.
If the points raised above are particularly focused on visual impairment, it should be noted that there are other forms of disability that require work on web accessibility in general. How will an Internet user who has broken both arms navigate? Or an amputee? Whether the disability is permanent or temporary, our development method can greatly assist in navigation.
"Any implementation of accessibility, however small, is a success."
Paul Airy
Accessibility, a subject that does not date from yesterday for Badsender.
Badsender has already touched on the subject of accessibility in email marketing, through articles such as " Template emailing 1,2,3... Maximum text and full responsive !" .
Some acronyms to know about accessibility
- a11y: Hashtag and acronym for Accessibility/accessibilité.
- ACTA: Auditory Calls-to-Action
- ARIA: Assistive/Accessible Rich Internet Applications
- WCAG: Web Content Accessibility Guidelines
- W3C: World Wide Web Consortium
- ADA: Americans with Disabilities Act
- ADHD: Attention Deficit Hyperactivity Disorder
Resources to go even further
- https://www.a11yproject.com/
- https://www.who.int/news-room/fact-sheets/detail/blindness-and-visual-impairment
- http://createsend.com/t/d-ABFFF5F25EC93A19
- https://mailchimp.com/resources/accessibility-in-email-marketing/
- https://emails.hteumeuleu.fr/2016/08/thinking-outside-the-table-tedc-2016/
- https://litmus.com/community/discussions/6816-get-off-the-table
- https://a11yproject.com/posts/getting-started-aria/
- https://www.campaignmonitor.com/resources/guides/accessibility/
- https://www.emailonacid.com/blog/article/email-development/email-accessibilty-in-2017/
- https://www.emailonacid.com/blog/article/email-marketing/accessibility-in-email-webinar-recap/
- https://www.emailonacid.com/resource/accessibility-in-email/
- https://www.emailonacid.com/resource/email-accessibility-net-atlantic/
- https://emails.hteumeuleu.fr/2018/01/laccessibilite-des-e%E2%80%91mails-par-lexemple/
- https://webaim.org/standards/wcag/checklist
- https://www.wuhcag.com/wcag-checklist//
- https://www.w3.org/WAI/WCAG22/quickref/
- https://www.emailonacid.com/blog/article/email-development/which-code-should-i-include-in-every-email/
- https://accessibility.blog.gov.uk/2016/09/02/dos-and-donts-on-designing-for-accessibility/
- https://www.slideshare.net/DigitalGov/accessibility-for-animated-gifs-victoria-wales-us-agov-gobiernousagov
- https://a11yproject.com/posts/title-attributes/
- http://colororacle.org/
- https://www.campaignmonitor.com/blog/email-marketing/color-blindness-accessibility-and-the-vision-impaired-in-email-design/
- https://speakerdeck.com/hteumeuleu/thinking-outside-the-table
- https://litmus.com/community/discussions/6816-get-off-the-table
- http://emails.hteumeuleu.fr/2016/08/thinking-outside-the-table-tedc-2016/
- https://github.com/M-J-Robbins/get-off-the-table/blob/master/template.html
- https://en.wikipedia.org/wiki/Computer_accessibility
- http://mds.is/a11y/
- https://css-tricks.com/html-email-accessibility/
- https://www.rodriguezcommaj.com/blog/nearly-table-free-emails
- https://css-tricks.com/accessibility-testing-tools/
- https://fr.slideshare.net/M_J_Robbins/accessibility-in-email-eoainsights
- https://litmus.com/blog/email-design-podcast-30-interview-with-email-developer-mark-robbins
- https://www.youtube.com/watch?v=NUaEhil4vrc
- https://www.courtneyfantinato.com/correcting-outlook-dpi-scaling-issues/
And a amazing list of articles, presentations, tools, resources, books, webinars and podcasts on this truly fascinating subject.
