Accessibilité et emails : rendre ses campagnes plus accessibles

L’accessibilité comme nouvelle tendance ?

Je dois vous avouer une chose, cela me choque de parler de tendance lorsqu’on parle d’accessibilité. L’accessibilité est un devoir. Paul Airy comme Litmus l’avaient d’ailleurs bien rappelé en 2017.

“Doing nothing is not a option. Email accessibility is our job.” Paul Airy

Et des pionniers comme EmailOnAcid évoquaient déjà largement le sujet il y a deux ans de cela. Cependant, il semblerait que le monde de l’Email Marketing se décide enfin à prendre de bonnes résolutions pour 2019. Tant mieux, quand on sait que 1.3 milliard de personnes à travers le monde vit avec une forme de déficience visuelle selon l’OMS. Les articles fleurissent de toutes parts sur ce sujet. Le hashtag #a11y ne s’est jamais si bien porté (même si on peut difficilement parler d’accessibilité lorsque le même hashtag lu par un lecteur d’écran évoque “a eleven y”…). Relevons tout d’abord la documentation Github sur l’accessibilité dans l’email. Nous avons, chez Badsender, eu l’occasion d’entrevoir une partie du travail à effectuer lors de notre participation au Litmus Live de Londres en Août 2018. Il ne s’agissait que de la partie immergée de l’iceberg. Mais nous pouvons tous, à notre échelle, participer à améliorer l’accessibilité de nos campagnes d’email marketing. accessibilité email

“People spend a lot of time worrying about email clients with 1% usage; accessibility is a much bigger issue.” Mark Robbins

L’accessibilité demande-t-elle des changements dans nos méthodes de conception graphique et technique ?

L’accessibilité fait appel à de nouveaux outils technologiques : Lecteurs d’écran (VoiceOver pour iOS, TalkBack pour Android), loupes d’écran, technologie de suivi des yeux, ou plus simplement, les assistants personnels (Google Home, Apple HomePod, Amazon Echo). Ces derniers utilisent les instructions vocales pour agir. Nous pourrions donc, potentiellement, demander à un assistant personnel de lire notre courrier électronique. Ce qu’on appellerait alors un “appel auditif à l’action” (en anglais, The Auditory Call-to-Action, aka ACTA). Si la technique ne le permet pas encore sur Google Home, d’autres l’autorisent, comme un support sous iOS avec Siri activé. Et vous pensez peut-être qu’un assistant personnel choisira la version en texte brut pour lire le contenu d’un email ? Vous vous trompez. Un assistant personnel lira la version HTML.

Qui doit agir ?

A nous alors, designers et intégrateurs emailing, d’adapter notre HTML comme notre design. Actuellement, rendre les emails plus “accessibles” n’est pas si compliqué en soit. De petits changements dans le graphisme ou dans les techniques de développement peuvent faire de grosses différences pour l’audience. Voici une liste non-exhaustive amenée sans aucun doute à s’étoffer ou à évoluer avec le temps.

