Accessibilité HTML de vos emails

publié le 16/08/2023
, mis à jour le
21/12/2023

Restez informé·e via les newsletters de Badsender

Chaque mois, nous publions une newsletter sur l’email marketing et une infolettre sur la sobriété et le marketing. En savoir plus.

Votre adresse email ne sera jamais communiquée à un tiers. Vous pourrez vous désabonner à tout moment en un seul clic.

Table des matières

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

L’accessibilité comme nouvelle tendance ?

Cela nous choque de parler de tendance lorsqu’on parle d’accessibilité. L’accessibilité est un devoir et c’est une bonne pratique à part entière dans la conception de vos templates HTML. 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.

« 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.

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…

<html lang="fr">

Sans cette indication, un lecteur d’écran va utiliser la langue dans lequel il est configuré par défaut.

Encoder correctement les caractères HTML

Pour ce faire, ajouter le code HTML suivant :

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Ce code indique au navigateur ou au client de messagerie quel type de caractères est attendu dans le code suivant.

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.

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`.

<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:o="urn:schemas-microsoft-com:office:office">

Corriger le DPI pour les images

Cette partie du code s’ajoute juste avant la fermeture de la balise head.

<!--[if gte mso 9]> <xml>     <o:OfficeDocumentSettings>     <o:AllowPNG/>     <o:PixelsPerInch>96</o:PixelsPerInch>     </o:OfficeDocumentSettings> </xml> <![endif]--> </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.

<!-- 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;">

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.

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.

Prendre garde aux gifs animés

Les 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.)

Besoin d'aide ?

Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.

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é.

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.

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.

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.

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.

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…

Maintenir une structure de lecture logique (de gauche à droite).

Cela permet aussi d’aider les destinataires souffrant de dyslexie à maintenir leur rythme de lecture.

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.

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.

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.

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.

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.

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).

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é.

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.

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.

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.

« Any implementation of accessibility, however small, is a success. »
Paul Airy

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 comme « Template emailing 1,2,3… Maximum texte et full responsive !« .

Quelques acronymes à connaître sur l’accessibilité

a11y : Hashtag et acronyme pour Accessibilité/accessibility.
ACTA : Auditory Calls-to-Action
ARIA : Assistive/Accessible Rich Internet Applications
WCAG : Web Content Accessibility Guidelines
W3C : World Wide Web Consortium
ADA : American with Disabilities Act
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.

Soutenez l'initiative "Email Expiration Date"

Brevo et Cofidis soutiennent financièrement le projet. Rejoignez le mouvement et ensemble, responsabilisons l’industrie de l’email face à l’urgence climatique.

Partagez

L’auteur

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.

Toutes les publications