Accessibilité des e-mails HTML : guide pour les développeurs

Pour une équipe qui écrit ses e-mails en code, notre choix pour l'accessibilité est MJML. Le balisage qu'il produit reste lisible, chaque table de mise en page et chaque attribut alt se vérifient directement dans le fichier source, et les revues de code montrent clairement ce qui a changé. MJML est auto-hébergé et sa page tarifaire ne publie aucun palier payant à reprendre ici ; le détail figure sur mjml.io/pricing. Pour contrôler le résultat avant envoi, ajoutez Email on Acid : son plan Premium, à 199 $ par mois pour 2 000 aperçus, est le seul de ses plans listés à inclure les tests d'accessibilité.

Ce guide ne fait pas l'inventaire de tous les constructeurs du marché. Il se concentre sur les six outils qui reviennent le plus souvent dans les projets d'e-mails : MJML, React Email et Maizzle pour les équipes qui codent, Stripo, BEE et Unlayer pour l'édition visuelle, et Email on Acid pour le contrôle avant envoi. Un constructeur ne rend pas un e-mail accessible à lui seul. Il peut produire des tables propres et des styles en ligne, mais le texte alternatif, l'ordre de lecture, la formulation des liens et le contraste dépendent toujours de la personne qui rédige et de celle qui relit.

Pourquoi l'accessibilité se joue dans le balisage

Un e-mail est un document HTML rendu par des clients très différents : webmails dans le navigateur, applications mobiles, clients de bureau. Outlook pour Windows, par exemple, rend le HTML avec un moteur issu de Word, ce qui ignore une bonne partie des règles CSS modernes. Les lecteurs d'écran ne lisent pas ce que vous avez prévu, mais ce que le client expose à l'utilisateur. Trois éléments déterminent donc le résultat : la structure (tables, titres, listes), les alternatives textuelles des images et les couleurs.

Un bon outil rend ces trois éléments corrects par défaut, ou au moins faciles à corriger avant l'envoi. Un mauvais outil les cache dans un code généré que personne ne relit. La question à poser à chaque candidat est donc simple : après une modification, le fichier exporté reste-t-il assez lisible pour qu'un humain puisse vérifier la structure en deux minutes ?

Tableau comparatif des outils

Le tableau suivant résume la situation de chaque outil pour un projet où l'accessibilité compte. Les prix sont ceux indiqués sur les pages officielles au 7 octobre 2026. Lorsque la page tarifaire ne publie pas de montant, la mention « tarif sur demande » est utilisée à la place d'une estimation.

Les outils, un par un

MJML : le choix le plus lisible pour le code

MJML fournit des composants comme mj-section, mj-column, mj-text et mj-image, puis compile le tout en tables HTML compatibles avec les clients e-mail. Pour l'accessibilité, son avantage principal est la lisibilité : le fichier source est court, chaque image apparaît avec son attribut alt, et une revue de code montre immédiatement un lien sans texte explicite ou une image décorative mal marquée. Vous gardez la main sur le balisage final.

Ses limites sont claires. MJML ne rédige pas les textes alternatifs à votre place et ne sait pas si un titre est pertinent dans le contexte de l'e-mail. Le modèle est auto-hébergé : il faut une chaîne de compilation, un dépôt et quelqu'un qui maintient les gabarits. Sur le plan tarifaire, la fiche ne publie aucun palier payant ; le modèle est indiqué comme auto-hébergé, et les frais d'hébergement restent à votre charge. Le détail est disponible sur mjml.io/pricing.

React Email : pour les applications qui envoient leurs propres messages

React Email permet d'écrire les e-mails sous forme de composants React, puis de les rendre en HTML. C'est le bon choix lorsque l'application possède déjà la logique d'envoi : les données du compte, les variables et les états sont dans le même code, et une même équipe maintient le composant et l'envoi. Les textes alternatifs et les titres se contrôlent comme n'importe quel composant, avec des tests unitaires si votre équipe en écrit déjà pour le reste de l'application.

Le point faible est la compétence requise. Si votre équipe marketing doit modifier seule les modèles, React Email exige un développeur. Le tarif n'est pas repris ici : consultez la page officielle de l'éditeur, car aucun montant n'est publié dans les sources retenues pour ce guide.

Maizzle : un framework avec des gabarits versionnés

