« Lien non conforme : intitulé identique sur vingt-quatre occurrences, aucune ne permet d’identifier sa destination hors contexte visuel. » C’est ainsi qu’un rapport d’audit formule le constat sur la page d’accueil d’un site de recettes de cuisine, organisée en grille de cartes, chacune terminée par un bouton « En savoir plus » menant à une recette différente.
Visuellement, rien ne choque : chaque carte affiche une photo, un titre de recette, un temps de préparation, puis le bouton. Le problème n’apparaît que lorsqu’on retire ce contexte visuel, exactement ce que fait un utilisateur de lecteur d’écran naviguant par la liste des liens de la page plutôt que par la lecture linéaire du contenu.
Le critère RGAA en cause
Le référentiel général d’amélioration de l’accessibilité, dans sa version 4.0 alors en vigueur, consacre sa thématique 6 aux liens, avec un premier critère qui demande que chaque lien, hors cas particuliers prévus par la méthodologie, soit explicite : sa destination ou sa fonction doit pouvoir être comprise à partir du seul intitulé du lien, éventuellement combiné à son contexte immédiat dans la même phrase ou le même item de liste, mais pas à un élément visuel séparé comme une image de carte.
Le test de vérification, décrit dans la méthodologie technique associée au référentiel, consiste précisément à afficher la liste de tous les liens d’une page, sans autre contexte, un mode de restitution que proposent la plupart des lecteurs d’écran sous forme de raccourci clavier dédié. Vingt-quatre occurrences identiques de « En savoir plus » dans cette liste ne permettent strictement aucune distinction.
Pourquoi ce piège est si fréquent
Le bouton « En savoir plus » est un choix de rédaction courant parce qu’il fonctionne visuellement : la carte fournit déjà le titre de la recette juste au-dessus, l’œil relie naturellement les deux éléments. Cette lecture contextuelle, évidente pour un visiteur voyant qui balaie la grille du regard, disparaît totalement pour quiconque navigue par la structure du document plutôt que par sa mise en page.
Le composant en cause avait été construit comme un bloc réutilisable dans l’éditeur, avec l’intitulé du bouton figé en dur dans le gabarit, sans variable dynamique reprenant le titre de la recette associée. Ce choix technique, anodin en apparence, est la cause directe du manquement : le gabarit ne disposait tout simplement pas de la donnée nécessaire à la correction, au moment où le bouton était rendu.
La correction appliquée
Deux approches ont été envisagées, avec un arbitrage assez net en faveur de la seconde :
- Modifier chaque intitulé visible pour y intégrer le titre de la recette, au risque de casser la cohérence visuelle de la grille de cartes si les titres sont longs.
- Conserver l’intitulé visible « En savoir plus », identique pour toutes les cartes, mais lui adjoindre un texte additionnel réservé aux technologies d’assistance, reprenant le titre de la recette.
<a href="/recettes/tarte-aux-pommes-normande/">
En savoir plus
<span class="lecture-ecran-seule">sur la recette Tarte aux pommes normande</span>
</a>
.lecture-ecran-seule {
position: absolute;
width: 1px;
height: 1px;
overflow: hidden;
clip: rect(0 0 0 0);
white-space: nowrap;
}
Cette classe, souvent appelée screen-reader-only dans la documentation anglophone, masque visuellement le texte tout en le laissant accessible à l’arbre d’accessibilité du navigateur, donc restitué par un lecteur d’écran. Le rendu visuel de la grille de cartes n’a strictement pas changé ; seule la restitution non visuelle a été enrichie.
Le résultat au nouveau passage d’audit
Le contrôle du critère du lien explicite est repassé de non conforme à conforme, sans qu’aucune ligne de mise en page n’ait été touchée. Le gabarit de bloc a été modifié une seule fois, à la source, ce qui a corrigé automatiquement les vingt-quatre occurrences de la page d’accueil ainsi que toutes les occurrences similaires ailleurs sur le site, sans reprise manuelle carte par carte.
Un réflexe de conception à intégrer dès la maquette : tout bouton dont l’intitulé est générique par choix graphique doit prévoir, dès la construction du composant, un emplacement pour un complément contextuel réservé aux technologies d’assistance. Ajouter ce complément après coup coûte toujours plus cher que de le prévoir à la conception.
Notre verdict
Ce cas illustre un manquement qui ne se voit jamais à l’œil nu et qui pourtant concerne une part significative des sites construits autour de grilles de cartes, un motif de mise en page extrêmement répandu. La correction ne demande ni script complexe ni refonte graphique : elle demande seulement que le composant dispose, dès sa construction, de la donnée nécessaire pour distinguer chaque lien de ses voisins visuellement identiques.
