Essentiel Mis à jour : 2026-06

"Lire la suite", "En savoir plus" : les liens ambigus et comment les corriger

Un lecteur d'écran peut lister tous les liens d'une page sans leur contexte. "Lire la suite" répété dix fois, c'est dix liens indiscernables. Les causes, les solutions et les erreurs à ne pas commettre.

Table des matières

NVDA propose une commande qui extrait tous les liens de la page dans une liste : Insert + F7. L’utilisateur navigue dans cette liste au clavier sans voir le reste du contenu. Sur une page d’actualités avec dix articles, il entend :

Lire la suite
Lire la suite
Lire la suite
Lire la suite

Dix liens. Dix fois le même intitulé. Aucun moyen de distinguer lequel mène où.

JAWS fait la même chose. VoiceOver sur iOS permet de lister les liens d’une page d’un glissement. La fonctionnalité existe dans tous les lecteurs d’écran parce qu’elle est utile : parcourir une page longue lien par lien va deux fois plus vite que de la lire en entier. Un intitulé ambigu annule cet avantage.

Pourquoi l’intitulé doit être compréhensible hors contexte

Le critère RGAA 6.1 exige que l’intitulé de chaque lien soit explicite hors contexte visuel ou via le contexte RGAA autorisé.

Le contexte RGAA autorisé est précis : le titre de section (<h1>-<h6>) qui précède le lien, la cellule de tableau, la liste <li> qui contient le lien, ou le paragraphe directement adjacent. Ces éléments sont accessibles programmatiquement. Un lecteur d’écran peut donc, dans certains modes de navigation, lire le titre “Rapport annuel 2025” suivi du lien “Lire la suite” et reconstituer le sens.

Mais ce contexte n’est disponible que dans le mode lecture linéaire de la page. Dans la liste des liens, il disparaît. L’intitulé seul doit suffire.

Les quatre solutions

Toutes sont valides au regard du RGAA. Elles ne coûtent pas le même effort selon le CMS.

Option 1 : réécrire l’intitulé visible

<a href="/rapport-2025">Lire le rapport annuel 2025</a>

La plus robuste. Pas d’ARIA, pas de CSS : juste un texte explicite. Sur WordPress par exemple, un thème qui génère des liens “Lire la suite” automatiques peut être configuré via le filtre the_content_more_link. Sur un CMS headless, c’est un choix éditorial à documenter dès la conception.

Option 2 : aria-label

<a href="/rapport-2025" aria-label="Lire la suite : Rapport annuel 2025">Lire la suite</a>

L’intitulé visible reste court. Le lecteur d’écran annonce l’aria-label complet. Cette option respecte le critère WCAG 2.5.3 (Label in Name) parce que l’intitulé visible “Lire la suite” est contenu dans l’aria-label.

L’ordre importe : si “Lire la suite” n’est pas au début de l’aria-label, les utilisateurs qui utilisent la reconnaissance vocale (“cliquer sur Lire la suite”) ne pourront pas activer le lien par sa partie visible.

Option 3 : texte masqué visuellement (.sr-only)

<a href="/rapport-2025">Lire la suite
  <span class="sr-only"> du rapport annuel 2025</span>
</a>

L’option la plus légère à implémenter dans un CMS : le texte visible reste “Lire la suite”, et le complément est ajouté dans le code. Le lecteur d’écran lit les deux : “Lire la suite du rapport annuel 2025”. Pas d’aria-label à maintenir.

Option 4 : aria-labelledby

<h2 id="titre-rapport">Rapport annuel 2025</h2>
<p>Découvrez nos résultats...</p>
<a href="/rapport-2025" aria-labelledby="titre-rapport">Lire la suite</a>

aria-labelledby remplace le nom accessible du lien par le contenu de l’élément référencé. NVDA annoncera “Rapport annuel 2025, lien”, ce qui résout exactement le problème dans la liste des liens.

À noter : le texte visible “Lire la suite” est écrasé par le nom accessible, ce qui crée une divergence avec le critère WCAG 2.5.3 (Label in Name). Le pattern reste acceptable ici puisque l’intitulé référencé est plus informatif, mais le titre ciblé doit couvrir précisément l’action du lien : un titre générique comme “Nos actualités” poserait le même problème qu’un “Lire la suite” non différencié. À réserver aux cas où les options 1-3 ne sont pas praticables.

Les tuiles entièrement cliquables

Un pattern fréquent dans les pages d’actualités et les cartes de contenu : envelopper toute la tuile dans un <a> pour rendre sa surface entièrement cliquable.

<!-- ❌ La tuile entière dans un lien -->
<a href="/rapport-2025">
  <article>
    <h2>Rapport annuel 2025</h2>
    <p>Découvrez nos résultats, nos perspectives...</p>
    <time>15 avril 2025</time>
  </article>
</a>

Le lecteur d’écran concatène tout le contenu textuel comme intitulé du lien : “Rapport annuel 2025 Découvrez nos résultats, nos perspectives… 15 avril 2025, lien”. L’utilisateur n’a aucun moyen d’aller au suivant sans écouter la tuile entière.

La correction conserve la surface cliquable via CSS, sans toucher à la sémantique :

<!-- ✅ Lien dans le titre, extension via CSS -->
<article class="card">
  <h2>
    <a href="/rapport-2025" class="card__link">Rapport annuel 2025</a>
  </h2>
  <p>Découvrez nos résultats, nos perspectives...</p>
  <time>15 avril 2025</time>