Les “Tips’n Tricks Accessibility” à connaître et à mettre en place au plus vite dans nos emails.

  1. Spécifier la langue dans laquelle le contenu de l’email est rédigé. Ajouter l’attribut lang=”” à la balise <html> du code HTML. Si le texte est en français, renseigner l’attribut lang ainsi : lang=”fr”. En anglais, lang=”en”. En espagnol, lang=”es”, et ainsi de suite
    Sans cette indication, un lecteur d’écran va utiliser la langue dans lequel il est configuré par défaut.
  2. Encoder correctement les caractères HTML. Pour ce faire, ajouter le code HTML suivant :
    Ce code indique au navigateur ou au client de messagerie quel type de caractères est attendu dans le code suivant.
  3. Fournir un titre via la balise <title> au code HTML. Cela permet de définir un titre sur l’onglet de la page web lors de l’affichage du courrier électronique dans un navigateur, mais fournit également un contexte aux utilisateurs de technologies d’assistance comme les lecteurs d’écran.
  4. S’assurer du rendu correct d’un email sur du 120 DPI, et en particulier dans le cas d’utilisation d’images de fond. Pourquoi ? Parce que la mise à l’échelle DPI est en réalité un paramètre d’accessibilité sous Windows. En règle générale, le DPI est défini par défaut à 96 (ou un zoom de 100%). Toutefois, cela a évolué car les écrans haute résolution sont maintenant configurés sur une valeur par défaut de 120 (zoom de 125%) ou parfois de 144 (zoom de 150%). Mais les utilisateurs eux-mêmes peuvent également définir la valeur DPI sur une valeur de leur choix. Il est donc important de respecter leur choix, car il dépend peut-être d’une déficience visuelle. Les étapes :
    • Ajouter un XML Namespace sur la balise <html>.
    • Corriger le DPI pour les images : Cette partie du code s’ajoute juste avant la fermeture de la balise </head>.
    • Utiliser du CSS à la place/en plus des attributs HTML. Il faut savoir que toute valeur spécifiée autrement qu’avec l’unité px sera convertie en points. Autrement dit, les valeurs comprises dans les attributs width et height doivent être renseignées via les propriétés CSS correspondantes.
  5. Résumer le contenu du message dans le preheader. Une pratique peut-être alternative et soulevée par John Ties dans deux articles (1|2) consiste à concentrer le contenu du message dans le preheader de l’email et de rendre le preheader invisible à l’écran. Par cette technique, le preheader n’apparaît donc pas, mais sera bien lu par un lecteur d’écran ou un assistant personnel, permettant ainsi d’accéder rapidement à l’entièreté de l’offre et du message de l’email. Le petit plus : Siri conclura la fin de lecture du preheader par “Voulez-vous répondre à cet email ?”. A nous donc de rédiger un texte pertinent. John affirme que les résultats obtenus sur leurs tests étaient intéressants.
  6. Chaque image, quelle qu’elle soit, doit avoir un attribut alt. Si aucun attribut alt n’est indiqué, les lecteurs d’écran vont lire le nom du fichier. L’expérience peut vite s’avérer désagréable. Les textes alternatifs ont un rôle majeur et doivent impérativement être configurés pour que votre courrier soit toujours lisible avant le chargement des images. Définir le bon texte alternatif permettra aux lecteurs d’écran de décrire avec précision les images. Cependant, si on utilise une image uniquement pour “l’esthétique” de l’email (comme un spacer ou une ombre), veiller à définir un alt=”” (vide donc) sur l’image. Cela indique aux lecteurs d’écran de “sauter”/passer ces images. En revanche, dans le cas où une image a un attribut alt vide mais qu’un lien englobe cette image, un lecteur d’écran va lire l’url comprise dans le lien. Il est alors préférable 1/ de supprimer le lien ou 2/ de renseigner un texte alternatif.
  7. Prendre garde aux gifs animés trop “violents”, instables, trop rapides, pour éviter l’épilepsie (ça prête à rire car je suis le premier dans mes articles à faire un usage sans doute trop intensif de gifs animés abrutissants, mais j’en tire les conclusions.)
  8. Prévoir que le contenu du message compris dans un gif animé soit accessible/compréhensible dès la première slide : Ce n’est plus une surprise, Outlook bloque les gifs animés sur la première image comprise dans le gif. Il est donc primordial de proposer un contenu/une offre compréhensible dès la première slide. Cette première slide ou état peut très bien s’afficher 0 millisecondes, pour ne pas la voir apparaître sur les clients mail affichant correctement la lecture du gif animé.
  9. Ajouter l’attribut role=”presentation” sur les tableaux présents dans un mail. Les tableaux HTML ne sont pas faits à l’origine pour de la présentation, excepté pour les emails, où les tableaux permettent d’obtenir un résultat identique sur la majorité des clients mail, et surtout d’utiliser certaines propriétés de style sur Outlook (width ou padding). Le fait d’ajouter cet attribut permet d’indiquer aux lecteur d’écran qu’il s’agit donc d’une table de présentation, et non d’une table de données. Cela rendra la lecture du contenu beaucoup plus intuitive pour les lecteurs d ‘écran, puisque ceux-ci ne liront pas les nombres de lignes et cellules du tableau. En revanche, si un tableau présent dans votre code HTML est vraiment présent pour afficher des données, il ne sera pas nécessaire de lui ajouter cet attribut. Il semblerait, d’après un webinar proposé par EmailOnAcid en collaboration avec Net Atlantic, que l’attribut role=”presentation” n’ai aucun effet sur des tableaux avec une bordure.
  10. Utiliser des balises sémantiques. Les balises <h1>, <h2>, <h3>, <p>, etc. aident les lecteurs d’écran qui distinguent alors les titres et leurs différents niveaux, les paragraphes… Bien que les balises sémantiques fournissent une meilleure compréhension de la hiérarchie du contenu des emails, elles sont souvent déconseillées ou évitées, car certains clients de messagerie ou webmails leur appliquent des styles propres à ces éléments, ce qui peut causer un rendu médiocre. Les marges extérieures (margin) sont par exemple une des mises en forme graphiques appliquées par défaut sur ces balises. Pour résoudre ce problème, il sera parfois nécessaire d’appliquer des “reset” CSS à ces balises.
  11. Insérer des textes en HTML plutôt qu’en image, non seulement pour optimiser le ratio texte/image d’une campagne, mais surtout pour garantir un maximum d’informations à l’affichage d’un email sans téléchargement des images.
  12. Un paragraphe de texte doit avoir une taille de police supérieure ou égale à 14px, un minimum de 16px pour des polices “light” et une hauteur de ligne d’au moins une fois et demie la taille de la police. Il est possible, pour garantir une lisibilité optimale, de spécifier un line-height d’au moins 150% à chaque texte présent dans un email.
  13. Prendre en compte et améliorer le contraste des textes ou des données dans l’email. Un texte blanc sur fond jaune peut être difficile à lire. L’outil Litmus Builder permet, entre autres, de consulter un rendu pour “daltonien”. D’autres outils, comme Tanaguru, permettent de connaître le ratio entre deux couleurs. Il est nécessaire, autant que possible, d’appliquer un ratio minimum de 4.5:1 sur tous les textes d’un email. Pour des textes plus grand que 23px ou des textes en gras supérieurs à 18px, le ratio minimum est encore plus strict, descendant à 3:1. Une liste d’astuces pour créer une palette de couleurs accessible peut être utile, tout comme un outil pour connaître rapidement le ratio entre des couleurs, des tailles de typo, etc…
  14. Maintenir une structure de lecture logique (de gauche à droite). Cela permet aussi d’aider les destinataires souffrant de dyslexie à maintenir leur rythme de lecture.
  15. Aligner les textes à gauche. L’œil à un point de référence pour commencer à lire chaque nouvelle ligne. Bien qu’il soit acceptable de centrer des textes pour des titres ou des boutons, cela devient plus complexe à lire lorsqu’il s’agit de paragraphes de textes. Il est donc déconseillé de centrer ou de justifier des paragraphes de textes.
  16. Le contenu des liens doit avoir un sens et être descriptif : Préférer ainsi “Contactez-nous” à “Cliquez ici”. Le texte renseigné dans le lien doit informer le lecteur de ce qu’il va se passer quand il cliquera sur ce même lien.
  17. Ne pas spécifier d’attribut title aux liens. Ils complexifient la lecture par les lecteurs d’écran. A la place, préférer renseigner un contenu pertinent directement dans le texte des liens, ou dans le lien lui-même.
  18. Les liens ne dépendent pas de la couleur pour être identifiés comme tels. Ils peuvent être indiqués par un soulignement ou suivi d’un symbole (>) par exemple.
  19. Utiliser la propriété CSS border-bottom plutôt que la propriété CSS text-decoration:underline sur les liens pour en améliorer la lisibilité, pour les personnes souffrant de dyslexie. Il est toutefois conseillé de continuer à garder les liens soulignés.
  20. Les boutons et les liens peuvent facilement être cliqués en proposant une zone de clic assez large et haute (zone d’au moins 44px de large sur 44px de haut selon Apple, mais les avis divergent).
  21. Le texte peut être agrandi sans être coupé (et par coupé, j’entends invisible parce qu’il passe sous un autre élément par exemple). Pour faire le test, afficher un email dans le navigateur Firefox. Appuyer sur la touche Alt pour afficher la barre de tâches. Cliquer sur Affichage > Zoom > Zoom texte seulement. Le texte doit pouvoir être agrandi jusqu’à 200% sans être coupé.
  22. S’assurer que les tailles des textes soient cohérentes pour un affichage sur mobile. Un titre sur deux lignes pour la version Desktop avec une typo de 64px se verra peut-être passer sur cinq ou six lignes sur certaines résolutions (ce n’est qu’un exemple) sans compter les cassures qu’un mot trop long pourrait engendrer si rien n’est fait via les media queries pour en changer la taille. A l’inverse, un texte de 12px sera (peut-être) encore relativement lisible sur desktop, mais le sera-t-il tout autant sur mobile ? Un Call to Action de 160px de large sur 40px de haut sera-t-il aussi facilement “cliquable” avec un doigt ? Proposer aussi les bons textes, sur les bons supports : “cliquer” pour un mobile qui ne comprend que le “tapotage” semblera peut-être incongru. Les media queries sont là-aussi pour parer à ces problématiques.
  23. L’HTML est correctement structuré, sans erreurs, et quand les clients mail le permettront, utilisera les rôles ARIA. Ces rôles permettent de décrire la structure d’un document, tels que les titres, les régions (bannières, menu…), les tableaux… Aujourd’hui malheureusement, certains clients mail ajoutent des rôles incorrects à certaines balises HTML. Il est donc déconseillé de les utiliser pour le moment, excepté pour le role=”presentation” sur les <table>.
  24. Garder un code concis. Le plus léger possible. Les codes trop lourds, ou superflus, peuvent impacter le temps de chargement. Des outils comme HTML Tidy Online (basé sur le W3C Tidy Project) ou Dirty Markup peuvent être utiles pour supprimer des balises vides, inutiles, ou mal fermées. Ceci participe aussi à un code sans erreur. A noter (merci Laurent Depoorter) que Tidy semble avoir tendance à supprimer certains tips’n tricks pour Outlook ou autres clients mail.

