Les emails sont-ils soumis au RGAA ?

Le RGAA ne couvre pas directement les emails, mais les bonnes pratiques WCAG s'appliquent. Pour les administrations soumises au RGAA, les emails transactionnels et newsletters font partie de la communication publique en ligne et devraient être accessibles. L'EAA renforce cette obligation pour les entreprises.

Comment tester l'accessibilité d'un email ?

Testez avec un lecteur d'écran (NVDA sur Windows, VoiceOver sur Mac) dans votre client email. Vérifiez que l'email est compréhensible sans images (elles sont souvent bloquées). Utilisez des outils comme Litmus Accessibility ou Email on Acid. Vérifiez les contrastes et la version texte brut.

Pourquoi utiliser role="presentation" sur les tableaux dans les emails ?

Les emails HTML utilisent des tableaux pour la mise en page (layout), pas pour des données. Sans role="presentation", les lecteurs d'écran annoncent « tableau avec X lignes et Y colonnes » pour chaque tableau de layout, rendant l'email incompréhensible. Cette attribut indique au lecteur d'écran d'ignorer la structure de tableau.

Emails accessibles : HTML email, images, contrastes et bonnes pratiques RGAA

L'accessibilité des emails : un canal souvent oublié

Les emails représentent un canal de communication majeur : newsletters, emails transactionnels (confirmations de commande, réinitialisations de mot de passe), communications internes. Pourtant, l'accessibilité des emails est rarement prise en compte.

Si le RGAA ne couvre pas directement les emails, les bonnes pratiques WCAG s'y appliquent pleinement. Un email inaccessible exclut des utilisateurs de technologies d'assistance et dégrade l'expérience pour tous.

Structure HTML d'un email accessible

Les contraintes de l'email HTML

L'email HTML est un environnement contraint : pas de JavaScript, support CSS limité, rendu variable selon les clients (Gmail, Outlook, Apple Mail, Thunderbird). Malgré ces contraintes, l'accessibilité est possible :

Attribut lang : ajoutez lang="fr" sur la balise <html> de l'email
role="presentation" : les tableaux utilisés pour la mise en page (layout tables) doivent avoir role="presentation" pour que les lecteurs d'écran ne les interprètent pas comme des données
Titres : utilisez des <h1>, <h2> pour structurer le contenu
Sémantique : <p> pour les paragraphes, <ul>/<ol> pour les listes

Structure recommandée

<table role="presentation"> <tr><td> <h1>Titre de la newsletter</h1> <p>Introduction...</p> <h2>Section 1</h2> <p>Contenu...</p> </td></tr> </table>

Images dans les emails

Texte alternatif : toutes les images informatives doivent avoir un alt descriptif
Images bloquées : de nombreux clients email bloquent les images par défaut. L'email doit être compréhensible sans images — l'alt text est alors affiché à la place
Images de décoration : utilisez alt="" et role="presentation"
Texte dans les images : évitez le texte en image. Si nécessaire, le texte alt doit reprendre le contenu
Boutons CTA : les boutons d'appel à l'action en image doivent avoir un alt descriptif (« Découvrir nos offres »). Préférez les boutons en HTML/CSS (bulletproof buttons)

Contrastes et couleurs

Ratio minimum : 4.5:1 pour le texte normal, 3:1 pour le grand texte (18px+ ou 14px+ gras)
Ne pas utiliser la couleur seule : les liens doivent être soulignés en plus d'être colorés
Dark mode : testez vos emails en mode sombre. Utilisez des meta tags pour contrôler le rendu : <meta name="color-scheme" content="light dark">
Fond et texte : définissez toujours une couleur de fond ET une couleur de texte (ne vous reposez pas sur les valeurs par défaut du client email)

Liens et boutons

Textes de liens descriptifs : « Lire l'article sur l'accessibilité » plutôt que « Cliquez ici » ou « En savoir plus »
Taille des zones cliquables : au moins 44x44px pour faciliter le clic sur mobile
Boutons bulletproof : créez les boutons CTA en HTML/CSS plutôt qu'en image pour qu'ils soient accessibles même avec les images bloquées
Lien de désinscription : visible, accessible et facile à trouver (en haut ET en bas de l'email)

Version texte brut

Proposez toujours une version texte brut (multipart MIME) en alternative à la version HTML :

Certains utilisateurs préfèrent le texte brut
Certains lecteurs d'écran fonctionnent mieux avec le texte brut
C'est une bonne pratique anti-spam
Le contenu essentiel doit être présent dans les deux versions

Emails transactionnels

Les emails transactionnels (confirmation de commande, réinitialisation de mot de passe, factures) sont particulièrement critiques :

Objet clair : « Confirmation de votre commande n°12345 » plutôt que « Votre commande »
Informations structurées : utiliser des tableaux de données balisés pour le récapitulatif de commande
Code OTP : si l'email contient un code de vérification, le placer dans un format facilement copiable et identifiable
Liens d'action : les liens de confirmation, d'annulation ou de réinitialisation doivent être clairement identifiables

Outils de test

Outil	Usage
Litmus Accessibility	Vérification d'accessibilité dans les emails
Email on Acid	Test de rendu multi-clients avec vérifications a11y
NVDA / VoiceOver	Test avec lecteur d'écran dans le client email
Colour Contrast Analyser	Vérification des contrastes

Un email accessible atteint une audience plus large et performe mieux. Les bonnes pratiques d'accessibilité email améliorent aussi la délivrabilité et le rendu dans tous les clients.