WCAG 2.4.4 : Objectif du lien (dans le contexte)

Ce que signifie cette règle

WCAG 2.4.4 — Objectif du lien (dans le contexte) — est un critère de succès de niveau A relevant du principe « Utilisable ». Il stipule que l’objectif de chaque lien doit pouvoir être déterminé à partir du texte du lien seul, ou à partir du texte du lien combiné à son contexte de lien déterminé par des moyens programmatiques. Si ni l’un ni l’autre n’est suffisant, le lien échoue à ce critère.

L’expression « contexte de lien déterminé par des moyens programmatiques » est définie avec précision par les WCAG. Elle renvoie aux informations qui peuvent être dérivées de la même phrase, du même paragraphe, du même élément de liste ou de la même cellule de tableau que le lien, ou du titre qui précède une section contenant le lien. Elle inclut également le contexte exposé via des relations ARIA telles que aria-labelledby ou aria-describedby. De manière cruciale, ce contexte doit être disponible par des moyens programmatiques — ce qui signifie que les technologies d’assistance peuvent le lire automatiquement — et non simplement suggéré visuellement pour les utilisateurs voyants.

En pratique, les éléments et attributs HTML suivants sont directement concernés par ce critère : les éléments d’ancrage <a href>, les éléments <area> dans les images réactives, les éléments <button> qui déclenchent une navigation, les éléments stylés ou scriptés pour se comporter comme des liens à l’aide de rôles ARIA tels que role='link', et les éléments SVG <a>. Le nom accessible du lien — calculé à partir de son texte interne, de aria-label, de aria-labelledby ou d’un attribut alt sur une image enfant — est le principal vecteur de communication de l’objectif.

Ce qui est considéré comme conforme : Un lien est conforme si un utilisateur peut déterminer sa destination ou sa fonction sans contexte supplémentaire (par exemple, « Télécharger le rapport annuel 2024 au format PDF »), ou si le contexte programmatique environnant rend l’objectif clair (par exemple, un lien « En savoir plus » à l’intérieur d’un <li> qui commence par le titre de l’article). Le texte du lien n’a pas besoin d’être unique à l’échelle de toute la page ; il doit seulement être non ambigu dans son contexte.

Ce qui est considéré comme non conforme : Un texte de lien générique tel que « cliquez ici », « en savoir plus », « ici », « plus » ou « lien » est non conforme lorsque le contexte programmatique environnant ne permet pas de lever l’ambiguïté sur la destination. Un lien image avec un attribut alt manquant ou vide est également non conforme, car le nom accessible est totalement absent.

Exception officielle : Les WCAG reconnaissent une exception. Lorsque l’objectif du lien est intentionnellement ambigu — c’est-à-dire que le fait de le rendre connu à l’avance détruirait son utilité ou celle du contenu environnant — le critère ne s’applique pas. Cette exception est extrêmement étroite et rarement applicable dans des scénarios réels.

Pourquoi c’est important

Environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, selon l’Organisation mondiale de la santé. Parmi elles, les personnes aveugles qui s’appuient sur des lecteurs d’écran sont particulièrement affectées par les textes de lien ambigus. Les logiciels de lecture d’écran tels que NVDA, JAWS et VoiceOver permettent aux utilisateurs de naviguer dans une page en générant une liste de tous les liens extraits de leur contexte. Lorsque cette liste contient des dizaines d’entrées qui indiquent toutes « en savoir plus » ou « cliquez ici », les personnes aveugles ne peuvent pas déterminer quel lien mène où sans revenir à chacun et lire le contenu environnant — un processus long et désorientant.

Les personnes ayant des limitations motrices qui naviguent au clavier uniquement, avec des contacteurs ou des dispositifs de suivi oculaire en tirent également un bénéfice substantiel. Ces utilisateurs parcourent souvent les éléments interactifs séquentiellement avec la touche de tabulation et s’appuient sur l’étiquette de l’élément focalisé pour décider de l’activer ou non. Un texte de lien ambigu impose des étapes de navigation supplémentaires qui augmentent la fatigue et le taux d’erreur.

Les personnes ayant des troubles cognitifs — y compris les troubles de l’attention, les troubles de la mémoire ou un faible niveau de littératie — bénéficient de textes de lien clairs et descriptifs, car ils réduisent la charge cognitive nécessaire pour comprendre la structure d’une page. Elles n’ont pas besoin de conserver des informations contextuelles en mémoire de travail pendant qu’elles parcourent les liens.