Si les points soulevés ci-dessus sont particulièrement axés sur le handicap visuel, il est à noter qu’il existe d’autres formes d’handicap qui nécessitent un travail sur l’accessibilité du web de façon générale. Comment naviguera un internaute qui s’est cassé les deux bras ? Ou une personne amputée ? Qu’il s’agisse d’handicap permanent ou  de déficiences temporaires, notre méthode de développement peut grandement aider à la navigation. Handicap navigation email

“Any implementation of accessibility, however small, is a success.” Paul Airy

Et voici une infographie publiée par EmailOnAcid abordant quelques-uns des points cités ci-dessus. EmailOnAcid Accessibility Infographic

Pour l’accessibilité… Mais pas seulement !

Si l’on souhaite aller au bout de la démarche, il serait grandement intéressant d’abandonner définitivement l’intégration des emails via les tableaux imbriqués. Plusieurs raisons à cela : les tableaux imbriqués alourdissent le code HTML, et rendent sa compréhension bien plus complexe, ainsi que sa mise à jour. Pour des questions aussi d’accessibilité comme nous l’avons abordé ci-dessus, les tableaux n’étant pas la méthode idéale pour les lecteurs d’écran. Et aussi pour une autre raison que nous n’avons pas développée jusqu’à présent : le poids de l’email serait sans doute plus léger si nous nous affranchissions des <table>, <tr>, <td>, ce qui permettrait de réduire notre impact écologique. Ce qui, soit dit en passant, devrait tout autant être un impératif en 2019. Empreinte écologique email Mais alors qu’en est-il d’un code développé entièrement à partir de <div> et de balises sémantiques ? Est-ce possible lorsqu’on sait qu’Outlook n’interprète pas la propriété CSS width appliquée sur une <div> par exemple ?

