Lien accessible : critères 6.1 et 6.2, intitulé explicite

Un lien est une référence interactive qui conduit l'utilisateur vers une ressource ou un autre endroit. L'élément natif <a href> est le seul choix correct, et le détail qui compte est dans le href : un <a> sans href n'est pas un lien (pas de focus, pas de rôle, annoncé comme du texte ordinaire).

Le motif n'a aucune difficulté technique : toute son accessibilité tient dans deux questions. Ce contrôle est-il vraiment un lien ? Et son intitulé dit-il où il mène, y compris lu seul, hors de tout contexte ? Les utilisateurs de lecteur d'écran consultent couramment la liste de tous les liens d'une page : chaque entrée doit y être compréhensible isolément. Pour le pas-à-pas de rédaction des intitulés, voir l'article Intitulé de lien accessible RGAA : le bon critère en audit.

Quand ce motif est le mauvais choix

• Le contrôle agit au lieu de naviguer (supprimer, soumettre, ouvrir une modale) : c'est un bouton <button>, pas un lien. Un <a href="#" onclick> est annoncé « lien » alors qu'il agit, Espace ne l'active pas, et « ouvrir dans un nouvel onglet » sur une action de suppression n'a aucun sens.
• Pas de destination du tout : sans href, l'élément n'est ni focusable ni annoncé comme lien. Si le contrôle n'a pas de destination, c'est un bouton.
• Carte cliquable entière enveloppée dans un seul <a> : le nom accessible du lien devient la concaténation de tout son contenu (titre, texte, date, étiquettes). Lier le titre seul et étendre la zone cliquable en CSS (technique montrée plus bas).

Critères RGAA applicables

• Critère 6.1 : lien explicite. Le critère central du motif. L'intitulé seul, ou additionné à son contexte, doit permettre de comprendre la fonction et la destination du lien. Le test 6.1.5 exige en outre que le nom accessible contienne au moins l'intitulé visible.
• Critère 6.2 : intitulé de lien. Chaque lien doit avoir un intitulé entre <a> et </a> ; un lien image ou icône sans nom est annoncé « lien » tout court, voire son URL épelée.
• Critère 3.1 : information donnée par la couleur. Un lien dans un bloc de texte ne doit pas être distinguable par la couleur seule : le souligner, ou garantir un indice non fondé sur la couleur.
• Critère 10.7 : prise de focus visible. Le lien doit afficher un indicateur de focus visible ; ne pas supprimer l'outline sans le remplacer.
• Critère 7.1 : scripts compatibles avec les technologies d'assistance. Quand les liens sont générés ou contrôlés par script (navigation d'application), leurs états doivent être restitués, par exemple aria-current="page" sur le lien de la page courante.

Interaction clavier attendue

Rôles et attributs ARIA

Sur un <a href> natif, aucun role n'est nécessaire. Le nom accessible vient du contenu ; s'il faut le compléter (« Lire la suite »), préférer du texte masqué visuellement qui étend l'intitulé plutôt qu'un aria-label qui le remplace : le nom accessible doit contenir l'intitulé visible (test 6.1.5), sans quoi la commande vocale « clique Lire la suite » ne correspond plus à rien.

<!-- Explicite hors contexte : lisible seul dans la liste des liens,
     avec la bonne pratique format / poids pour un fichier. -->
<a href="/rapports/2026.pdf">
  Télécharger le rapport annuel 2026 (PDF, 3,2 Mo)
</a>

<!-- « Lire la suite » rendu explicite : le texte masqué ÉTEND l'intitulé
     visible au lieu de le remplacer. Rien à synchroniser, la commande
     vocale continue de fonctionner. -->
<a href="/blog/rgaa-5">
  Lire la suite<span class="sr-only"> de l'annonce du RGAA 5</span>
</a>

<!-- Lien icône seule : le nom vit dans le texte masqué et décrit
     la destination. -->
<a href="https://github.com/exemple">
  <svg aria-hidden="true" focusable="false" width="24" height="24">
    <use href="#icone-github"/>
  </svg>
  <span class="sr-only">Exemple sur GitHub</span>
</a>

<!-- Nouvelle fenêtre : annoncée avant activation,
     et rel="noopener" n'est pas optionnel. -->
<a href="https://exemple.fr" target="_blank" rel="noopener">
  Site partenaire<span class="sr-only"> (nouvelle fenêtre)</span>
</a>

<!-- Page courante dans une navigation. -->
<nav aria-label="Navigation principale">
  <ul>
    <li><a href="/" aria-current="page">Accueil</a></li>
    <li><a href="/tarifs">Tarifs</a></li>
  </ul>
</nav>

Indiquer le format et le poids d'un fichier, ou signaler l'ouverture dans une nouvelle fenêtre, sont de bonnes pratiques utiles mais ne sont pas des exigences chiffrées d'un critère RGAA dédié.

/* Critère 3.1 : dans un paragraphe, le soulignement est l'indice non
   fondé sur la couleur. C'est le comportement par défaut du navigateur ;
   le retirer est une décision active, presque toujours perdante. */
p a {
  color: #0056b3;
  text-decoration: underline;
}

a:focus-visible {
  outline: 2px solid #0056b3;
  outline-offset: 2px;
}

/* Page courante : pas par la couleur seule. */
[aria-current="page"] {
  font-weight: 700;
  border-block-end: 3px solid currentColor;
}

La technique de la carte cliquable, qui évite le lien enveloppant au nom interminable :