Un scénario concret : Considérons une page de liste de produits d’un site e-commerce qui affiche dix produits, chacun avec un bouton « Acheter maintenant » et un lien « En savoir plus » rendus de manière identique. Une personne aveugle qui navigue via la liste des liens entend dix occurrences consécutives de « En savoir plus » sans indication du produit auquel chaque lien se rapporte. Pour acheter le bon produit, elle doit lire tout le contexte environnant de chaque lien — un processus qui peut prendre des minutes plutôt que des secondes. Avec un texte de lien descriptif tel que « En savoir plus sur le casque Sony WH-1000XM5 », la même tâche ne nécessite qu’un seul geste de navigation.

Au-delà de l’accessibilité, un texte de lien descriptif offre des avantages SEO mesurables. Les robots d’indexation des moteurs de recherche utilisent le texte d’ancrage comme signal pour comprendre le contenu de la page liée. Un texte de lien descriptif et riche en mots-clés améliore l’explorabilité et l’indexabilité des ressources liées, contribuant positivement au classement dans les résultats de recherche. De plus, un texte de lien clair réduit les taux de rebond et les demandes d’assistance en définissant des attentes utilisateur précises avant la navigation.

Règles axe-core associées

• link-name : Cette règle vérifie que chaque élément <a> avec un attribut href, chaque élément avec role='link' et chaque élément <area> possède un nom accessible non vide. Le nom accessible est calculé via le calcul standard du nom accessible ARIA : contenu textuel interne, aria-label, aria-labelledby ou attribut alt d’un enfant <img>. Axe signale une violation lorsque le nom accessible calculé est vide, composé uniquement d’espaces ou totalement absent. Cette règle détecte la forme la plus grave d’échec de 2.4.4 — les liens totalement sans nom — mais elle ne peut pas détecter les liens dont les noms sont techniquement présents mais sémantiquement dénués de sens (par exemple, « cliquez ici » ou « en savoir plus »), car les outils automatisés ne peuvent pas déterminer l’intention à partir de chaînes génériques.
• duplicate-id-aria : Cette règle vérifie qu’aucun des éléments de la page ne partage le même attribut id lorsqu’il est référencé par un attribut ARIA tel que aria-labelledby ou aria-describedby. Des identifiants dupliqués utilisés dans des relations ARIA amènent le navigateur à résoudre la référence de manière imprévisible — généralement vers le premier élément correspondant dans l’ordre du DOM — ce qui peut amener le nom accessible d’un lien à être calculé à partir du mauvais élément. Par exemple, si deux liens utilisent chacun aria-labelledby='product-title' et que deux éléments partagent cet ID, les lecteurs d’écran peuvent annoncer le mauvais nom de produit pour l’un ou l’autre lien, violant directement 2.4.4. Axe signale cela comme un problème critique, car le nom accessible qui en résulte est peu fiable.

Il est important de comprendre les limites des tests automatisés pour ce critère. Des outils comme axe-core peuvent vérifier qu’un lien possède un nom accessible, mais ils ne peuvent pas vérifier que ce nom est significatif. Un lien nommé « ici » passe automatiquement la règle link-name parce que la chaîne n’est pas vide. Un jugement humain est nécessaire pour évaluer si un texte de lien générique enfreint 2.4.4. Cela fait des tests manuels un complément essentiel à l’analyse automatisée pour ce critère.

Comment tester

