L’accessibilité était autrefois la dernière ligne de la checklist e-mail, celle qu’on traitait s’il restait du temps. C’est terminé. L’European Accessibility Act est en vigueur depuis le 28 juin 2025, et les mêmes correctifs de texte alternatif et de contraste qui aident une personne équipée d’un lecteur d’écran décident aussi si votre message survit images désactivées ou s’il déclenche un filtre antispam. L’accessibilité est désormais à la fois un problème de portée, un problème juridique et un problème de délivrabilité.
Commençons donc par ce que nous mesurons réellement. Sur les e-mails passés par Unspam, 84 % passent leurs contrôles d’accessibilité, ce qui paraît sain jusqu’à ce qu’on voie où les échecs se regroupent : attributs de langue absents, tableaux de mise en page non marqués, contraste faible et texte alternatif manquant. C’est l’écart que ce guide comble. Il est écrit pour les deux moitiés de la salle, le marketeur qui a besoin du quoi et du pourquoi, et le développeur qui a besoin du comment, avec du vrai code prêt à coller là où cela compte.
Qu’est-ce que l’accessibilité des e-mails ?
L’accessibilité des e-mails consiste à construire un e-mail que tout le monde peut percevoir, utiliser et comprendre, y compris les personnes qui passent par un lecteur d’écran, naviguent au clavier, agrandissent le texte, lisent en mode sombre, ou qui ont une vision faible ou un daltonisme. En pratique, ce sont les principes de WCAG 2.2 (perceptible, utilisable, compréhensible, robuste) appliqués aux contraintes de la boîte de réception : du vrai texte plutôt que des images figées, un texte alternatif descriptif, un contraste de couleurs suffisant, une structure sémantique et une langue déclarée.
Contrairement à l’accessibilité web, l’accessibilité des e-mails contourne les contraintes de la boîte de réception : pas de CSS externe, une mise en page à base de tableaux et des clients de messagerie qui bloquent les images par défaut. Les principes sont les mêmes, mais les tactiques sont façonnées par l’endroit où le message atterrit.
Les bonnes pratiques d’accessibilité en un coup d’œil
Voici les pratiques essentielles, dans l’ordre où la plupart des e-mails se trompent. Chacune est détaillée plus bas avec son mode opératoire.
- Donnez à chaque image informative un texte
altdescriptif, et aux images décoratives unalt=""vide - Structurez le message avec de vrais titres
<h1>à<h6>, pas du texte mis en gras - Ajoutez
role="presentation"à chaque tableau de mise en page pour que les lecteurs d’écran lisent le contenu linéairement - Respectez le contraste de couleurs : 4,5:1 pour le texte normal, 3:1 pour le grand texte et les éléments d’interface
- Concevez pour le mode sombre et testez le contraste dans les deux modes
- Écrivez un texte de lien qui décrit sa destination, jamais « cliquez ici »
- Gardez des zones tactiles confortables et un texte courant de 14 à 16px
- Déclarez la langue avec
<html lang="en">et envoyez une vraie partie en texte brut
Ce que nous voyons sur les e-mails que nous testons
La plupart des guides d’accessibilité argumentent à partir de statistiques d’audience : combien de personnes vivent avec un handicap. C’est réel, et c’est traité plus bas, mais ce ne sont pas des preuves sur votre e-mail. Les chiffres de cette section en sont, parce qu’ils viennent des e-mails réellement passés par Unspam.
- 84 % des e-mails que nous contrôlons passent leurs contrôles d’accessibilité. C’est bien plus optimiste que le chiffre tout ou rien de « 99,88 % des e-mails échouent » que vous avez peut-être vu cité, et c’est plus utile : un score gradué vous dit que la plupart des e-mails ont déjà fait presque tout le chemin, et que l’écart restant est petit et refermable.
- Quand un e-mail échoue vraiment, les manques se regroupent dans quelques endroits prévisibles : un attribut
langabsent, des tableaux de mise en page non marqués, un contraste faible et un texte alternatif manquant. - Notre contrôle d’accessibilité signale spécifiquement le texte invisible ou illisible pour un humain à cause de la couleur du texte et de l’arrière-plan, autrement dit un contraste de couleurs faible. Son but entier est de vous donner une vue d’ensemble de votre situation et de ce qu’il faut corriger.
Il est utile de lire ces 84 % à côté du reste de ce que nous mesurons. Les signaux de contenu sont invariablement le point faible : seuls 30 % des e-mails passent nos contrôles de bonnes pratiques HTML, le taux de réussite le plus bas de tout ce que nous testons. L’accessibilité, à 84 %, est en bien meilleure forme que le HTML sous votre e-mail, ce qui vous dit que les gains sont précis et ciblés plutôt qu’une refonte.
Un attribut alt vide est une décision. Un attribut absent est un accident qui lit votre nom de fichier à voix haute.
Pourquoi l’accessibilité des e-mails compte
L’audience est plus large que vous ne le pensez
L’argument de la portée est simple. Aux États-Unis, plus d’un adulte sur quatre, soit 28,7 % ou plus de 70 millions de personnes, déclarait un handicap en 2022 (CDC, d’après l’enquête BRFSS 2022), dont 5,5 % un handicap visuel en particulier. À l’échelle mondiale, l’Organisation mondiale de la santé estime qu’au moins 2,2 milliards de personnes vivent avec une déficience visuelle de près ou de loin. Le daltonisme touche à lui seul environ 1 homme sur 12 et à peu près 1 femme sur 200 d’origine nord-européenne (Colour Blind Awareness). Et une large part des e-mails est ouverte sur mobile, où un texte petit et des zones tactiles minuscules pénalisent tout le monde, pas seulement les personnes avec une déficience diagnostiquée.
Vous n’avez pas besoin que chacune de ces personnes soit aveugle pour que le travail paie. Un titre à faible contraste est aussi difficile à lire sur un téléphone en plein soleil pour une personne qui voit parfaitement.
Le paysage juridique
Le droit de l’accessibilité est maintenant assez réel pour que « nous ne savions pas » ne soit plus une défense. Trois régimes comptent le plus pour les expéditeurs d’e-mails, et ils ne s’accordent pas sur les détails.
| Régime | Qui il couvre | Norme | En vigueur |
|---|---|---|---|
| European Accessibility Act (directive (UE) 2019/882) | Les entreprises, y compris hors UE, qui vendent dans l’UE des produits et services couverts, commerce en ligne et communications électroniques inclus | EN 301 549, qui intègre WCAG | Obligations applicables depuis le 28 juin 2025 |
| ADA Title III (États-Unis) | Les lieux ouverts au public aux États-Unis, les tribunaux traitant les sites et applications d’entreprise comme couverts | Aucune norme WCAG codifiée, WCAG 2.1 AA est la référence de fait dans les accords transactionnels | ADA depuis 1990, la position sur le web reste en construction |
| ADA Title II (États-Unis) | Les sites et applications des États et des collectivités américaines | WCAG 2.1 AA (règle du DOJ de 2024) | Délais prolongés : 26 avril 2027 (population de 50 000 et plus), 26 avril 2028 (en dessous) |
| Section 508 (États-Unis) | Les agences fédérales américaines et leurs fournisseurs | WCAG 2.0 AA, une version derrière Title II | Obligatoire depuis le 18 janvier 2018 |
Quelques réserves honnêtes. L’EAA ne nomme pas l’« emailing » comme catégorie ; sa portée sur l’e-mail est indirecte mais réelle, plus forte pour les messages transactionnels et de service rattachés à un service de commerce en ligne ou bancaire couvert, et plus grise pour les envois purement promotionnels, où le traitement dépend de la transposition nationale. L’ADA Title III ne fixe aucune règle WCAG pour les entreprises privées ; WCAG 2.1 AA est ce que retiennent les tribunaux et les accords transactionnels, pas un texte de loi. Aucune certification ne rend un e-mail formellement conforme à l’ADA ; la conformité à WCAG 2.1 ou 2.2 AA est ce que l’expression signifie en pratique. Et les échéances américaines du Title II pour les administrations ont été repoussées d’un an en avril 2026, donc les dates actuelles sont 2027 et 2028, et non 2026 et 2027. La lecture prudente de tout cela : construisez pour WCAG 2.2 AA et vous franchissez la barre partout où il y en a une.
L’argument économique
L’accessibilité n’est pas une œuvre de charité qui vous coûte de l’argent. Elle recoupe presque entièrement le travail qui améliore le rendu et la délivrabilité :
- Résistance aux images désactivées. Beaucoup de clients de messagerie bloquent les images par défaut. Un texte alternatif descriptif devient votre texte de repli, donc le message survit intact, que le lecteur soit aveugle ou qu’il ait simplement désactivé les images.
- Score de spam. Les filtres se méfient des e-mails tout en images. Du vrai texte vivant améliore le ratio texte/image, ce qui aide à la fois les personnes équipées d’un lecteur d’écran et votre placement en boîte de réception.
- Une vraie partie en texte brut. Un authentique message
multipart/alternativeavec une partietext/plaincorrecte sert les clients de messagerie en texte seul et les outils d’assistance, et améliore le placement en boîte de réception. Un seul correctif, deux gains. - Engagement. Une taille de police lisible et un contraste fort augmentent la lisibilité pour tout le monde, ce qui augmente les signaux d’engagement que les fournisseurs de messagerie récompensent. Une heatmap d’e-mail montre si les lecteurs atteignent vraiment votre CTA une fois que le texte est lisible.
WCAG pour l’e-mail : quels critères s’appliquent vraiment
La plupart des guides citent WCAG A/AA/AAA et passent à autre chose. Voici la correspondance concrète, critère par critère, et comment satisfaire chacun dans un e-mail.
| Critère WCAG 2.2 | Niveau | Ce que cela veut dire dans un e-mail | Comment le satisfaire |
|---|---|---|---|
| 1.1.1 Contenu non textuel | A | Les images ont besoin d’alternatives textuelles | alt descriptif sur les images informatives, alt="" sur les décoratives |
| 1.3.1 Information et relations | A | La structure doit être programmatique, pas seulement visuelle | De vrais titres <h1> à <h6>, role="presentation" sur les tableaux de mise en page |
| 1.4.3 Contraste (minimum) | AA | Le texte doit être lisible sur son arrière-plan | 4,5:1 pour le texte normal, 3:1 pour le grand texte |
| 1.4.11 Contraste du contenu non textuel | AA | Les objets d’interface et graphiques doivent être distinguables | 3:1 pour les boutons, les icônes, les états de focus |
| 2.4.4 Fonction du lien | A | Le texte du lien doit avoir du sens hors contexte | Décrivez la destination, pas de « cliquez ici » nu |
| 2.5.8 Taille de la cible (minimum) | AA | Les cibles interactives doivent être assez grandes pour être atteintes | 24 x 24 px CSS minimum, ou l’exception d’espacement |
| 3.1.1 Langue de la page | A | Le logiciel du lecteur doit connaître la langue | <html lang="en">, lang en ligne sur les fragments étrangers |
Deux d’entre eux, le contraste et la taille des cibles, sont fixés précisément dans la section design ci-dessous, parce que ce sont ceux que les gens citent de travers.
Comment rendre un e-mail accessible : contenu et structure
De vrais titres, pas du texte mis en forme
Les personnes équipées d’un lecteur d’écran naviguent dans un contenu long en sautant de titre en titre. Cela ne marche que si vos titres sont de véritables éléments de titre.
- Utilisez
<h1>à<h6>pour la hiérarchie, pas un<span>en gras ni un gros<td>qui ressemble seulement à un titre. - Utilisez un seul
<h1>logique et imbriquez vers le bas sans sauter de niveau. Un<h2>suivi d’un<h4>casse le modèle de parcours par titres, et c’est un point que nous signalons. - Gardez l’ordre du source (DOM) identique à l’ordre de lecture. Les lecteurs d’écran et le rendu mobile linéarisé suivent l’ordre du source, pas la position visuelle définie en CSS, donc ne comptez jamais sur le CSS pour réordonner le sens.
Des liens descriptifs, jamais « cliquez ici »
Un lecteur d’écran peut afficher la liste de tous les liens du message, lus hors contexte. « Cliquez ici » cinq fois de suite est inutile dans cette liste.
- Écrivez un texte de lien qui nomme la destination : « lisez la checklist de délivrabilité », pas « en savoir plus ».
- Évitez les URL brutes comme texte de lien, elles sont lues caractère par caractère.
- Gardez les mots porteurs de sens à l’intérieur du lien, pas autour.
Design d’e-mail accessible
Contraste de couleurs et taille des cibles
Le contraste est le critère sur lequel le contrôle d’Unspam se concentre, en signalant le texte pratiquement invisible sur son arrière-plan. Les seuils sont exacts, et ce sont des seuils, pas des cibles à arrondir : 4,499:1 échoue face à 4,5:1.
| Contenu | Minimum WCAG AA | WCAG AAA |
|---|---|---|
| Texte normal (moins de 18pt / moins de 14pt gras) | 4,5:1 | 7:1 |
| Grand texte (18pt normal / 14pt gras et plus) | 3:1 | 4,5:1 |
| Composants d’interface et objets graphiques | 3:1 | sans objet |
« Grand texte » a une définition exacte partagée par ces critères : 18pt normal (environ 24px) ou 14pt gras (environ 18,66px). Tout ce qui est plus petit compte comme texte normal et doit le plein 4,5:1.
La taille des cibles est celle que tout le monde énonce de travers. Le minimum AA de WCAG 2.2 (SC 2.5.8) est de 24 x 24 px CSS, avec une exception d’espacement pour les cibles plus petites qui ne sont pas serrées par d’autres cibles. Le fameux chiffre de 44 x 44 est plus strict : c’est du WCAG AAA (SC 2.5.5) et le minimum des Apple Human Interface Guidelines, pas l’exigence AA. Donc « WCAG exige 44 x 44 » est une erreur courante. Traitez 24 x 24 comme conforme et 44 x 44 comme confortable à l’usage, et visez le second sur tout CTA principal.
- Ne portez jamais le sens par la couleur seule. Associez un état d’erreur coloré à une icône ou à un libellé, et soulignez les liens pour que le daltonisme ne les cache pas.
- Donnez aux boutons une taille réellement tactile et une marge intérieure généreuse, surtout sur mobile.
Typographie et mise en page
- Réglez le texte courant de 14 à 16px, avec une préférence pour 16px sur mobile, et utilisez des tailles plus grandes pour les titres.
- Utilisez une mise en page responsive sur une seule colonne, qui se réagence proprement au zoom et sur écran étroit. La même discipline se retrouve dans le design d’e-mail actuel.
- Gardez des lignes d’environ 45 à 75 caractères, ce qu’une mise en page sur une colonne de 600px à 16px atteint naturellement, et réglez l’interligne autour de 1,5. Déclarez des polices de repli pour qu’une police web non prise en charge se dégrade en quelque chose de lisible.
Le texte alternatif bien fait
Le texte alternatif manquant est l’un des manques que notre contrôle signale, et le correctif est précis, pas juste « ajoutez alt partout ».
- Images informatives : décrivez la fonction ou le contenu, pas le support. Écrivez
alt="Spring sale, 30% off all boots", pasalt="banner image", et jamaisalt="image of...". - Images décoratives : donnez-leur un
alt=""vide et explicite (alt nul) pour que les lecteurs d’écran les sautent entièrement. Il s’agit d’un espaceur, d’un séparateur, d’une fioriture d’arrière-plan. - N’omettez pas
altentièrement. Un attribut absent n’est pas la même chose qu’un attribut vide, et certains lecteurs réagissent en annonçant le nom du fichier ou l’URL à voix haute, exactement l’accident que décrivait la citation plus haut. - Souvenez-vous que le texte alternatif est aussi votre texte de secours images désactivées, donc écrivez-le pour que le message reste intact quand l’image ne charge jamais.
Le revers du texte alternatif, c’est de ne pas en avoir besoin. Le moyen le plus rapide d’échouer à tous les contrôles d’un coup est l’e-mail tout en images : un titre cuit dans un JPEG ne peut pas être lu par un lecteur d’écran, ne peut pas se réagencer au zoom, ne peut pas s’adapter au mode sombre et disparaît entièrement images désactivées. Gardez les titres, le texte courant et les boutons en vrai texte HTML, et réservez les images à ce que seule une image peut montrer.
Animation et GIF
L’animation a des règles dures. Gardez tout GIF sous trois flashs par seconde, arrêtez-le après environ trois boucles ou cinq secondes, et mettez le message complet dans la première image, parce que les anciennes versions d’Outlook ne montrent jamais que la première. Pour les clients de messagerie qui le prennent en charge, prefers-reduced-motion vous permet de basculer sur une image fixe pour les lecteurs qui ont demandé moins de mouvement à leur appareil.
Code d’e-mail accessible
Voici la moitié développeur. Tout est prêt à coller.
role="presentation" sur les tableaux de mise en page
L’e-mail utilise encore des tableaux pour la mise en page. Laissé sans marquage, un lecteur d’écran annonce chaque ligne, chaque colonne et chaque cellule comme des données, ce qui n’est que du bruit. Marquez chaque tableau de mise en page pour qu’il se lise linéairement :
<table role="presentation" cellpadding="0" cellspacing="0" border="0" width="100%">
<tr>
<td>Your actual content, read in source order.</td>
</tr>
</table>
role="none" est un synonyme, mais role="presentation" bénéficie de la prise en charge la plus large par les technologies d’assistance, donc préférez-le. Appliquez-le à chaque tableau de mise en page, y compris les imbriqués.
lang (et dir) pour que la voix soit juste
Les lecteurs d’écran choisissent leur prononciation et leur profil de voix d’après la langue déclarée du document. Sans lang, le lecteur retombe sur la valeur par défaut de son système et prononce tout de travers, du texte français lu avec la phonétique anglaise, par exemple. Un lang absent est l’un des défauts les plus courants dans le monde réel sur l’ensemble des e-mails, et il coûte une ligne à corriger :
<html lang="en" dir="ltr">
Pour une écriture de droite à gauche, mettez dir="rtl". Pour un contenu multilingue, surchargez fragment par fragment avec un attribut en ligne : <span lang="fr">merci beaucoup</span>.
Des CTA à toute épreuve et accessibles
Construisez les boutons comme de vrais liens stylés pour ressembler à des boutons, dimensionnés pour le toucher, avec un texte descriptif à l’intérieur de l’ancre :
<a href="https://example.com/checklist"
style="display:inline-block; padding:14px 28px; font-size:16px;
background:#1a4d8f; color:#ffffff; text-decoration:none;
border-radius:6px;">
Read the deliverability checklist
</a>
Le texte du lien porte le sens à lui seul, la marge intérieure lui donne une cible confortable, et l’association de couleurs franchit 4,5:1.
Mode sombre et accessibilité
Le mode sombre n’est pas un comportement, il en est trois, et chacun peut casser le contraste à sa manière : l’inversion complète (arrière-plan et texte tous deux retournés), l’inversion partielle (texte retourné, arrière-plans en grande partie conservés) et l’absence de changement. Le cas partiel est le dangereux, parce que les palettes à moitié retournées produisent des combinaisons boueuses et peu contrastées que vous n’avez jamais conçues.
Signalez votre intention pour que l’inversion automatique agressive recule :
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
Associez-la ensuite au color-scheme CSS correspondant sur votre body. Deux bizarreries de clients de messagerie à contourner :
- Apple Mail inverse le
#000000pur et le#FFFFFFpur. La solution de contournement est un presque-noir et un presque-blanc,#000001et#FFFFFE, visuellement identiques mais exemptés du retournement forcé. - Outlook pour ordinateur (Microsoft 365 sous Windows) fait une inversion complète, le mode le plus invasif, en recolorant même les designs sombres. Outlook.com sur le web fait une inversion partielle, en détectant les arrière-plans clairs et en les retournant, et il ajoute les attributs
data-ogscetdata-ogsbà vos éléments quand il réécrit les couleurs, ce qui rend possible le ciblage[data-ogsc]pour le mode sombre.
La règle qui survit à tout cela : le contraste s’applique aussi en mode sombre. Prévisualisez votre e-mail en mode sombre dans de vrais clients de messagerie et testez les deux modes face à 4,5:1 et 3:1. Les logos et les icônes sur fond transparent sont l’échec classique du mode sombre, invisibles dès l’instant où l’arrière-plan se retourne sous eux.
Comment les lecteurs d’écran traitent Gmail, Outlook et Apple Mail
Le même e-mail accessible est annoncé et affiché différemment selon le client de messagerie et le lecteur d’écran. Cela façonne ce que vous optimisez.
| Client de messagerie et lecteur | Ce que la ligne de la boîte de réception annonce | À l’intérieur du message ouvert |
|---|---|---|
| Apple Mail + VoiceOver | Expéditeur, objet, heure de réception | Contrôle-Option-J lit le corps du message |
| Outlook + VoiceOver (Mac) | Expéditeur, objet, date, présence de pièces jointes | Les flèches gauche et droite parcourent le contenu du message |
| Gmail (mode lecteur d’écran) | Passe d’une conversation à l’autre avec j/k ou les flèches, Entrée ou o pour ouvrir | n lit chaque message non lu, du plus ancien au plus récent |
L’implication est pratique : l’objet et le préheader font le gros du travail, parce qu’ils sont annoncés avant même que le corps soit ouvert. Une fois le lecteur à l’intérieur, vos titres et vos tableaux role="presentation" décident de la navigabilité du corps.
Deux détails en découlent. Si vous employez l’astuce du préheader masqué, les caractères de remplissage invisibles qui tiennent votre texte courant hors de l’aperçu de la boîte de réception ne sont pas invisibles pour un lecteur d’écran, donc enveloppez le span de remplissage dans aria-hidden="true" pour que la technologie d’assistance le saute au lieu de lire un mur de rien. Et un lecteur d’écran annonce chaque emoji par son nom complet, donc un objet qui s’ouvre sur deux cotillons est entendu comme du bruit avant que votre offre n’arrive. Employez les emoji avec parcimonie, placez-les à la fin de l’objet ou de la phrase, et ne laissez jamais l’un d’eux remplacer un mot dont le message a besoin.
Comment tester l’accessibilité d’un e-mail
Le test est l’endroit où la plupart des guides font un geste vague vers une liste d’outils. Voici la version plus profonde.
Lancez d’abord un contrôle automatique
Commencez par la passe rapide et reproductible. Le contrôle d’accessibilité d’Unspam tourne à l’intérieur du test de spam gratuit sur la page d’accueil, en modélisant votre e-mail face à WCAG 2.2 AA et en analysant sept choses à la fois : le contraste de couleurs (cible 4,5:1), le texte alternatif des images, le comportement en mode sombre, l’ordre des titres sans niveau sauté, le texte descriptif des liens, la taille des zones tactiles et un attribut lang déclaré. Il vous donne une vue graduée de votre situation et de ce qu’il faut améliorer, plutôt qu’un verdict unique de réussite ou d’échec.
Associez-le aux contrôles de contenu voisins qui recoupent l’accessibilité : le spam word checker pour le texte qui nuit à la fois à la lisibilité et au placement, et l’outil email verifier pour garder la liste elle-même propre, afin que vos e-mails accessibles atteignent vraiment des personnes engagées.
Testez ensuite avec un vrai lecteur d’écran
Les scores automatiques attrapent les défauts mécaniques. Ils ne peuvent pas vous dire si votre texte alternatif a vraiment du sens lu à voix haute. Pour cela, testez à la main, idéalement avec les lecteurs gratuits intégrés aux plateformes que votre audience utilise :
- Envoyez-vous l’e-mail et ouvrez-le dans le client de messagerie visé.
- Activez le lecteur d’écran (VoiceOver chez Apple, NVDA sous Windows, TalkBack sous Android).
- Écoutez l’ordre de lecture. Le message a-t-il du sens lu linéairement ? Les titres sont-ils annoncés comme des titres ?
- Vérifiez que les images décoratives sont sautées et que les informatives lisent une description utile.
- Confirmez que les liens annoncent leur destination hors contexte.
Contrôles au clavier et au zoom
- Parcourez le message avec la touche Tab. Chaque élément interactif doit être atteignable et porter un état de focus visible.
- Zoomez à 200 %. Le texte doit se réagencer dans la colonne unique sans être coupé ni provoquer de défilement horizontal.
- Affichez l’e-mail images désactivées et confirmez que le texte alternatif porte le message à lui seul.
Ce qu’il faut corriger en premier
Si vous n’avez qu’une heure, dépensez-la dans cet ordre. Ce classement croise nos propres données avec le classement de fréquence des problèmes du rapport 2026 sur l’accessibilité de l’Email Markup Consortium, qui constate qu’un dir absent et un lang absent sont les défauts les plus courants dans le monde réel, devant les tableaux de mise en page sans role, le contraste faible et le texte alternatif manquant.
- Ajoutez l’attribut
lang(etdir). Une ligne, absente presque partout, gain immédiat pour toute personne équipée d’un lecteur d’écran. - Marquez chaque tableau de mise en page
role="presentation". Transforme un mur de bruit tabulaire en contenu linéaire. - Corrigez le texte alternatif manquant. Un attribut
altabsent fait disparaître l’image en silence, et un alt descriptif vous protège aussi images désactivées. - Réparez le contraste de couleurs faible. Le contrôle qu’Unspam signale directement, et celui qui pénalise aussi les lecteurs mobiles qui voient très bien.
- Remplacez le texte mis en forme par de vrais titres. Débloque la navigation par titres.
- Réécrivez les liens « cliquez ici » nus. Peu coûteux, et cela rend votre liste de liens utilisable.
La checklist d’accessibilité des e-mails (à copier)
- Chaque image informative a un texte
altdescriptif, les images décoratives ontalt="" - De vrais titres
<h1>à<h6>dans l’ordre, sans niveau sauté -
role="presentation"sur chaque tableau de mise en page - Contraste du texte au moins 4,5:1 (3:1 pour le grand texte et les éléments d’interface)
- Le sens n’est jamais porté par la couleur seule
- Le texte du lien décrit sa destination, pas de « cliquez ici »
- Texte courant de 14 à 16px, zones tactiles confortables sur les CTA
-
<html lang="...">déclaré,dirdéfini pour le RTL - Méta
color-schemedéfinie et les deux modes testés pour le contraste - Une vraie partie
text/plaindans un messagemultipart/alternative - Testé avec un vrai lecteur d’écran, au clavier, au zoom et images désactivées
L’accessibilité n’est pas une grande refonte, c’est cette poignée d’habitudes appliquées avant chaque envoi, et la plupart d’entre elles aident au passage votre délivrabilité. Vous voulez savoir où en est votre prochaine campagne ? Lancez un test de spam gratuit et lisez votre score d’accessibilité en 30 secondes environ, sans inscription.
