Le ticket de support client était déroutant au départ. "Je ne peux pas utiliser vos e‑mails." L’utilisateur a expliqué qu’il était aveugle et utilisait un lecteur d’écran. Les e‑mails magnifiquement conçus de l’entreprise n’étaient qu’un mur de "image image image lien lien lien" — pas de texte alternatif, pas de structure sémantique, aucune façon de comprendre le contenu.
L’accessibilité des e‑mails n’est pas facultative. Au-delà de l’impératif éthique d’inclure tout le monde, il existe des exigences légales dans de nombreuses juridictions. Et concrètement, des e‑mails accessibles sont de meilleurs e‑mails — structure plus claire, meilleure expérience mobile, rendu plus fiable.
Cette liste de contrôle couvre les considérations techniques et de design qui font fonctionner les e‑mails pour tout le monde.
Images et médias
Toutes les images ont un texte alternatif (alt). Chaque balise <img> doit avoir un attribut alt. Décrivez ce que montre l’image, pas seulement que c’est une image. "Photo produit de chaussures de course bleues" est utile. "Image" ne l’est pas.
Les images décoratives ont un alt vide. Les images qui ne véhiculent pas d’information (espaces, bordures décoratives) doivent avoir alt="" pour que les lecteurs d’écran les ignorent. N’omettez pas totalement l’attribut alt — cela amène les lecteurs d’écran à lire le nom de fichier.
Le texte alternatif est concis mais complet. Visez moins de 125 caractères. Décrivez l’information essentielle. Pour les images complexes comme des graphiques, fournissez un résumé textuel à proximité.
Les images ne sont pas le seul moyen de transmettre une information. Si une image contient du texte, ce texte doit également apparaître comme du vrai texte. Si un graphique montre des données, résumez les principaux enseignements en texte.
Les GIF animés sont utilisés avec parcimonie. Un contenu clignotant ou changeant rapidement peut déclencher des crises. Si vous utilisez une animation, assurez-vous qu’elle ne clignote pas plus de trois fois par seconde. Fournissez un moyen de mettre l’animation en pause si possible.
Texte et typographie
La taille de police est lisible. Minimum 14px pour le corps du texte, idéalement 16px. Un texte plus petit est difficile pour beaucoup d’utilisateurs, pas seulement ceux ayant des déficiences visuelles.
L’interligne est suffisant. Au moins 1.5x la taille de police. Un texte tassé est difficile à lire pour tout le monde et particulièrement pour les personnes dyslexiques ou avec des déficiences cognitives.
Le contraste des couleurs respecte les normes WCAG. Le texte doit avoir un ratio de contraste d’au moins 4.5:1 par rapport à son arrière-plan (3:1 pour le texte de grande taille). Utilisez un outil de vérification du contraste pour le confirmer.
La couleur n’est pas le seul indicateur. Ne vous fiez pas uniquement à la couleur pour transmettre un sens. "Les champs en rouge sont obligatoires" échoue pour les personnes daltoniennes. Utilisez des icônes, des libellés textuels ou des motifs en plus de la couleur.
Le texte peut être redimensionné. Utilisez des unités relatives (em, rem, %) plutôt que des pixels fixes lorsque c’est possible. Les utilisateurs qui ont besoin d’un texte plus grand doivent pouvoir l’obtenir.
Structure et sémantique
Les titres créent une hiérarchie logique. Utilisez des balises de titre (h1, h2, h3) pour structurer le contenu. Ne sautez pas de niveaux. Les utilisateurs de lecteurs d’écran naviguent par titres — une hiérarchie correcte rend cela possible.
Les tableaux sont utilisés pour des données, pas pour la mise en page. Les tableaux de mise en page perturbent les lecteurs d’écran. Utilisez des tableaux uniquement pour des données tabulaires réelles. Pour la mise en page, utilisez d’autres techniques (même si les contraintes du HTML des e‑mails rendent cela difficile).
Les tableaux de données ont des en-têtes. Utilisez <th> pour les cellules d’en-tête avec scope="col" ou scope="row". Cela indique aux lecteurs d’écran comment associer les cellules de données à leurs en-têtes.
L’ordre de lecture est logique. Les lecteurs d’écran suivent l’ordre du DOM, pas l’ordre visuel. Assurez-vous que l’ordre HTML a du sens lorsqu’il est lu linéairement, même si le CSS réorganise l’affichage.
La langue est spécifiée. Incluez lang="en" (ou le code de langue approprié) sur l’élément HTML. Cela aide les lecteurs d’écran à utiliser la bonne prononciation.
Liens et boutons
Le texte des liens est descriptif. "Cliquez ici" et "Lire la suite" n’ont aucun sens hors contexte. Les utilisateurs de lecteurs d’écran naviguent souvent par liens — "Lire notre politique de confidentialité" leur indique où mène le lien.
Les liens sont visuellement distincts. Les soulignements sont l’indicateur le plus fiable. La couleur seule n’est pas suffisante pour les personnes daltoniennes.
Les cibles tactiles sont suffisamment grandes. Minimum 44x44 pixels pour les éléments cliquables. De petits liens sont difficiles pour les personnes avec des troubles moteurs et frustrants pour tout le monde sur mobile.
Les liens ont des états de focus. Les utilisateurs au clavier doivent voir quel élément est focalisé. Assurez-vous que les styles de focus sont visibles et distincts.
Formulaires (si applicable)
Les champs de formulaire ont des libellés. Chaque champ input doit avoir un libellé associé. Utilisez <label for="fieldid"> ou encapsulez l’input dans l’élément label.
Les messages d’erreur sont clairs. Expliquez ce qui ne va pas et comment le corriger. Ne vous contentez pas de surligner le champ en rouge — fournissez une explication textuelle.
Les champs obligatoires sont indiqués. Indiquez clairement les champs obligatoires, en utilisant du texte ("obligatoire") et pas seulement des astérisques ou la couleur.
Tester l’accessibilité
Testez avec un lecteur d’écran. NVDA (Windows, gratuit), VoiceOver (Mac/iOS, intégré) et TalkBack (Android, intégré) sont les principales options. Écoutez comment votre e‑mail est lu, pas seulement comment il apparaît.
Testez la navigation au clavier. Pouvez-vous atteindre tous les éléments interactifs avec Tab ? L’ordre de focus est-il logique ? Pouvez-vous activer les liens et les boutons avec Entrée ?
Testez avec les images désactivées. De nombreux clients de messagerie bloquent les images par défaut. Votre e‑mail est-il compréhensible sans elles ?
Testez à différents niveaux de zoom. Zoomez à 200 % dans votre navigateur. La mise en page fonctionne-t-elle toujours ? Le texte reste-t-il lisible ?
Utilisez des outils automatisés. WAVE, axe et des outils similaires détectent des problèmes courants. Ils ne détectent pas tout — des tests manuels restent nécessaires — mais c’est un bon point de départ.
Considérations spécifiques aux e‑mails
Le texte de préheader est pertinent. Les lecteurs d’écran peuvent annoncer le texte de préheader. Rendez-le utile, pas seulement "Voir dans le navigateur" ou des espaces vides.
La version texte brut est complète. Certains utilisateurs préfèrent ou nécessitent le texte brut. Assurez-vous que votre version texte contient toutes les informations de la version HTML.
La désinscription est facile à trouver. Ne la reléguez pas dans un texte minuscule. Les utilisateurs qui veulent se désabonner doivent pouvoir trouver l’option facilement.
Erreurs courantes
Utiliser des images contenant du texte. Le texte dans une image ne peut pas être redimensionné, ne se recompose pas et n’est pas lisible par les lecteurs d’écran. Utilisez du vrai texte autant que possible.
Texte justifié. La justification complète crée des espacements irréguliers difficiles pour les personnes dyslexiques. Utilisez un alignement à gauche.
« Choix de design » à faible contraste. Un texte gris clair sur un fond blanc peut paraître élégant mais ne respecte pas les exigences d’accessibilité. Priorisez la lisibilité plutôt que l’esthétique.
Absence de liens d’évitement. Pour les e‑mails longs, un lien "aller au contenu principal" aide les utilisateurs au clavier à passer la navigation répétitive.
Frequently asked questions
Les exigences d’accessibilité s’appliquent-elles à tous les e‑mails ?
Les exigences légales varient selon les juridictions et le contexte. Mais l’accessibilité bénéficie à tout le monde — structure plus claire, meilleure expérience mobile, rendu plus fiable. Il n’y a aucun inconvénient à rendre les e‑mails accessibles.
Comment tester des e‑mails avec un lecteur d’écran ?
Envoyez l’e‑mail à vous-même, ouvrez-le dans un client de messagerie, et utilisez un lecteur d’écran (VoiceOver sur Mac, NVDA sur Windows). Écoutez l’e‑mail en entier. Notez où l’information manque, est confuse ou dans le mauvais ordre.
Quel est le rapport de contraste minimal pour le texte ?
WCAG AA exige 4.5:1 pour le texte normal et 3:1 pour le texte de grande taille (18px+ ou 14px+ en gras). WCAG AAA exige 7:1 et 4.5:1 respectivement. Utilisez des outils comme le vérificateur de contraste de WebAIM pour le confirmer.
Puis-je utiliser du CSS pour des fonctionnalités d’accessibilité dans les e‑mails ?
Le support du CSS dans les e‑mails est limité et incohérent. Fiez-vous aux attributs HTML (alt, lang, scope) plutôt qu’à des solutions uniquement CSS. Testez sur plusieurs clients pour vous assurer que les fonctionnalités d’accessibilité fonctionnent.