1. Analyse automatisée avec axe DevTools ou Lighthouse : Installez l’extension de navigateur axe DevTools (Chrome ou Firefox) ou lancez un audit d’accessibilité Lighthouse dans Chrome DevTools. Déclenchez une analyse de page complète et filtrez les résultats pour les règles link-name et duplicate-id-aria. Examinez chaque élément signalé : confirmez que le nom accessible calculé est absent ou vide pour les violations link-name, et vérifiez que les identifiants dupliqués perturbent les références d’étiquettes ARIA pour les violations duplicate-id-aria. Notez que le passage de ces vérifications automatisées ne garantit pas une conformité complète à 2.4.4 — poursuivez avec les étapes manuelles.
2. Revue manuelle de la liste des liens : Dans NVDA avec Firefox, appuyez sur la combinaison de touches Insert+F7 pour ouvrir la boîte de dialogue Liste des éléments et sélectionnez « Liens ». Passez en revue chaque entrée de la liste isolément, sans contexte visuel. Demandez-vous : pouvez-vous déterminer où mène chaque lien à partir de son texte seul ? Répétez l’opération dans JAWS avec Chrome en utilisant Insert+F7 pour ouvrir la liste des liens. Dans VoiceOver avec Safari sur macOS, appuyez sur Contrôle+Option+U pour ouvrir le rotor d’éléments Web et sélectionnez « Liens ». Tout lien dont l’objectif est ambigu pris isolément doit être examiné par rapport à son contexte programmatique.
3. Test de navigation au clavier : En utilisant uniquement la touche Tab, parcourez tous les éléments interactifs de la page. Chaque fois que le focus se place sur un lien, lisez uniquement le texte annoncé (et non le contenu visuel environnant). Si vous ne pouvez pas déterminer la destination du lien à partir de ce qui est annoncé, il est probable que le lien échoue à 2.4.4. Portez une attention particulière aux liens constitués uniquement d’icônes (icônes de réseaux sociaux, boutons fléchés) et aux liens image.
4. Vérification du contexte : Pour les liens qui s’appuient sur le contexte environnant (par exemple, « En savoir plus » à l’intérieur d’un élément de liste), inspectez le DOM pour confirmer que le texte contextuel se trouve dans la même phrase, le même paragraphe, le même élément de liste ou la même cellule de tableau que le lien. Un contexte uniquement adjacent visuellement mais non associé par des moyens programmatiques ne satisfait pas le critère. Utilisez les DevTools du navigateur pour inspecter l’arbre d’accessibilité calculé et confirmer la relation.
5. Audit des étiquettes ARIA : Recherchez dans le code source de la page toutes les utilisations de aria-labelledby et aria-describedby sur les éléments de lien. Vérifiez que chaque ID référencé existe une seule fois dans le document et que l’élément référencé contient le texte descriptif souhaité. Utilisez le panneau de l’arbre d’accessibilité du navigateur (disponible dans Chrome DevTools sous l’onglet Accessibility) pour confirmer le nom calculé de chaque lien.

Comment corriger

Lien constitué uniquement d’une icône sans nom accessible — Incorrect

<!-- Un lien icône sans texte et sans aria-label -->
<a href='https://twitter.com/accsible'>
  <svg viewBox='0 0 24 24' width='24' height='24'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Lien constitué uniquement d’une icône sans nom accessible — Correct

<!-- aria-label fournit un nom accessible descriptif pour les lecteurs d’écran -->
<a href='https://twitter.com/accsible' aria-label='Accsible sur Twitter'>
  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Liens génériques « En savoir plus » dans une liste de cartes — Incorrect

<!-- Plusieurs textes de lien identiques sans contexte distinctif -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>Read more</a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>Read more</a>
  </li>
</ul>

Liens génériques « En savoir plus » dans une liste de cartes — Correct

<!-- Option 1 : texte visuellement masqué ajouté au lien -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>
      Read more
      <span class='sr-only'>about the Istanbul Accessibility Summit 2024</span>
    </a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>
      Read more
      <span class='sr-only'>about the New WCAG 2.2 Guidelines</span>
    </a>
  </li>
</ul>

<!-- Option 2 : utiliser aria-label pour remplacer entièrement le texte visible -->
<a href='/events/istanbul-2024' aria-label='Read more about the Istanbul Accessibility Summit 2024'>
  Read more
</a>

Lien image avec attribut alt vide — Incorrect

<!-- L’image a un alt vide, ce qui rend le lien totalement sans nom -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='' />
</a>

Lien image avec attribut alt vide — Correct

<!-- L’attribut alt de l’image fournit le nom accessible du lien -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='Accsible Overlay Widget — product details' />
</a>

aria-labelledby référençant un ID dupliqué — Incorrect

<!-- Deux éléments partagent le même ID ; le second lien se résout vers la mauvaise étiquette -->
<div>
  <span id='card-title'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title'>View</a>
</div>
<div>
  <span id='card-title'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title'>View</a>
</div>

aria-labelledby référençant un ID dupliqué — Correct

<!-- Chaque ID est unique ; chaque lien se résout vers la bonne étiquette -->
<div>
  <span id='card-title-docs'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title-docs'>View</a>
</div>
<div>
  <span id='card-title-pricing'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title-pricing'>View</a>
</div>

Erreurs courantes

