L'email HTML reste du HTML, rendu par un agent utilisateur — un client webmail est un navigateur, et le moteur de rendu d'une application de messagerie native n'est pas fondamentalement différent. Les critères de succès de WCAG ne prévoient pas d'exception spécifique à l'email, et ils s'appliquent tout aussi directement à un sondage, un quiz ou un accordéon tout-CSS qu'au composant web équivalent. Voici une checklist pratique pour les quatre critères les plus importants pour l'email interactif piloté par le « checkbox hack ».
Pourquoi WCAG s'applique ici
WCAG 2.2 est rédigé en termes de « contenu » rendu par un « agent utilisateur », et non spécifiquement de « pages web » — ce n'est pas une norme formelle spécifique à l'email, puisque l'email en tant que médium n'est nommé nulle part dans la spécification, mais le contenu sous-jacent reste du HTML dans les deux cas. C'est pourquoi la communauté de l'accessibilité traite les critères de succès de WCAG comme la barre pratique pour le contenu email, exactement comme le fait cette checklist, plutôt que de traiter l'email comme une catégorie séparée que les directives n'atteindraient pas.
1.1.1 Contenu non textuel — chaque image a besoin d'un vrai alt
Les photos de produit, les images d'en-tête, les séparateurs décoratifs et les boutons à icône seule ont tous besoin d'un attribut alt qu'un lecteur d'écran peut annoncer — ou, pour des images véritablement décoratives ne portant aucune information, d'un alt="" explicitement vide, afin que le lecteur d'écran les ignore plutôt que de lire un nom de fichier dénué de sens. Cela compte davantage dans les blocs interactifs que dans les blocs statiques : une roue de la fortune ou une carte à gratter entièrement pilotée par l'image, sans alternative textuelle décrivant le résultat, ne laisse à un utilisateur de lecteur d'écran aucun moyen de savoir ce qu'il a gagné.
1.4.3 / 1.4.11 — Contraste pour le texte et les contrôles interactifs
WCAG fixe un ratio de contraste minimum de 4.5:1 pour le texte de corps normal (3:1 pour le texte large, selon 1.4.3), et un minimum de 3:1 pour les limites visuelles des composants d'interface et des graphiques (1.4.11). Les deux s'appliquent directement aux éléments interactifs, pas seulement au texte des paragraphes — la bordure d'une option de sondage, le fond d'un bouton de réponse de quiz contre son conteneur, les chiffres d'un compte à rebours contre leur arrière-plan. Un contrôle interactif à faible contraste n'est pas qu'un raté esthétique ; il peut rendre le contrôle totalement invisible pour un destinataire malvoyant.
2.1.1 Clavier — l'avantage réel de la technique du checkbox hack
Un vrai <input type="radio">/<input type="checkbox"> associé à un <label for="..."> est nativement focalisable et actionnable avec Tab plus Espace ou Entrée, dans tout client qui rend ne serait-ce que les contrôles de formulaire — aucun balisage supplémentaire, aucun travail supplémentaire, car c'est ainsi que les navigateurs ont toujours traité les vrais contrôles de formulaire. Voir Machines à états CSS :checked pour le fonctionnement de la technique elle-même. C'est un avantage réel par rapport à ce que fait généralement un carrousel web piloté par JavaScript — un <div onclick> sans gestionnaire clavier — et c'est un avantage que l'email interactif obtient par construction, sans effort supplémentaire, tant que de vraies paires <label>/<input> sont utilisées plutôt que de simples <div> cliquables.
2.5.8 Taille de la cible (minimum) — nouveau dans WCAG 2.2
Le critère de succès 2.5.8, introduit dans WCAG 2.2, fixe un plancher de 24×24 pixels CSS pour les cibles interactives, avec des exceptions pour le texte en ligne, les contraintes de mise en page essentielles, ou un contrôle équivalent plus grand disponible ailleurs. C'est particulièrement pertinent sur mobile — où se produit la majorité des ouvertures d'email — pour les plus petits éléments interactifs qu'un studio rend faciles à trop réduire : points de carrousel, icônes de notation par étoiles, puces de réponse de quiz serrées les unes contre les autres.
4.1.2 Nom, rôle, valeur — étiqueter correctement les contrôles :checked
Un lecteur d'écran annonce le nom, le rôle et l'état actuel d'un contrôle à partir d'un balisage sémantique réel — ce qu'un <label> enveloppant un vrai <input> fournit gratuitement, et exactement ce qui manque à un simple <div> stylisé faisant office de bouton. En pratique, cela signifie que chaque option de sondage, réponse de quiz et en-tête d'accordéon a besoin d'un vrai texte de label qu'un lecteur d'écran peut lire à voix haute, pas seulement d'une image de fond ou d'une icône sans texte d'accompagnement.
Checklist pratique
- Chaque image porte un vrai
alt, ou unalt=""explicitement vide si elle est décorative. - Le texte et les bordures des contrôles interactifs respectent un contraste de 4.5:1 (texte) / 3:1 (composant d'interface).
- Chaque interaction
:checkedutilise une vraie paire<input>+<label for="...">— jamais un simple<div>cliquable. - Les cibles interactives font au moins 24×24 pixels CSS, en particulier sur les blocs orientés mobile.
- Les labels de sondage/quiz/accordéon portent un vrai texte lisible — pas seulement une image ou une icône.