Accessibility as a new trend?
I must confess one thing, it shocks me to talk about trends when we talk about accessibility. Accessibility is a must. Paul Airy as well as Litmus had reminded us well 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 lang= " " attribute to the <html> HTML code. If the text is in FrenchIn French, fill in the lang attribute as follows: lang="fr ". 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
tag 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 DPIand in particular 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, because 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 closing the tag.
96
- Use CSS instead of/in addition to HTML attributes. Please note that any value specified other than px will be converted to points. In other words, the values 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;">
- Add an XML Namespace on the tag <html>.
- 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 content of the message in the preheader of the email 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 alt attribute. If no alt attribute is specified, screen readers will read the file name. This can quickly become an unpleasant experience. Alternative texts have a major role and must be configured so that your mail is always readable before the images are loaded. Defining the right alt text will allow screen readers to accurately describe the images. However, if you use an image only for the "aesthetics" of the email (like a spacer or a shadow), be sure to set an 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 that are 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).
- Make sure that the content of the message included in an animated gif is accessible/understandable from the first slide : It's not a surprise anymore, Outlook blocks animated gifs on the first image included in the gif. It is therefore essential to propose a content/offer that is understandable 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 designed for presentation, except for emails, where tables allow you to obtain an identical result on most email clients, and especially to use certain style properties on Outlook (width or padding). Adding this attribute tells screen readers that this is a presentation table, not a data table. This will make the reading of 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>, <p>Although 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 imagesnot 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 14pxA 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% for 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 TanaguruThese are used to determine the ratio between two colors. It is necessary, as far as possible, apply a minimum ratio of 4.5:1 on all texts in an email. For text larger than 23px or bold text larger 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 rhythm.
- 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 headings 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 Contact us" is preferable to "Click here". The text in the link should inform the reader of what will happen when they click on it.
- Do not specify a title attribute for 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 (>) for example.
- Using the border-bottom CSS property rather than the CSS property text-decoration:underline on links for 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. The media queries are also there to avoid these problems.
- The HTML is correctly structured, without errors, and when the mail clients allow it, will 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 <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 the visual disability, 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
And here's an infographic published by EmailOnAcid addressing some of the above points.
For accessibility... But not only!
If you want to go through with it, it would be very interesting to definitively abandon the integration of emails via nested tables. There are several reasons for this: nested tables make the HTML code more cumbersome, and make it much more complex to understand and update. Also for accessibility issues as we discussed above, tables are not the ideal method for screen readers. And also for another reason that we haven't developed so far: the weight of the email would probably be lighter if we freed ourselves from the <table>, <tr>, <td>which would allow to reduce our ecological impact. Which, by the way, should be just as much of an imperative in 2019. But then what about a code developed entirely from <div> and semantic tags? Is this possible when we know that Outlook does not interpret the CSS width property applied to a <div> for example?
Definitely get out of the <table>
Mark Robbins as Rémi Parmentier have already raised the idea and taken this initiative, through their respective movements " Get off the table " and " Thinking outside the <table>" . Here is a small overview of the test results we are currently getting. In advance, I specify that I am still in its infancy, and that I discover many specificities every day...
- Most HTML elements (<hn>, <p>, <ul>, <li>, <em>, <strong>, <b>, <cite>, <blockquote>...) have a automatic graphic formatting (or by default) which differs according to the mail clients, media and browsers. Bold, italic, background color, indentation, bullets, text size... We can see that type tags are for example automatically bolded on almost all email clients. This means that a series of "resets" must be implemented in CSS. Can we then apply them directly in the tag present in the ?
- The present in the is not interpreted by Android 5.1, Android 6.0, or on Gmail App IMAP (Android 4.4)nor on T-Online (regardless of the browser). This major constraint forces us to write our styles online (inline)directly on our HTML elements.
- The reset CSS online (inline) through the CSS properties line-height, font-size, margin, padding, font-family, font-weight work correctly on tags of type <hn> or <p>. We note in passing that the writing of hexadecimal codes in 3 characters and not in 6 when possible works properly. We also note that Gmail App (iOS 10.3.2) and Inbox by Gmail (iOS 10.3) consider the elements as block elements, since they are one under the other, but their width is limited to their content. The opportunity to see that the <body> has internal margins (top or right and left depending on the version) on iPhone.
- It can be noted that it is possible to apply a CSS reset to elements <body> and <html> through the CSS properties padding, margin, width and height to avoid any internal margin. On the other hand, a background color set on the body is not displayed correctly on Yahoo! (any browser)This is probably due to the fact that Yahoo! Mail seems to remove the <body> HTML code (conclusion drawn from the HTML overview processed by Yahoo! Mail).
- We realize that we can use the <div> within an HTML email integration, but it does not support the CSS background-color property on Outlook 2007, 2010, 2013, 2016, and 2019. Also, the CSS width property is not interpreted at all on Outlook 2007, Outlook 2010, Outlook 2013, Outlook 2019 on Windows 10, and Windows 10 Mail (Windows 10)nor the CSS max-width property. Therefore, we are forced to use conditional comments specific to Outlook (versions greater than or equal to Outlook 2007) to simulate fixed widths on tables. Moreover, in these conditional comments, we are forced to fill in the background color via the CSS property background-color, since the bgcolor attribute does not work.
- At the same time, we notice that the Litmus renderings of Gmail App IMAP (Android 4)Gmail App (Android 8.0)Gmail App (Android 7.1) and Gmail App (Android 6.0) are "cut" by + or - 20 pixels before the end. This explains the disappearance of the <p> on these renderings on the texts of the previous examples (located in the last position, after the <h6>).
- The CSS padding property does not work on HTML elements other than tables in Outlook 2007/2010/2013/2016/2019 (Windows 10)Thunderbird 60 (Windows 7)Windows 10 Mail.
- Do not forget to specify an align="center" to the tables present in the Outlook conditional comments if you wish to center horizontally within the page these same tables.
- Astonishment, it seems that the T-Online.de mail client also interprets the conditional code specific to Outlook.
- When you want to put two divs side by side for a columnar operation, several conditions must be kept in mind: Apply the CSS property font-size:0px; to the <div> including both <div> side by side, as well as the display:inline-block (to modify its behavior). Add a "text-align:center" so that both columns are centered on the mobile version. At the same time, add a text-align:left (if the texts are to be left-shod) on the <p> included in the <div> side by side. The <div> including both <div> side by side must have a predefined maximum width (max-width). And these same <div> must be included in a conditional comment because Outlook and others do not accept the max-width property on <div>. You may also need to specify a vertical-align on both <div> in the event that they are not of the same height.
- We must not forget add the attribute role="presentation on all tables in the Outlook conditional comments to optimize the reading of screen readers.
- Mark Robbins mentioned the possibility of using Outlook specific attributes to counter the problems of interpretation of certain CSS properties by this mail client.
Accessibility, a subject that does not date from yesterday for Badsender.
Badsender has already discussed the topic of accessibility in email marketing, through recent articles such as " Could the near future of email be to adapt to personal assistants such as Amazon Echo or Google Home? "or older ones like " Template emailing 1,2,3... Maximum text and full responsive !" . At training sessions that Badsender will present in May, we will take the opportunity to address this topic. At least I will in my training HTML for email 😉 .
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://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.com/thinking-outside-the-table-at-tedc16-a58a76c7c625
- 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://www.emailonacid.com/wp-content/uploads/2018/03/EOA_Accessibility_Infographic.pdf
- https://emails.hteumeuleu.fr/2018/01/laccessibilite-des-e%E2%80%91mails-par-lexemple/
- https://webaim.org/standards/wcag/checklist
- https://wuhcag.com/wcag-checklist/
- https://www.w3.org/WAI/WCAG20/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/2014/09/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.