• Utiliser « cliquez ici », « ici », « plus » ou « en savoir plus » comme texte de lien sans aucun nom accessible supplémentaire via aria-label, aria-labelledby ou des éléments <span> visuellement masqués — ces chaînes sont dénuées de sens lorsqu’elles sont extraites de leur contexte visuel par un lecteur d’écran.
• Ajouter un aria-label à un lien qui contient un texte visible différent sans s’assurer que l’étiquette commence par la chaîne de texte visible — cela enfreint WCAG 2.5.3 (Label in Name) et provoque de la confusion pour les utilisateurs de commandes vocales qui tentent d’activer le lien en prononçant son nom visible.
• Définir alt='' sur une image qui constitue le seul contenu d’un lien, ce qui rend le nom accessible calculé du lien vide et provoque une violation link-name — un alt vide est correct pour les images décoratives, mais pas lorsque l’image est le seul contenu d’un élément interactif.
• Appliquer aria-hidden='true' au seul nœud de texte à l’intérieur d’un lien, ce qui supprime le nom accessible de l’arbre d’accessibilité et laisse le lien sans nom pour les utilisateurs de lecteurs d’écran.
• Réutiliser la même valeur d’id sur plusieurs éléments référencés par aria-labelledby sur différents liens, ce qui amène les lecteurs d’écran à calculer le mauvais nom accessible pour un ou plusieurs liens en raison d’une résolution d’ID imprévisible.
• Envelopper un composant de carte entier (titre, image, paragraphe et bouton) dans une seule balise <a>, ce qui amène les lecteurs d’écran à lire l’intégralité du contenu de la carte comme nom accessible du lien — une expérience verbeuse et désorientante — au lieu d’utiliser une étiquette brève et descriptive.
• Se fier uniquement à une info-bulle d’attribut CSS title ou à une pseudo-classe :hover pour fournir le contexte du lien — l’attribut title est exposé de manière incohérente par les lecteurs d’écran et est totalement inaccessible aux utilisateurs au clavier qui ne peuvent pas déclencher les états de survol.
• Utiliser l’URL elle-même comme texte de lien (par exemple, <a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>), ce qui est imprononçable par les lecteurs d’écran et dénué de sens pour les personnes ayant des troubles cognitifs.
• Générer dynamiquement des ID de liens ou des valeurs d’attribut ARIA avec des frameworks JavaScript sans garantir leur unicité — les composants React, Vue et Angular rendus dans des listes produisent fréquemment des ID dupliqués à moins que des stratégies de clé explicites ne soient mises en œuvre.
• Oublier d’ajouter focusable='false' aux icônes SVG en ligne à l’intérieur des liens dans Internet Explorer et les anciennes versions d’Edge, ce qui amène le SVG à recevoir son propre arrêt de tabulation et amène les lecteurs d’écran à annoncer le SVG séparément du texte du lien, scindant ainsi le calcul du nom accessible.

Lien avec la réglementation turque en matière d’accessibilité

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires en matière d’accessibilité numérique alignées sur WCAG 2.2. WCAG 2.4.4 Objectif du lien (dans le contexte) est un critère de niveau A, ce qui signifie qu’il fait partie du socle obligatoire que toutes les entités concernées doivent atteindre.

La circulaire s’applique à un ensemble défini de types d’entités dans les secteurs public et privé. Les institutions publiques — y compris les ministères, les agences d’État, les municipalités et les universités publiques — doivent atteindre une conformité complète de niveau A dans l’année suivant la publication de la circulaire. Les entités du secteur privé couvertes par la circulaire disposent d’un délai de conformité de deux ans. Le périmètre du secteur privé est large et inclut explicitement les plateformes de commerce électronique, les banques et institutions financières, les hôpitaux privés et prestataires de soins de santé, les opérateurs de télécommunications comptant 200 000 abonnés ou plus, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le ministère de l’Éducation nationale.

Pour toutes ces entités, un texte de lien non conforme constitue une violation réglementaire directe. Considérons une plateforme de commerce électronique turque qui affiche des pages de liste de produits avec des liens « Satın Al » (Acheter maintenant) ou « Devamını Oku » (Lire la suite) répétés, sans contexte programmatique. Une personne aveugle s’appuyant sur TalkBack, NVDA ou VoiceOver serait incapable de déterminer à quel produit chaque lien se rapporte, ce qui constitue un échec de 2.4.4 et une violation des exigences de la circulaire. De même, le portail de prise de rendez-vous d’un hôpital public qui utilise des liens de navigation constitués uniquement d’icônes sans noms accessibles échouerait à la fois à la règle axe link-name et au mandat de la circulaire.

La conformité à 2.4.4 n’est pas un simple point de contrôle technique. La circulaire signale un engagement gouvernemental plus large en faveur de l’inclusion numérique pour les quelque 8,5 millions de citoyens turcs en situation de handicap. Pour les entités concernées, traiter de manière proactive les problèmes d’objectif de lien — via des standards de design system, la formation des développeurs et l’analyse automatisée dans les chaînes CI/CD — est à la fois une obligation légale et un investissement judicieux dans l’ergonomie et la performance de recherche. Le non-respect des délais imposés peut entraîner des actions réglementaires de la part des autorités de supervision compétentes désignées par la circulaire.