Badsender

Accessibilité de vos emails : du design au HTML

  • , mis à jour le 

Restez informé·e via les newsletters de Badsender

Chaque mois, nous publions une infolettre sur l’email marketing et nous envoyons un email d’invitation à nos lives ou webinars. (2 emails par mois environ). En savoir plus.

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

L’accessibilité comme nouvelle tendance ?

Vu le nombre de publications autour du sujet et les hashtags #A11Y qui vont avec, nous pourrions nous demander. Mais chez Badsender, ça 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 email.

Paul Airy comme Litmus l’avaient bien rappelé en 2017 (oui oui 2017).

« Doing nothing is not a option. Email accessibility is our job. »

Paul Airy

Et d’autres grands acteurs de l’email, comme EmailOnAcid, évoquaient déjà largement le sujet également.

Il semblerait que le monde de l’Email Marketing se décide enfin à prendre de bonnes résolutions ou du moins le sujet en main. Dès lors que la règlementation, les obligations et potentielles sanctions montrent le bout de leur nez, tout de suite cela fait un peu plus réagir.

Chez Badsender, nous avons 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

Webinar avec Actito : Mardi 9 septembre à 11h30, en ligne, sur inscription

Que vous utilisiez Actito ou non, vous apprendrez forcément de ce webinar. Au programme : ce que dit la loi, des exemples concrets d’emails pour illustrer nos propos, et comment vous mettre en mouvement dès maintenant.

Inscrivez-vous


Table des matières

Pourquoi l’accessibilité et notamment celle des emails ?

L’accessibilité numérique est la mise à la disposition de tous les individus, quels que soient leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales, des ressources numériques.

Source : Wikipédia : Accessibilité numérique

Nous sommes ici face a des enjeux d’inclusions, d’égalité d’accès à des services ou produits, d’expérience utilisateur (UX).

C’est enjeux sont soumis en Europe depuis le 28 juin 2025 à un cadre légal. Par conséquent des obligations. Quand bien même vous ne souhaiteriez pas vous soumettre à ces obligations, il en va de la performance de vos campagnes, de votre image de marque et des valeurs que vous portez.

Le canal email est souvent le parent pauvre des projets numériques mais il fait partie intégralement de vos processus d’achat, création de compte, suivi de commande…

« A11Y », qu’est-ce que c’est ?

Vous avez peut-être déjà croisé cet acronyme ou hashtag sans trop comprendre. Ni comment le prononcer, ni savoir ce qu’il signifie réellement. Il s’agit de l’abréviation d’accessibilité en anglais.

Les 11 lettres entre le A et le Y de AccessibilitY.

Comme quoi, nous pouvons introduire des problèmes d’accessibilité en traitant du sujet lui même. Une bien belle ironie.

Accessibilité des emails, qui est concerné ?

“Les aveugles, c’est pas ma cible. »

Un retour client

Toute personne faisant de la conception a déjà, malheureusement, été confrontée à ce vilain poncif.

Certes en accessibilité numérique les handicaps visuels sont les premiers évoqués et 1.3 milliard de personnes à travers le monde vit avec une forme de déficience visuelle selon l’OMS. Toutefois il serait dommage de ne pas prendre en considération l’ensemble des handicaps afin de les confronter à la lecture d’un email.

  • handicap physique : atteinte partielle ou totale de la motricité
  • handicap sensoriel : organes sensoriels
  • handicap mental ou intellectuel : compréhension, connaissances et cognition
  • handicap cognitif : apprentissage, perception de l’environnement

Ce n’est ni exhaustif, ni précis dans les définitions. L’idée ici est de vous sensibiliser.

il y a 80 millions d’handicapés en Europe, soit 16 % de la population ou un Européen sur six. C’est considéré comme la première des causes de discrimination en Europe.

Source : Wikipédia : Handicap

Il n’y a pas de chiffre unique et les différentes publications de la DREES peuvent déjà permettre de se rendre compte de la situation et de sa complexité.

En tout cas si il y a une chose de sûr, que ce soit 20 ou 16 %, si c’était vos indicateurs de performance (ouverture, clic, désabonnement…), vous ne diriez plus que ce n’est pas votre cible ou que vous ne vous en souciez pas !

European Accessibility Act (EAA) : le décret européen

L’EAA, c’est la directive européenne (2019/882) qui a fait beaucoup parlé en ce début d’année 2025. Elle impose, depuis le 28 juin 2025, que de nombreux produits et services numériques soient accessibles aux personnes en situation de handicap.

En résumé, jusque là c’était principalement le secteur public et quelques entreprises privés ciblées. Maintenant l’EAA étend les obligations aux entreprises privées d’au moins 10 salariés et qui réalisent un chiffre d’affaires annuel supérieur à 2 millions d’euros.

Pour autant, ce ne sont pas de nouvelles règles du jeu qui sont arrivées avec l’EAA. Elles existaient depuis bien des années.

EN 301 549 : la norme européenne

Publiée par les organismes de normalisation européens, elle définit les exigences d’accessibilité pour les produits et services TIC (technologies de l’information et de la communication).

Elle a été conçue pour être alignée sur les WCAG (Web Content Accessibility Guidelines).

WCAG 2.1 / 2.2 : le socle technique international

Ce sont les recommandations techniques établies par le W3C (World Wide Web Consortium).

Pour tendre vers une mise en conformité de vos documents HTML (oui les emails que vous envoyez sont des documents HTML), c’est le point de départ d’une grande partie de ce que vous aurez à mettre en place.