Maizzle compile des gabarits écrits en HTML avec des utilitaires de style, puis produit des styles en ligne compatibles avec les clients e-mail. Il convient aux équipes qui veulent des gabarits réutilisables, versionnés dans Git et relus comme du code. Pour l'accessibilité, la force de Maizzle est de rendre la structure des gabarits prévisible : vous décidez une fois de la forme des tables de mise en page, puis chaque nouvel e-mail hérite de la même base.

La contrepartie est une chaîne de compilation à maintenir. Un changement de version du framework peut modifier la sortie, et il faut prévoir un test de rendu après chaque mise à jour. Le tarif est indiqué sur demande.

Stripo : l'éditeur visuel pour les équipes marketing

Stripo permet de construire des e-mails visuellement à partir de modèles. C'est l'outil qui donne le plus d'autonomie aux rédacteurs : ils ajustent les textes, les blocs et les images sans ouvrir le code. Cette autonomie a un coût pour l'accessibilité. Le champ alt de chaque image doit être rempli manuellement, et il est facile d'oublier qu'un bloc de texte stylisé en gras n'est pas un titre.

Avant chaque lancement, exportez le HTML et relisez-le : la structure des titres, les liens et les images doivent être cohérents. Si le rédacteur ne peut pas modifier les attributs alt, la responsabilité revient à la personne qui valide le gabarit. Tarif sur demande.

BEE (Beefree) : le glisser-déposer pour les rédacteurs

BEE repose sur un éditeur en glisser-déposer qui fonctionne sur des modèles existants. Il réduit le risque de casser la mise en page, ce qui est appréciable pour les rédacteurs qui n'écrivent pas de code. En revanche, l'éditeur ne garantit pas que chaque titre est un vrai titre ni que chaque lien a un texte explicite. Ces points se vérifient dans le modèle, une fois, puis se reconduisent lors des envois.

Un bon usage consiste à verrouiller les blocs critiques du gabarit : en-tête, titres, pied de page et bouton d'action. Les rédacteurs changent le texte, mais pas la structure. Tarif sur demande.

Unlayer : un éditeur intégré à votre application

Unlayer est conçu pour être intégré dans un produit : vos utilisateurs construisent leurs propres e-mails à l'intérieur de votre application. C'est un choix pertinent si votre produit doit offrir un éditeur à ses clients. L'accessibilité dépend alors à la fois de l'éditeur et de votre application hôte, qui gère les variables, la personnalisation et l'envoi. Un e-mail parfaitement structuré peut être cassé par une variable qui insère un texte sans alt ou un lien sans libellé.

Prévoyez donc un contrôle côté application : vérifiez que les modèles par défaut respectent les règles de ce guide et que les champs laissés aux clients rappellent ces exigences. Tarif sur demande.

Email on Acid : le contrôle avant envoi

Email on Acid n'est pas un constructeur, mais un outil de contrôle : il affiche le rendu de vos e-mails dans de nombreux clients et analyse le HTML. Le plan Basic, à 99 $ par mois, inclut 1 000 aperçus par mois, plus de 100 clients et appareils et l'accès à l'API. Le plan Premium, à 199 $ par mois, inclut 2 000 aperçus par mois et ajoute les tests d'accessibilité et l'analyse HTML.

Pour un projet où l'accessibilité est un engagement, le plan Premium est donc le seul de la liste publiée qui couvre les tests d'accessibilité. Un aperçu visuel ne remplace pas une écoute avec un lecteur d'écran : utilisez l'outil pour repérer les défauts évidents, puis testez le reste vous-même.

Combien coûte un contrôle régulier

Le coût d'un outil dépend surtout du volume de contrôles, pas seulement de l'abonnement. Le tableau suivant applique les tarifs publiés à quelques volumes réalistes d'aperçus mensuels. Lorsqu'une limite est dépassée sans tarif publié pour le dépassement, le montant est indiqué sur demande.

Pour une équipe qui code avec MJML et contrôle ses envois avec Email on Acid, le budget récurrent se limite donc à l'abonnement de contrôle et à l'hébergement de la chaîne de compilation. Pour une équipe qui dépend d'un éditeur visuel, le coût réel doit être demandé à l'éditeur avant tout engagement, en précisant le nombre de rédacteurs, le volume d'envois et les besoins d'accessibilité.

Comment choisir

