Un texte de lien qui a du sens hors contexte

Comment les utilisateurs de lecteurs d’écran naviguent réellement

Avant de parler de la façon de rédiger un texte de lien, il est utile de comprendre comment les gens utilisent réellement les liens lorsqu’ils ne peuvent pas voir la page.

Les lecteurs d’écran offrent un raccourci dont la plupart des utilisateurs voyants ignorent l’existence : appuyer sur une seule touche (généralement la lettre L dans la plupart des lecteurs d’écran) fait défiler tous les liens de la page, les lisant un par un, hors contexte. Les utilisateurs s’en servent pour parcourir rapidement une page, comme l’œil d’un utilisateur voyant pourrait survoler les titres et les boutons d’appel à l’action.

Si votre page comporte douze liens qui disent « Lire la suite », cette liste n’a aucun sens. L’utilisateur entend : « Lire la suite. Lire la suite. Lire la suite. Lire la suite… » Il ne peut pas savoir vers quoi chacun d’eux mène.

C’est le problème fondamental que l’accessibilité du texte de lien tente de résoudre : chaque lien doit être auto-descriptif, car le contexte disparaît lorsque vous naviguez de lien en lien.

Ce que dit WCAG

2.4.4 Fonction du lien (selon le contexte) au niveau A exige que l’objectif de chaque lien puisse être déterminé à partir du texte du lien seul, ou du texte du lien associé à son contexte environnant (le paragraphe, l’élément de liste, la cellule de tableau ou le titre dans lequel il se trouve).

2.4.9 Fonction du lien (lien uniquement) au niveau AAA va plus loin, exigeant que l’objectif du lien découle du texte du lien seul, sans dépendre du contexte. Viser cela est une bonne idée même si vous ne ciblez que la conformité AA.

2.5.3 Étiquette dans le nom (niveau A) exige que lorsqu’un lien ou un bouton a une étiquette textuelle visible, le nom accessible commence par ce texte. Un bouton icône intitulé « En savoir plus sur l’accessibilité » avec un aria-label de « Cliquez ici » échoue à ce critère.

Erreurs courantes et que faire à la place

« Cliquez ici » et « Lire la suite »

Ce sont les défaillances d’accessibilité des liens les plus répandues sur le web.

<!-- Échoue : aucun sens hors contexte -->
<a href="/blog/wcag-compliance">Lire la suite</a>

<!-- Réussit : auto-descriptif -->
<a href="/blog/wcag-compliance">Lire notre guide de conformité WCAG 2.2</a>

La correction est presque toujours simple : remplacez la formule vague par un texte qui décrit la destination ou l’action.

Liens génériques « ici »

« Cliquez ici pour télécharger le rapport » échoue pour la même raison — le mot du lien lui-même n’est que « ici ».

<!-- Échoue -->
<p>Pour les résultats complets, cliquez <a href="/report.pdf">ici</a>.</p>

<!-- Réussit : le texte du lien décrit ce qui est lié -->
<p>Téléchargez le <a href="/report.pdf">rapport d'audit d'accessibilité 2025 (PDF)</a>.</p>

Notez l’indication PDF entre parenthèses — c’est une bonne pratique pour informer les utilisateurs que suivre le lien ouvrira un PDF plutôt qu’une page web.

Liens vers la même destination avec un texte différent, ou vers des destinations différentes avec le même texte

Les deux créent de la confusion. Si cinq liens de navigation disent tous « En savoir plus » mais pointent vers des pages de service différentes, les utilisateurs ne peuvent pas prédire où ils vont atterrir. À l’inverse, deux liens différents qui disent « guide de conformité WCAG » mais mènent à des pages différentes sont tout aussi déroutants.

Liens et boutons composés uniquement d’une icône

Un lien ou un bouton qui ne contient qu’une icône — sans texte visible — doit avoir un nom accessible fourni via aria-label ou aria-labelledby. Sans cela, les lecteurs d’écran annoncent le nom de fichier de l’image de l’icône ou rien du tout.

<!-- Échoue : annoncé comme « lien, graphique » ou le nom de fichier du SVG -->
<a href="/social/twitter">
  <svg><!-- icône twitter --></svg>
