Dans chaque page web, chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) a-t-il une alternative ?
Un lecteur d’écran lit « :-) » comme « deux-points tiret parenthèse droite ». Pour quelqu’un qui dépend d’un lecteur d’écran, cette suite de signes de ponctuation ne communique rien. C’est le problème que cible le critère 13.5 : certains caractères sont utilisés non pour leur valeur littérale, mais pour représenter un dessin, une émotion ou un mot codé.
Trois catégories sont visées : l’art ASCII (dessins réalisés avec des caractères, comme ¯\_(ツ)_/¯), les émoticônes textuelles (:-), :D, <3, ^_^) et la syntaxe cryptique comme le leet speak (h4ck3r, l33t). Si l’un de ces contenus apparaît dans votre page et qu’il porte une information, il doit avoir une alternative compréhensible.
Deux solutions sont acceptées par le RGAA : un attribut title sur un élément englobant (<abbr>, lien, contrôle de formulaire), ou une définition textuelle placée immédiatement avant ou après le contenu cryptique dans le flux de la page. Pas d’alternative, pas de conformité.
Un test pour évaluer la compréhensibilité des contenus cryptiques
Alternative textuelle pour chaque contenu cryptique
- Parcourez la page et identifiez tous les contenus cryptiques : art ASCII, émoticônes textuelles (
:-),:D,<3…) et syntaxe cryptique (leet speak, etc.). - Pour chaque contenu trouvé, vérifiez l’une des deux conditions suivantes :
- Un attribut
titleest présent sur un élément englobant (<abbr>, lien, contrôle de formulaire) et fournit la définition en clair. - Un texte explicatif est placé immédiatement avant ou après le contenu cryptique dans le flux de la page.
- Un attribut
- Si au moins un contenu cryptique ne satisfait aucune de ces deux conditions, le test échoue.
Exemples
❌ Non conforme : Émoticône sans alternative
<p>Merci pour votre message :-)</p>Le lecteur d’écran vocalise « deux-points tiret parenthèse droite ». L’utilisateur doit seul décoder qu’il s’agit d’un sourire — ce décodage est impossible pour qui ne connaît pas les conventions des émoticônes textuelles.
✅ Conforme : Émoticône avec abbr et title
<p>Merci pour votre message <abbr title="sourire">:-)</abbr></p>Le lecteur d’écran expose le title et lit « sourire » à la place de la séquence de ponctuation. L’intention émotionnelle du message est transmise sans que l’utilisateur ait à décoder les symboles.
✅ Conforme : Art ASCII masqué avec définition visible adjacente
<p>Niveau de certitude : <span aria-hidden="true">¯\_(ツ)_/¯</span> (je ne sais pas)</p>L’art ASCII est masqué aux technologies d’assistance via aria-hidden="true", et une définition textuelle suit immédiatement entre parenthèses. Les visiteurs voyants lisent le symbole ; les utilisateurs de lecteurs d’écran entendent la signification. Double bénéfice.
❌ Non conforme : Leet speak sans alternative
<p>Bienvenue sur le site des <span class="highlight">h4ck3rz</span> !</p>Le lecteur d’écran épelle les caractères un à un : « h, 4, c, k, 3, r, z ». Sans title ni texte adjacent, l’utilisateur ne comprend pas qu’il s’agit du mot « hackers », et le sens de la phrase disparaît.
Astuces et pièges
⚠️ Confondre emojis Unicode et émoticônes textuelles
Les emojis Unicode (😊, 👍) ne sont pas des contenus cryptiques au sens du critère 13.5. Chaque emoji dispose d’une description officielle dans la norme Unicode que les lecteurs d’écran vocalisent. Les émoticônes textuelles (:-), :D) sont une autre catégorie : ce sont des séquences de signes de ponctuation sans sémantique Unicode, et c’est bien elles que cible ce critère.
⚠️ Négliger les contenus générés par les utilisateurs
Les zones de commentaires, forums et champs de chat sont dans le périmètre d’audit. Si votre plateforme affiche de l’art ASCII soumis par des utilisateurs sans le baliser, c’est une non-conformité. Deux options : filtrer les séquences cryptiques à la saisie, ou transformer automatiquement les émoticônes connues en <abbr title="..."> à l’affichage.
⚠️ Les caractères Unicode Private Use Areas ne relèvent pas de ce critère
Les plages Unicode U+E000–U+F8FF et U+F0000–U+FFFFF (PUA) sont utilisées par certaines polices d’icônes et des plateformes comme Moodle. Ces caractères ne sont pas des contenus cryptiques au sens du critère 13.5. S’ils portent une information, c’est le critère 1.1 qui s’applique : un aria-label sur l’élément suffit à rendre le contenu conforme.
💡 Combiner aria-hidden et définition adjacente : la technique la plus robuste
Plutôt que de laisser le lecteur d’écran vocaliser une séquence chaotique avant d’atteindre le title, masquez le contenu cryptique avec aria-hidden="true" et placez la définition en texte visible immédiatement après. Vous satisfaisez le critère 13.5 et offrez une expérience cohérente, que l’utilisateur emploie ou non une technologie d’assistance.
⚠️ Le title sur un span générique : risqué en pratique
La méthodologie RGAA mentionne les liens, contrôles de formulaire et <abbr> comme porteurs valides du title. Un <span title="..."> ordinaire est techniquement recevable, mais plusieurs lecteurs d’écran n’exposent pas le title des éléments non interactifs sans configuration spécifique. Préférez <abbr> pour les termes non standards : c’est l’élément sémantiquement approprié et son title est exposé de façon cohérente.
Questions fréquentes
Comment le critère RGAA 13.5 s'applique-t-il aux emojis (😊, 🎉) ?
Non. Les emojis Unicode ont une description officielle que les lecteurs d’écran vocalisent automatiquement. Ils relèvent du critère 1.1 si porteurs d’information : vérifiez alors que la description Unicode est suffisamment explicite dans le contexte, ou complétez-la avec un aria-label. Le critère 13.5 ne concerne que les séquences de caractères ASCII utilisées comme codes visuels (émoticônes textuelles, art ASCII, leet speak).
Comment rendre conformes les émoticônes textuelles selon le critère RGAA 13.5 ?
Une alternative suffit. Le RGAA n’interdit pas les émoticônes ; il exige qu’elles soient compréhensibles par tous. Un <abbr title="sourire">:-)</abbr> ou un texte adjacent « :-) (sourire) » rend le contenu conforme sans supprimer le caractère expressif du symbole.
Comment détecter efficacement les contenus cryptiques lors d'un audit RGAA ?
Cherchez dans le code source les séquences typiques : :-, :D, <3, ^_^, ainsi que les motifs chiffres-lettres alternés caractéristiques du leet speak. Inspectez aussi visuellement les zones éditoriales et les commentaires utilisateurs. Pour chaque occurrence, vérifiez la présence d’un title sur un élément englobant ou d’un texte adjacent explicatif.
Dans quels cas le RGAA 13.5 s'applique-t-il aux contenus masqués ou hors écran ?
Non. Le critère porte sur les contenus présentés à l’utilisateur. Un contenu masqué avec display: none ou visibility: hidden n’est pas rendu par les technologies d’assistance et sort du périmètre. En revanche, un contenu positionné hors écran via CSS mais toujours dans l’arbre d’accessibilité (technique sr-only) reste dans le périmètre.
Comment le RGAA 13.5 traite-t-il les mots de passe masqués par des * ?
C’est une zone frontière. Les caractères de masquage (•, *) sont des représentations fonctionnelles standard des champs de mot de passe : les lecteurs d’écran vocalisent « caractère protégé » ou équivalent selon l’implémentation. La base de connaissance RGAA indique que le critère 13.5 peut s’appliquer en l’absence d’un test plus spécifique, mais ce cas d’usage est généralement couvert par les critères de formulaire (11.x).