Le choix dépend moins de la liste des fonctions que de la façon dont votre équipe travaille. Un outil très bien conçu peut produire un e-mail peu accessible si personne ne le relit, et un outil modeste peut donner de très bons résultats si le gabarit est verrouillé et contrôlé. Les questions ci-dessous aident à trancher.

Une règle simple : choisissez l'outil qui laisse la structure du gabarit entre les mains d'une personne compétente, puis ajoutez un contrôle régulier. Le meilleur constructeur ne compense pas l'absence de relecture, et une relecture ne compense pas un gabarit mal construit.

Mise en place et migration

Si vous migrez des e-mails existants vers un nouveau constructeur, ne convertissez pas tout d'un coup. Commencez par les gabarits les plus utilisés, puis étendez la migration. La table suivante sert de feuille de route pour une équipe de taille moyenne.

Gardez l'ancien gabarit actif pendant une période de transition, en le marquant comme obsolète dans votre outil. Si le nouveau constructeur produit une régression, vous pouvez revenir à l'ancien sans interrompre les envois planifiés.

Les règles techniques, quel que soit l'outil

Les règles suivantes s'appliquent à tous les constructeurs de cette liste. Elles ne dépendent pas du produit choisi, et elles doivent être vérifiées dans le HTML exporté.

Marquer les tables de mise en page

Les tables servent encore à la mise en page dans la plupart des clients e-mail. Il faut indiquer aux lecteurs d'écran qu'il ne s'agit pas de tableaux de données, sans quoi ils annoncent la navigation dans le tableau (« ligne 1, colonne 1 »), ce qui désoriente l'utilisateur :

<table role="presentation" width="100%">
  <tr>
    <td>
      Contenu de la mise en page
    </td>
  </tr>
</table>

Hiérarchie des titres

Les utilisateurs de lecteurs d'écran naviguent souvent par titres. Un e-mail doit donc avoir un titre principal, puis des sous-titres qui découpent le contenu dans l'ordre. Les styles en ligne permettent de contrôler l'apparence sans changer le niveau sémantique :

<h1 style="font-size: 24px; margin: 0;">Bienvenue chez nous</h1>
<p>Texte d'introduction...</p>

<h2 style="font-size: 20px; margin: 20px 0 10px 0;">Nouveautés</h2>
<p>Description de la fonctionnalité...</p>

<h2 style="font-size: 20px; margin: 20px 0 10px 0;">Premiers pas</h2>
<p>Instructions...</p>

Évitez de sauter de h1 à h3 pour obtenir une taille de texte donnée. Si le résultat visuel vous gêne, réglez la taille avec le style, pas avec le niveau de titre.

Éléments sémantiques

Lorsque le client le permet, utilisez les éléments qui décrivent le contenu : un paragraphe pour un paragraphe, une liste pour une énumération, strong pour une information importante et em pour une emphase réelle. Ces éléments sont annoncés différemment par les lecteurs d'écran, ce qui n'est pas le cas d'un simple texte mis en gras par un style.

Textes alternatifs

Chaque image doit être traitée selon son rôle. Une image informative doit être décrite pour ce qu'elle montre. Une image décorative doit avoir un attribut alt vide, et non pas être omise. Une image qui contient du texte doit reprendre ce texte.

<!-- Image informative : décrire le contenu -->
<img src="produit.jpg" alt="Chaussures de running bleues à semelles blanches" />

<!-- Image décorative : alt vide -->
<img src="separateur.png" alt="" />

<!-- Image qui contient du texte : reprendre le texte -->
<img src="bandeau-soldes.jpg" alt="50 % de réduction sur tous les articles ce week-end" />

Quelques repères couramment utilisés par les équipes d'accessibilité :

• Décrivez ce que montre l'image, pas le fait qu'il s'agit d'une image.
• Restez concis : une phrase suffit dans la plupart des cas, et un alt de moins de 125 caractères reste une bonne cible.
• Ne mettez pas de texte alternatif identique à celui d'un lien voisin sans le justifier.

Les informations importantes ne doivent pas reposer uniquement sur une image. Certains utilisateurs ont les images désactivées par défaut, et de nombreux clients ne les chargent qu'après validation. Si un bouton est une image, ajoutez un lien texte à côté ou un libellé qui reprend la même action.

Contraste