</article>
/* Le pseudo-élément couvre toute la card */
.card {
  position: relative;
}
.card__link::after {
  content: '';
  position: absolute;
  inset: 0;
}

Le lien porte un intitulé court et explicite. La surface cliquable reste totale. Les textes dans la tuile restent sélectionnables (la tuile n’est pas un lien unique).

Les CTAs répétés sur la même page

Une page de contact avec trois sections d’activités, chacune avec un bouton “Prendre rendez-vous”. Dans la liste des liens, trois fois “Prendre rendez-vous” sans distinction.

La correction est identique à celle des liens “Lire la suite” : contextualiser l’intitulé visible ou son équivalent ARIA.

<!-- ❌ Trois CTAs identiques -->
<a href="/rdv-surf">Prendre rendez-vous</a>
<a href="/rdv-voile">Prendre rendez-vous</a>
<a href="/rdv-kayak">Prendre rendez-vous</a>

<!-- ✅ Option sr-only -->
<a href="/rdv-surf">Prendre rendez-vous
  <span class="sr-only"> pour le surf</span>
</a>
<a href="/rdv-voile">Prendre rendez-vous
  <span class="sr-only"> pour la voile</span>
</a>
<a href="/rdv-kayak">Prendre rendez-vous
  <span class="sr-only"> pour le kayak</span>
</a>

L’intitulé visible reste “Prendre rendez-vous” sur les maquettes. Le lecteur d’écran lit la version complète.

Les liens de téléchargement

“Télécharger” sans précision est une erreur de critère 6.1. L’intitulé doit nommer le document, le format et le poids :

<!-- ❌ -->
<a href="/docs/ra2025.pdf">Télécharger</a>

<!-- ✅ -->
<a href="/docs/ra2025.pdf">Télécharger le rapport annuel 2025 (PDF, 2,4 Mo)</a>

Le format et le poids sont utiles avant d’activer le lien : l’utilisateur sait ce qu’il télécharge et si sa connexion peut le gérer. Le critère 6.1 ne l’impose pas explicitement, mais l’absence d’information sur le format rend l’intitulé incomplet.

Les icônes avec un label qui décrit la forme

Un cas connexe, souvent confondu avec les icônes décoratives. Une icône de cœur dans un lien, avec aria-label="Cœur" : l’intitulé décrit l’apparence du pictogramme, pas l’action du lien.

<!-- ❌ aria-label décrit la forme -->
<a href="/favoris/12" aria-label="Cœur">
  <svg aria-hidden="true"><use href="#icon-heart"/></svg>
</a>
<!-- → NVDA : "Cœur, lien" -->

<!-- ✅ aria-label décrit l'action -->
<a href="/favoris/12" aria-label="Ajouter aux favoris">
  <svg aria-hidden="true"><use href="#icon-heart"/></svg>
</a>
<!-- → NVDA : "Ajouter aux favoris, lien" -->

Le même problème touche les icônes d’engrenage (“Engrenage” au lieu de “Paramètres”), de crayon (“Crayon” au lieu de “Modifier”) ou de poubelle (“Poubelle” au lieu de “Supprimer”). Le sens dépend de l’action, pas du pictogramme.

Pour en savoir plus sur la meilleure pratique pour utiliser les icônes accessibles : Icônes accessibles : aria-hidden, alternatives textuelles et Font Awesome

En audit RGAA

Critère 6.1 : l’intitulé de chaque lien est-il explicite ?

Tester avec la liste des liens de NVDA (Insert + F7) : chaque lien doit être compréhensible sans lire le reste. Vérifier en particulier les pages d’articles, les listes de téléchargements, les pages avec plusieurs sections CTA.

Critère 6.2 : chaque lien a-t-il un intitulé ?

Un <a> sans texte visible, sans alt sur l’image enfant et sans aria-label est un lien vide. Erreur bloquante : le lecteur d’écran annonce “lien” sans aucune information.

Checklist

  • Aucun lien “Lire la suite”, “En savoir plus”, “Cliquez ici” sans complément contextuel
  • Les CTAs répétés (“Prendre rendez-vous”, “Télécharger”…) sont différenciés par un aria-label ou un texte .sr-only
  • Les tuiles cliquables utilisent un lien dans le titre, pas une enveloppe <a> sur toute la carte
  • Les liens de téléchargement précisent le document, le format et le poids
  • Les icônes dans les liens ont un aria-label qui décrit l’action ou la destination, pas la forme
  • Aucun <a> sans intitulé accessible (texte visible, alt ou aria-label)

Erreurs fréquentes en audit

ErreurCritèreCorrection
”Lire la suite” répété × N sans différenciation6.1aria-label ou .sr-only avec le titre de l’article
Tuile entière dans un <a>6.1Lien dans <h2>/<h3>, extension CSS via ::after
aria-label="Cœur" sur un lien favori6.1aria-label="Ajouter aux favoris"
”Télécharger” sans précision6.1Ajouter document, format, poids
Lien icône SVG sans aria-label sur le <a>6.2aria-label sur l’élément <a>
<a> vide (ni texte ni alternative)6.2Ajouter un aria-label ou supprimer le lien

La lettre de l'Atelier A11Y

Ressources pédagogiques, critères RGAA commentés et retours de terrain : une lettre mensuelle pour progresser sur l'accessibilité numérique, sans jargon.

  • Nouveaux articles et ressources pédagogiques
  • Critères RGAA décortiqués avec des exemples concrets
  • Bonnes pratiques et retours d'expérience terrain
S'abonner à la newsletter (s'ouvre dans un nouvel onglet)

Gratuit. Désabonnement possible à tout moment.