</a>

<!-- Réussit : aria-label fournit le nom accessible -->
<a href="/social/twitter" aria-label="QualiBooth sur Twitter">
  <svg aria-hidden="true"><!-- icône twitter --></svg>
</a>

L’attribut aria-hidden="true" sur le SVG empêche les lecteurs d’écran d’annoncer le titre ou le contenu du SVG — puisque le lien lui-même a déjà une étiquette, le contenu de l’icône est redondant.

Utiliser aria-label pour compléter un texte visible

Lorsqu’une page comporte plusieurs liens « Télécharger » et que vous ne pouvez pas modifier le texte visible (une contrainte de conception), aria-label peut étendre le nom accessible :

<!-- Le texte visible est « Télécharger » mais le nom accessible est la chaîne complète -->
<a href="/report-2025.pdf" aria-label="Télécharger le rapport d'accessibilité 2025 PDF">
  Télécharger
</a>

Une mise en garde ici : WCAG 2.5.3 exige que le nom accessible commence par le texte visible. « Télécharger le rapport d’accessibilité 2025 PDF » commence par « Télécharger » — bien. « Rapport d’accessibilité 2025 — Télécharger PDF » ne le fait pas — mauvais.

Liens qui s’ouvrent dans un nouvel onglet

Ouvrir un nouvel onglet sans avertissement désoriente les utilisateurs, en particulier ceux ayant un handicap cognitif ou les utilisateurs de lecteurs d’écran qui peuvent ne pas se rendre compte de ce qui s’est passé. Indiquez le comportement d’ouverture dans un nouvel onglet dans le texte du lien ou avec une note masquée visuellement.

<!-- Signale le comportement d'ouverture dans un nouvel onglet visuellement et pour la technologie d'assistance -->
<a href="https://example.com" target="_blank">
  Voir l'exemple de rapport
  <span class="sr-only">(s'ouvre dans un nouvel onglet)</span>
</a>

Quand le texte de lien fonctionne sans être évident

Le contexte peut légitimement fournir le sens manquant selon WCAG 2.4.4. Un lien « Télécharger » est acceptable s’il se trouve dans une cellule de tableau dont l’en-tête de colonne dit « Rapport annuel » et dont l’en-tête de ligne dit « 2025 ». Le contexte rend l’objectif clair.

C’est différent d’un lien « Lire la suite » à la fin d’un paragraphe autonome. Le paragraphe fournit un contexte, mais « Lire la suite » échoue quand même car le texte du lien pourrait s’appliquer à n’importe quel paragraphe — il n’identifie pas de manière unique la destination.

Liens image

Lorsque le contenu du lien est une image plutôt qu’un texte, l’attribut alt de l’image devient le nom accessible du lien. Le texte alternatif doit décrire la destination du lien, et non l’image elle-même.

<!-- Le texte alternatif décrit la destination du lien, pas l'apparence de l'image -->
<a href="/services/audits">
  <img src="audit-icon.png" alt="Services d'audit d'accessibilité">
</a>

Si l’image est purement décorative et accompagnée d’un texte visible dans le même lien, l’image doit avoir alt="" pour éviter d’annoncer deux fois le même texte.

Un audit rapide que vous pouvez réaliser vous-même

Ouvrez votre page et affichez la liste des liens à l’aide de votre lecteur d’écran (ou installez l’extension de navigateur gratuite HeadingsMap ou WAVE pour voir les liens extraits de leur contexte). Parcourez la liste. Si vous ne pouvez pas dire où va chaque lien à partir du texte seul, il faut y travailler.

La correction la plus courante consiste à ajouter un <span class="sr-only"> (masqué visuellement, accessible aux lecteurs d’écran) avec un contexte supplémentaire, ou simplement à réécrire entièrement le texte du lien. La réécriture est toujours préférable — elle améliore souvent l’ergonomie pour tout le monde, pas seulement pour les utilisateurs de lecteurs d’écran.

Pour un examen approfondi des liens de votre site et d’autres critères WCAG, nos audits d’accessibilité manuels couvrent la fonction des liens dans le cadre d’un examen plus large mené par des testeurs qui utilisent des technologies d’assistance au quotidien.