RGAA (Référentiel Général d’Amélioration de l’Accessibilité) : application dans le droit français

C’est le référentiel français qui traduit la norme européenne EN 301 549. L’outil qui permet de tester différents critères afin d’évaluer l’accessibilité de vos produits et services numérique.

Je veux juste des emails accessibles, pas des textes de loi et des spécifications techniques

Oui cela fait une entrée en matière un peu longue (bien que non exhaustive et détaillée), mais surtout si vous fouillez un peu plus les différentes sources, vous aurez constaté une chose importante : aucun de ces documents ne parle des emails !

Il est question de site, d’applications, de documents PDF, de liseuse, de terminaux de paiement… mais jamais d’email.

Or c’est bien là que nous, Badsender, avons un problème.

Comment évaluer l’accessibilité si nous n’avons pas de cadre sur lequel nous appuyer ?

D’ailleurs, qu’est que l’on peut vraiment évaluer ?

  • Le template email fournis à l’annonceur (sans contenus)
  • L’email HTML intégré (avec les contenus mais pas importé par l’outil de gestion de campagne)
  • L’email interprété par la boite de réception (croyez moi vous ne voulez pas ça)
  • Si c’est le cas, dans quel client ou web mail
  • Avec quel outil de restitution ou synthèse vocale

Quand on connaît la fragmentation des environnements d’ouverture et l’impact qu’ils ont sur le code, cela veut dire que même malgré nos efforts eux peuvent ruiner tous vos efforts.

Puisqu’il y a un grand vide de ce côté là actuellement, nous avons tranché afin de pouvoir garantir nos livrables. Chez Badsender, nous avons mis en place une grille d’évaluation d’accessibilité qui couvre une soixantaine de critères spécifique à l’email et qui touche aussi bien à la stratégie, aux contenus, au design qu’au code HTML.

Qui doit agir ? Un expert accessibilité email ?

Comme souvent dans une organisation, dans l’idéal il faudrait un référent accessibilité, un porteur ou en tout cas un responsable. Une personnes qui sera garante de la conformité d’accessibilité dans le temps.

Dans les faits ce n’est pas aussi simple. Il faut du budget, un recrutement, de la formation… mais surtout pour vos campagnes emails, vous allez me dire que vous n’avez pas le temps. Et donc, constater les défauts d’accessibilité uniquement après les avoir envoyés. Dommage.

Dans le meilleur des mondes, ce sont tous les intervenants de la chaîne de production. Du brief au livrable :

  • Directeur Artistique au niveau de la charte afin que dès le début nous n’ayons pas de souci.
  • Designer et intégrateur email, c’est le sujet qui nous concerne directement chez Badsender. À nous d’adapter le design comme le code HTML.
  • Contributeurs (équipe marketing, CRM, rédacteurs, traducteurs) afin de mettre en place des contenus (textes, images, liens) qui respectent les bonnes pratiques d’accessibilité.

Nous n’aborderons pas ici l’impact éventuel d’un email builder ou bien de l’outil de gestion de campagne sur l’accessibilité de vos emails. Gardez juste en tête que chaque étape de production peut avoir un impact.

Mais rendre les emails « accessibles » n’est pas si complexe ou contraignant. De petits changements dans le graphisme ou dans les techniques de développement peuvent faire de grosses différences pour vos abonnés.

Les bonnes pratiques d’accessibilité à mettre en place dans le code de vos 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;">

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.

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.

L’HTML est correctement structuré, sans erreurs

Et quand les clients mail le permettront, utilisera les rôles ARIA (Assistive/Accessible Rich Internet Applications). 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.

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.

Garder un code concis et 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

Les bonnes pratiques d’accessibilité pour vos contenus et votre design

Insérer des textes en HTML plutôt qu’en image

Il s’agit de garantir l’accès à l’information en toutes circonstances. Vous voyez ces blocs d’introduction (header) avec une image de fond, un joli texte d’accroche, un code promo mis en forme et un bouton d’action le tout en une seule image. Comment rendre tout ça explicite avec un simple attribut alt ?

Prendre en compte les contrastes de couleurs (et de tailles)

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…

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.

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.

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.


Le contenu du message compris dans un gif animé est 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é.

Le contenu des liens doit avoir un sens et être descriptif

Préférez 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.

Proposez aussi les bons textes, sur les bons supports : « cliquer » pour un mobile qui ne comprend que le « tapotage » semblera peut-être incongru. 

Ne pas spécifier d’attribut title aux liens

Ils complexifient la lecture par les lecteurs d’écran. À la place, préférez 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.

Maintenir un sens de lecture logique

En déclarant le sens de lecture (gauche droite en occident par exemple), cela permet aussi d’aider les destinataires souffrant de dyslexie à maintenir leur rythme de lecture.

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

Adapter la tailles des textes 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 ?

Les media queries sont là-aussi pour parer à ces problématiques.

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

Les bonnes pratiques d’accessibilité pour vos campagnes

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 ? ». À nous donc de rédiger un texte pertinent. John affirme que les résultats obtenus sur leurs tests étaient intéressants.

Les assistants personnels et l’accessibilité

L’accessibilité peut impliquer de faire appel à des 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 : 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.

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 de nombreux articles ainsi que ce guide publié dans sa première version en 2023.

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.

Je me renseigne
Partagez
L’auteur
Image de Thomas Defossez
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