Sortir définitivement des <table>

Mark Robbins comme Rémi Parmentier ont déjà évoqués l’idée et pris cette initiative, à travers leurs mouvements respectifs “Get off the table” et “Thinking outside the <table>“. Petit tour d’horizon des résultats de tests que nous tirons actuellement. Par avance, je précise que j’en suis encore aux balbutiements, et que je découvre nombre de spécificités chaque jour…

  • La plupart des éléments HTML (<hn>, <p>, <ul>, <li>, <em>, <strong>, <b>, <cite>, <blockquote>…) ont une mise en forme graphique automatique (ou par défaut) qui diffère selon les clients mail, supports et navigateurs. Gras, italique, couleur de fond, retrait, puces, taille du texte… Nous pouvons constater que les balises de type <hn> sont par exemple automatiquement en gras sur quasiment la totalité des clients mail. Cela implique donc de mettre en place une série de “reset” ou remise à zéro en CSS. Peut-on alors les appliquer directement dans la balise <style> présente dans le <head> ?
  • Le <style> présent dans le <head> n’est pas interprété par Android 5.1, Android 6.0, ou sur Gmail App IMAP (Android 4.4), ni sur T-Online (quel que soit le navigateur). Cette contrainte majeure nous oblige donc à rédiger nos styles en ligne (inline), directement sur nos éléments HTML.
  • Les reset CSS en ligne (inline) à travers les propriétés CSS line-height, font-size, margin, padding, font-family, font-weight fonctionnent correctement sur des balises de type <hn> ou <p>. On note au passage que la rédaction des codes hexadécimaux en 3 caractères et non en 6 quand cela est possible fonctionne correctement. On note aussi que Gmail App (iOS 10.3.2) et Inbox by Gmail (iOS 10.3) considèrent bien les éléments comme des éléments de type block, puisqu’ils sont les uns sous les autres, mais que leur largeur est limité à leur contenu. L’occasion de voir que la balise <body> présente des marges internes (en haut ou à droite et à gauche selon les versions) sur iPhone.
  • On remarque qu’il est possible d’appliquer un reset CSS aux éléments <body> et <html> à travers les propriétés CSS padding, margin, width et height pour éviter toute marge interne. En revanche, une couleur de fond renseignée sur le body ne s’affiche pas correctement sur Yahoo! Mail (tout navigateur confondu), sans doute dû au fait que Yahoo! Mail semble supprimer la balise <body> du code HTML (conclusion tirée depuis l’aperçu de l’HTML traité par Yahoo! Mail).
  • On s’aperçoit qu’on peut utiliser l’élément <div> au sein d’une intégration HTML d’email, mais que celle-ci ne supporte pas la propriété CSS background-color sur Outlook 2007, 2010, 2013, 2016, et 2019. De plus, la propriété CSS width n’est pas du tout interprétée sur Outlook 2007, Outlook 2010, Outlook 2013, Outlook 2019 sur Windows 10, et Windows 10 Mail (Windows 10), ni la propriété CSS max-width. De ce fait, nous sommes donc contraints de passer par des commentaires conditionnels spécifiques à Outlook (versions supérieures ou égales à Outlook 2007) pour simuler des largeurs fixes sur des tableaux. De plus, dans ces commentaires conditionnels, nous sommes obligés de renseigner la couleur de fond via la propriété CSS background-color, puisque l’attribut bgcolor ne fonctionne pas.
  • On remarque par la même occasion que les rendus Litmus de Gmail App IMAP (Android 4), Gmail App (Android 8.0), Gmail App (Android 7.1) et Gmail App (Android 6.0) sont “coupés” de + ou – 20 pixels avant la fin. Ce qui explique la disparition du <p> sur ces rendus sur les textes des exemples précédents (situé en dernière position, après le <h6>).
  • La propriété CSS padding ne fonctionne pas sur des éléments HTML autres que des tableaux sur Outlook 2007/2010/2013/2016/2019 (Windows 10), Thunderbird 60 (Windows 7), Windows 10 Mail.
  • Ne pas oublier de préciser un align=”center” aux tableaux présents dans les commentaires conditionnels Outlook si l’on souhaite centrer horizontalement au sein de la page ces mêmes tableaux.
  • Étonnement, il semblerait que le client mail T-Online.de interprète lui aussi le code conditionnel spécifique à Outlook.
  • Lorsqu’on souhaite mettre deux divs côte à côte pour un fonctionnement en colonnes, il ne faut pas oublier plusieurs conditions : Appliquer la propriété CSS font-size:0px; sur la <div> comprenant les deux <div> côte à côte, ainsi que le display:inline-block (pour en modifier le comportement). Ajouter un “text-align:center” pour que les deux colonnes soient centrées sur la version mobile. Du même coup, ajouter un text-align:left (si les textes doivent être ferrés à gauche) sur les <p> compris dans les <div> côté à côte. La <div> comprenant les deux <div> côte à côte doit avoir une largeur maximale prédéfinie (max-width). Et ces mêmes <div> doit être comprises dans un commentaire conditionnel car Outlook et d’autres n’acceptent pas la propriété max-width sur les <div>. Vous pourrez être aussi amenés à spécifier un vertical-align sur les deux <div> dans l’hypothèse où elles ne seraient pas de la même hauteur.
  • Il ne faut pas omettre d’ajouter l’attribut role=”presentation” sur tous les tableaux présents dans les commentaires conditionnels Outlook pour optimiser la lecture des lecteurs d’écran.
  • Mark Robbins évoquait la possibilité d’utiliser les attributs spécifiques Outlook pour contrer les problèmes d’interprétation de certaines propriétés CSS par ce client mail.