<!-- À ne pas faire : la carte entière dans un seul lien. Le nom
     accessible devient chaque mot du contenu : titre, texte, date,
     étiquette, annoncés d'un seul bloc. -->
<a href="/projets/1" class="carte">
  <h3>Résidence des berges</h3>
  <p>Un programme de 200 logements...</p>
  <time datetime="2026-03-01">1er mars 2026</time>
</a>

<!-- À faire : lier le titre, étendre la surface cliquable en CSS. -->
<article class="carte">
  <h3><a href="/projets/1" class="carte__lien">Résidence des berges</a></h3>
  <p>Un programme de 200 logements...</p>
</article>

/* Un seul lien, petit et explicite ; toute la carte cliquable. */
.carte { position: relative; }
.carte__lien::after {
  content: "";
  position: absolute;
  inset: 0;
}

Et les contre-exemples classiques :

<!-- À ne pas faire : <a> sans href. Non focusable, sans rôle,
     annoncé comme du texte : inatteignable au clavier. -->
<a onclick="afficherPanneau()">Voir le détail</a>

<!-- À ne pas faire : href="#" en attendant le script. Remonte en haut
     de page si le JS échoue, et le contrôle agit alors qu'il est
     annoncé « lien ». -->
<a href="#" onclick="supprimer(); return false;">Supprimer</a>

<!-- À ne pas faire : un aria-label qui REMPLACE l'intitulé visible.
     « clique Lire la suite » ne correspond plus à rien (test 6.1.5). -->
<a href="/blog/rgaa-5" aria-label="Notes de version du RGAA 5">Lire la suite</a>

<!-- À ne pas faire : lien image sans alternative. Annoncé par son URL,
     caractère par caractère. L'alternative doit décrire la DESTINATION,
     pas l'image (critères 6.1 et 6.2). -->
<a href="/"><img src="logo.svg"></a>

<!-- À ne pas faire : éléments interactifs imbriqués. HTML invalide, que
     le navigateur désassemble de façon imprévisible. -->
<a href="/produit/1">
  Nom du produit
  <button type="button">Ajouter au panier</button>
</a>

Défauts fréquents et impact utilisateur

• Intitulés ambigus répétés (« Cliquez ici », « Lire la suite », « En savoir plus ») : dans la liste des liens du lecteur d'écran, dix entrées identiques sont inutilisables. C'est exactement le défaut que le critère 6.1 vise (critère 6.1).
• aria-label qui remplace l'intitulé visible : un utilisateur de commande vocale dit « clique En savoir plus » et rien ne correspond, car le nom accessible est devenu tout autre chose (test 6.1.5).
• Lien image sans alternative : annoncé par son URL, caractère par caractère ; l'alternative d'une image lien doit décrire la destination, pas l'image (critères 6.1 et 6.2).
• <a> sans href porteur d'un onclick : invisible pour la navigation clavier, l'élément est simplement inatteignable.
• Liens du corps de texte distingués par la couleur seule, sans soulignement : indétectables pour un utilisateur qui ne perçoit pas la différence de couleur (critère 3.1).
• Éléments interactifs imbriqués (<button> dans un <a>) : HTML invalide que le navigateur désassemble de façon imprévisible, inutilisable au clavier.

Ce que les outils automatiques ne détectent pas

• Le caractère explicite d'un intitulé : « Lire la suite » est un lien valide, nommé, et pourtant inutilisable hors contexte. Le critère 6.1 relève fondamentalement du jugement humain.
• La pertinence de l'alternative d'un lien image : décrire la destination et non l'image est une appréciation de sens.
• La sémantique lien / bouton : un lien qui agit ou un bouton qui navigue passent les vérifications automatiques, le balisage étant valide dans les deux cas.

Les liens sans nom accessible et les liens image sans alternative sont en revanche bien détectés par les outils automatiques, dont notre scanner : une bonne première passe, qui ne juge ni la clarté ni la pertinence des intitulés.

Vérifier ce composant

Protocole manuel rapide, dans cet ordre :

1. Le test de la liste des liens, le vrai test du critère 6.1 : ouvrir la liste des liens du lecteur d'écran (VoiceOver : Ctrl + Option + U puis Liens ; NVDA : Insert + F7) et la lire sans regarder la page. Chaque entrée doit avoir du sens seule ; des doublons « Lire la suite » signent l'échec.
2. Au clavier : Tab atteint le lien, Entrée l'active, Espace ne doit PAS l'activer, et le focus est visible.
3. Le test de la couleur (critère 3.1) : passer un paragraphe contenant un lien en niveaux de gris. Le lien reste-t-il repérable ? Sinon, il n'est distingué que par la couleur.
4. À la commande vocale (ou mentalement) : prononcer l'intitulé visible de chaque lien doit suffire à le viser.

Deux outils gratuits du site aident à ce contrôle : le Simulateur Lecteur d'Écran affiche l'arbre d'accessibilité de la page (le nom réellement exposé de chaque lien s'y lit directement), et le Simulateur de Daltonisme vérifie qu'un lien non souligné reste repérable quand on ne distingue pas sa couleur (critère 3.1).

Approfondir avec les fiches critères

• Critère 3.1 : Information par couleur
• Critère 6.1 : Intitulé des liens
• Critère 6.2 : Titre des liens
• Critère 7.1 : Compatibilité scripts
• Critère 10.7 : Focus visible

Toutes les fiches composants accessibles