Les critères WCAG 2.1 de niveau AA fixent des seuils minimaux : 4,5:1 pour le texte normal et 3:1 pour le texte large, c'est-à-dire 18 pt (24 px) ou 14 pt en gras (environ 18,7 px). Mesurez chaque combinaison de couleurs du gabarit avec un vérificateur de contraste, y compris les textes de pied de page souvent choisis en gris clair.

<!-- Contraste suffisant -->
<p style="color: #333333; background-color: #ffffff;">
  Texte à fort contraste
</p>

<!-- Contraste insuffisant, à éviter -->
<p style="color: #999999; background-color: #ffffff;">
  Texte à faible contraste
</p>

Ne pas transmettre une information par la couleur seule

Un message d'erreur en rouge ne suffit pas pour un utilisateur daltonien. Ajoutez un libellé ou une icône qui porte le même sens :

<!-- À éviter : couleur seule -->
<span style="color: red;">Erreur</span>

<!-- Préférable : couleur, icône et texte -->
<span style="color: red;">⚠ Erreur : adresse e-mail invalide</span>

Liens descriptifs

Les lecteurs d'écran permettent de lister tous les liens d'une page. Un libellé comme « cliquez ici » répété cinq fois devient inutilisable dans cette liste. Le libellé doit décrire la destination :

<!-- À éviter -->
<a href="...">Cliquez ici</a>

<!-- Correct -->
<a href="...">Voir le détail de votre commande</a>

<!-- Correct -->
<a href="...">Télécharger le rapport 2026 (PDF, 2 Mo)</a>

Pour les e-mails transactionnels, un libellé comme « Voir ma facture » vaut mieux que « Cliquer » ou « En savoir plus », car il indique à l'utilisateur ce qu'il trouvera après le clic.

Langue et taille du texte

Déclarez la langue du document, ce qui permet aux lecteurs d'écran de choisir la bonne prononciation. Pour un passage dans une autre langue, utilisez l'attribut lang sur l'élément concerné :

<html lang="fr">

<p>Le mot anglais <span lang="en">shipping</span> signifie expédition.</p>

Pour la taille, une règle courante est de ne pas descendre sous 14 px pour le texte principal et de viser 16 px. Un interligne d'environ 1,5 facilite la lecture pour de nombreux utilisateurs, y compris ceux qui ont une basse vision :

<p style="font-size: 16px; line-height: 1.5;">
  Texte courant facile à lire
</p>

Liens et focus au clavier

Dans la plupart des clients e-mail, vous ne contrôlez pas l'indicateur de focus. Il vaut tout de même la peine de rendre les boutons assez grands pour être atteints au clavier et de conserver une bordure ou une couleur de fond qui les distingue du texte. Les clients gèrent le focus de manière inégale, donc ne comptez pas sur un style précis pour l'annonce.

Tester avant chaque envoi

Un contrôle automatisé détecte les oublis évidents : image sans alt, contraste trop faible, lien vide. Il ne dit pas si l'ordre de lecture est compréhensible ni si le message est clair à l'écoute. Ces deux points demandent une personne.

Testez avec au moins un lecteur d'écran. VoiceOver est intégré à macOS et iOS, et NVDA est gratuit sous Windows. Écoutez le message de la première ligne à la dernière : la structure est-elle annoncée clairement ? Les images sont-elles décrites utilement ? Les liens ont-ils un sens hors de leur contexte ?

Enfin, envoyez un test à un compte avec les images désactivées. Si l'information essentielle disparaît, le message doit être corrigé. Gardez une trace écrite de chaque contrôle : nom du gabarit, date, outil utilisé, défauts relevés et corrections apportées. Cette trace sert autant à la personne qui relit qu'à celle qui reprendra le gabarit six mois plus tard.

En résumé

Un e-mail accessible repose sur trois choses : une structure sémantique, des textes alternatifs rédigés par une personne, et un contraste suffisant. Le constructeur compte, mais surtout la manière dont votre équipe contrôle ce qu'elle envoie. MJML donne le plus de visibilité sur le code, Stripo, BEE et Unlayer donnent le plus d'autonomie aux rédacteurs, React Email s'intègre aux applications qui envoient leurs propres messages, et Maizzle convient aux équipes qui versionnent leurs gabarits. Email on Acid, dans son plan Premium à 199 $ par mois, couvre le contrôle d'accessibilité qui manque aux autres étapes.