L’accessibilité, un sujet qui ne date pas d’hier pour Badsender.

Badsender a déjà évoqué le sujet de l’accessibilité dans l’email marketing, à travers des articles récents comme “Le futur proche de l’email serait-il de s’adapter aux assistants personnels tels qu’Amazon Echo ou Google Home ?” ou plus anciens comme “Template emailing 1,2,3… Maximum texte et full responsive !“. Lors des sessions de formations que Badsender présentera au mois de mai, nous en profiterons pour aborder ce sujet. Du moins, je le ferai dans ma formation HTML pour l’email 😉 .

Quelques acronymes à connaître sur l’accessibilité

  1. a11y : Hashtag et acronyme pour Accessibilité/accessibility.
  2. ACTA : Auditory Calls-to-Action
  3. ARIA : Assistive/Accessible Rich Internet Applications
  4. WCAG : Web Content Accessibility Guidelines
  5. W3C : World Wide Web Consortium
  6. ADA : American with Disabilities Act
  7. ADHD : Attention Deficit Hyperactivity Disorder

Des ressources pour aller encore plus loin

Et une liste incroyable d’articles, de présentations, d’outils, de ressources, de livres, de webinars et podcats sur ce sujet réellement passionnant.

A propos de Thomas Defossez

Thomas a démarré sa carrière en tant qu'intégrateur emailing chez Experian avant de créer sa propre agence web. Aujourd’hui, Thomas a décidé de se focaliser sur l’email afin d’être un spécialiste de l’intégration HTML de ce médium. Depuis fin 2014, Thomas collabore à divers projets de l'Agence Badsender.com.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *