Dans chaque page web, pour chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) ayant une alternative, cette alternative est-elle pertinente ?
Un lecteur d’écran qui rencontre « :-) » sans alternative lit les trois caractères un par un. Si une alternative est fournie mais qu’elle indique « :-) » ou « émoticône », l’utilisateur n’est pas mieux loti. C’est exactement ce que vérifie ce critère.
Le critère 13.5 demande si le contenu cryptique a une alternative. Le critère 13.6 va plus loin : cette alternative transmet-elle vraiment le sens ? Une émoticône « ;-) » avec title=";-)" n’est pas pertinente. Une alternative qui dit « clin d’œil complice » l’est.
Trois types de contenus sont concernés : l’art ASCII (représentations visuelles faites de caractères), les émoticônes (séquences de ponctuation comme :-) ou :-D), et la syntaxe cryptique comme le leetspeak. Pour chacun, l’alternative doit transmettre le sens réel — pas décrire la forme, pas copier les caractères.
Un test pour vérifier la pertinence de l'alternative aux contenus cryptiques
Pertinence de l'alternative du contenu cryptique
- Repérez tous les contenus cryptiques dans la page : art ASCII, émoticônes (:-), :-D, ;-), etc.), leetspeak et autres syntaxes non standard.
- Pour chaque contenu cryptique, identifiez l’alternative fournie : attribut
title,aria-label,altsi encodé en image, ou texte adjacent immédiat. - Vérifiez que cette alternative exprime le sens du contenu — pas ses caractères bruts, pas son format, mais ce qu’il signifie. Une émoticône souriante doit avoir une alternative signifiant « sourire » ou équivalent.
- Si toutes les alternatives sont pertinentes, le test est validé. Un seul contenu avec une alternative non pertinente fait échouer le test.
Exemples
❌ Non conforme : Émoticône avec alternative répétant les caractères
<abbr title=":-)"> :-)</abbr>L’attribut title recopie simplement les caractères de l’émoticône. Un lecteur d’écran lira « deux points, tiret, parenthèse fermante » — aucun sens transmis. Le critère exige que l’alternative exprime ce que signifie le contenu, pas ce qu’il représente graphiquement.
✅ Conforme : Émoticône avec alternative pertinente
<abbr title="sourire">:-)</abbr>L’utilisateur de lecteur d’écran entend « sourire » à la place des trois caractères. La même logique s’applique au leetspeak : <abbr title="Austin Rocks">Au5t1N r0xx0rz</abbr> est correct car le title donne la forme lisible et compréhensible.
❌ Non conforme : Art ASCII avec alternative décrivant le format
<pre aria-label="art ASCII">
/\_/\
( o.o )
> ^ <
</pre>aria-label="art ASCII" décrit le format du contenu, pas ce qu’il représente. L’utilisateur sait que c’est de l’art ASCII, mais ignore qu’il s’agit d’un chat. C’est la même erreur que mettre alt="image" sur une photo.
✅ Conforme : Art ASCII avec alternative descriptive du sujet
<pre role="img" aria-label="Un chat assis, vu de face">
/\_/\
( o.o )
> ^ <
</pre>L’aria-label décrit ce que représente l’art ASCII. Le lecteur d’écran annonce « Un chat assis, vu de face », transmettant l’information visuelle sans que l’utilisateur ait à déchiffrer les caractères un par un.
Astuces et pièges
⚠️ Répéter les caractères dans l’alternative
C’est l’erreur la plus fréquente en audit : mettre title=":-)" ou aria-label=":-D". L’alternative doit exprimer le sens, pas copier la forme. « Sourire », « grand sourire », « clin d’œil » — voilà des alternatives pertinentes.
⚠️ Nommer le format plutôt que le sens
aria-label="émoticône" ou alt="art ASCII" informe l’utilisateur du type de contenu, pas de sa signification. C’est non pertinent au sens du critère 13.6. Une alternative pertinente répond à la question « que veut dire ce contenu ? », pas « de quel type est-il ? ».
💡 Les emojis Unicode ne sont pas des émoticônes ASCII
Les emojis Unicode (😊, 👍, 🎉) bénéficient d’une vocalisation automatique par les lecteurs d’écran via leur nom Unicode (« visage souriant »). Les émoticônes ASCII comme :-) ou :-D ne bénéficient pas de ce traitement : elles nécessitent une alternative explicite. Ne confondez pas les deux dans votre audit.
⚠️ Contenus générés par les utilisateurs
Si votre site permet de saisir du contenu contenant des émoticônes — fil de commentaires, messagerie, forum — c’est à vous d’implémenter la conversion automatique. Un système qui affiche :-) sans le transformer en <abbr title="sourire">:-)</abbr> ne satisfait pas le critère 13.6, même si vous n’avez pas saisi ce contenu vous-même.
⚠️ 13.5 et 13.6 : deux critères à auditer séparément
Le critère 13.5 vérifie l’existence d’une alternative. Le critère 13.6 vérifie sa pertinence. Un contenu cryptique sans aucune alternative échoue uniquement au 13.5. Un contenu avec une alternative non pertinente échoue aux deux. Tracez-les séparément dans votre rapport d’audit.
Questions fréquentes
Comment tester en pratique la pertinence d'une alternative textuelle selon le RGAA ?
Lisez l’alternative sans regarder le contenu cryptique. Comprenez-vous ce que l’auteur voulait exprimer ? Si oui, elle est pertinente. Si vous devez voir le contenu original pour interpréter l’alternative, elle ne l’est pas. C’est le test le plus simple du RGAA.
Dans quel cas un texte adjacent constitue-t-il une alternative valide en RGAA ?
Oui, selon la technique H86 des WCAG : un texte placé immédiatement avant ou après le contenu cryptique peut servir d’alternative, à condition qu’il soit pertinent. « Nous sommes ravis de vous accueillir :-) » n’est pas suffisant, car « ravis » contextualise sans expliciter l’émoticône. Un texte comme « :-) [sourire] » serait acceptable.
Comment auditer les émoticônes en RGAA : par occurrence individuelle ou par type ?
Chaque occurrence. Une même émoticône :-) peut avoir des nuances selon le contexte : dans un message de condoléances, son alternative devrait refléter ce décalage de ton. Le test 13.6.1 impose de vérifier chaque contenu cryptique individuellement.
Quelle différence distingue les techniques WCAG F71 et F72 pour les alternatives cryptiques ?
F71 couvre l’échec pour les émoticônes et l’art ASCII dont l’alternative répète les caractères sans en transmettre le sens. F72 couvre spécifiquement le leetspeak. En pratique, les deux décrivent la même erreur : une alternative qui ne transmet pas le sens réel du contenu cryptique, quel qu’en soit le type.
Pourquoi auditer le leetspeak en RGAA même lorsqu'il est absent des pages ?
Dès qu’un contenu cryptique est présent, il doit avoir une alternative pertinente — le RGAA ne fait pas d’exception pour la rareté. Une page de jeu vidéo, un forum communautaire ou un site de marque peut tout à fait en contenir. La technique H86 donne l’exemple de référence : <abbr title="Austin Rocks">Au5t1N r0xx0rz</abbr>.