Un lien qui s’ouvre dans une nouvelle fenêtre ou onglet accessible

Note : si vous avez lu cet article dans l’après-midi du 12 janvier, référez-vous à la note de révision.

Vous avez sans doute déjà entendu ou lu que, pour des raisons d’accessibilité, si on fait s’ouvrir un lien dans une nouvelle fenêtre ou un nouvel onglet, il faut prévenir les internautes de ce comportement. Ce « il faut » cache différentes choses :

• Si on considère la conformité au RGAA, alors ce n’est plus une obligation depuis sa version 4.
  En effet, jusqu’à la version 3 incluse, c’était un critère de niveau A (simple A) (critère autrefois numéroté 13.2 et nommé Dans chaque page Web, pour chaque ouverture de nouvelle fenêtre, l’utilisateur est-il averti ?). Mais dans la version 4, dans un soucis d’harmonisation avec les WCAG, ce critère a disparu car il s’agit, en fait, d’un critère de niveau AAA (triple A) et le RGAA 4 a fait disparaître les critères de ce niveau.
  En effet, la DINUM (la direction interministérielle du numérique) a considéré que, puisque la loi oblige la conformité au niveau AA (double A), alors il n’est pas nécessaire de mettre les critères du niveau suivant dans le référentiel (ce qui est franchement critiquable mais ce n’est pas le sujet) ;
• Si on considère la conformité aux WCAG, alors cela correspond bien à un critère, et de niveau triple A ;
• Si on considère tout simplement la nécessaire accessibilité du web pour les personnes handicapées, alors oui, il faut prévenir de ce comportement, peu importe le niveau légal de conformité à respecter ; d’autant plus que ce n’est pas si difficile à faire.

Pas si difficile à faire… oui, mais… On peut se demander comment faire au mieux ; c’est l’objet de cet article. Mais d’abord, peut-être vous demandez-vous pourquoi et qui il faudrait prévenir de ce comportement ?

Pourquoi prévenir qu’un lien s’ouvre dans une nouvelle fenêtre ?

Ce qui est intéressant avec les WCAG, c’est que, quand on se plonge un peu dedans, on peut apprendre bien des choses. À l’inverse du RGAA qui, par sa forme, joue plutôt un rôle de référentiel technique à destination des personnes expertes réalisant des audits, les WCAG sont une documentation très fournie.

Chaque critère et chaque technique nous explique à qui ça sert, à quel besoin ça répond pour les personnes handicapées et donc, pourquoi on doit faire comme ci et pas comme ça.

Hélas, parfois, on trouve des surprises et je me suis un peu triturée le cerveau pour comprendre l’organisation et où trouver les informations que je voulais. Je documente ça avant de passer à l’explication. Vous pouvez directement passer au chapitre de l’explication si les méandres des WCAG ne vous intéressent pas.

Trouver les informations dans le critère WCAG concerné et les techniques associées

Dans les WCAG, on trouve un seul critère demandant de prévenir, en avance, qu’un lien s’ouvre dans une nouvelle fenêtre. Il s’agit du critère de succès 3.2.5 Change on request (Changement à la demande), de niveau triple A.

On trouve également quatre techniques à propos des liens s’ouvrant dans une nouvelle fenêtre. Les techniques sont des exemples de moyens de se conformer aux WCAG mais ne sont pas requises pour y être conforme. Elles sont non-normatives, contrairement aux critères de succès et sont associées à un ou plusieurs critères. Ces quatre techniques m’ont beaucoup questionnée :

• Deux techniques de conseil (Advisory) :
  • La technique G200 « Ouvrir un lien dans une nouvelle fenêtre ou un nouvel onglet seulement si nécessaire » (par exemple, le lien vers la politique de confidentialité dans un formulaire, pour éviter de perdre sa saisie), associée, sans qu’on sache vraiment pourquoi, aux critères :
    • 3.2.1 On focus (Au focus) (simple A), concernant les composants d’interface lorsqu’ils reçoivent le focus ;
    • 3.2.5 Change on request (triple A).
  • La technique G201 « Avertir les utilisateurices à l’avance de l’ouverture d’une nouvelle fenêtre ». Cette technique parle des liens s’ouvrant en nouvelle fenêtre et est pourtant associée aux critères suivants, sans qu’on sache pourquoi non plus :
    • 3.2.1 On focus (simple A) ;
    • 3.2.2 On input (À la saisie) (simple A), concernant donc les champs de formulaire.
• Deux techniques suffisantes (Sufficient) pour répondre au critère de succès de niveau triple A 3.2.5 Change on request :
  • La technique H83 « Utiliser l’attribut target pour ouvrir une nouvelle fenêtre à la demande de l’utilisateurice et l’indiquer dans le texte du lien » ;
  • La technique SCR24 « Utiliser l’amélioration progressive pour ouvrir les nouvelles fenêtres à la demande de l’utilisateurice ».

Les deux techniques G200 et G201 sont donc associées à des critères de niveau simple A et, c’est peut-être ce qui a fait que prévenir qu’un lien s’ouvre dans une nouvelle fenêtre a été intégré au RGAA en niveau simple A au départ. Toutefois, ces techniques n’ont à priori aucun rapport avec ces critères pour y répondre.

Ainsi, seules les techniques H83 et SCR24 sont bien associée au critère de succès 3.2.5 pour y répondre de manière suffisante sur le sujet des liens s’ouvrant dans une nouvelle fenêtre. Toutefois, elles sont, en réalité, équivalentes à la G201 donc je m’appuie sur cette dernière malgré tout dans la suite de l’article.

L’explication du pourquoi via les techniques WCAG concernées

La technique G201 explique qu’ouvrir un lien dans une nouvelle fenêtre peut désorienter, si elles ne sont pas prévenues à l’avance, les personnes ayant des difficultés à percevoir le contenu visuel (les personnes aveugles ou malvoyantes), et certaines personnes ayant des handicaps cognitifs. Les techniques H83 et SCR24 ajoutent que les personnes peuvent même passer à côté de l’ouverture d’une nouvelle fenêtre, si celle-ci ne s’ouvre pas au premier plan.

Fournir un avertissement permet donc aux personnes de décider si elles veulent vraiment cliquer sur ce lien qui les fera changer de fenêtre.

Cela leur permet aussi de savoir comment retourner en arrière dans leur navigation. En effet, la fonctionnalité de retour arrière du navigateur ne permettra pas de revenir à la fenêtre où elles étaient : elles devront fermer la nouvelle fenêtre ou naviguer entre les fenêtres ouvertes pour retrouver leur chemin. Une personne aveugle, par exemple, ne peut pas voir qu’une nouvelle fenêtre s’est ouverte et n’aura pas d’information donnée par son lecteur d’écran via le navigateur.

La technique H83 indique que les agents utilisateurs (navigateurs, technologies d’assistance…) peuvent permettre d’informer de l’ouverture dans une nouvelle fenêtre et de la désactiver si on utilise bien l’attribut target="_blank". Je n’ai jamais rencontré cette mise en œuvre mais il existe des extensions de navigateurs qui permettent de désactiver le comportement, par exemple.

La solution fréquente : attribut title, voire aria-label

La solution qui est sans doute la plus fréquemment évoquée est celle d’ajouter l’information « Nouvelle fenêtre » dans un attribut title voire un attribut aria-label placé sur le lien. Vous remarquerez que ce n’est pas une solution donnée dans la technique G201 des WCAG.

Je n’aime pas cette solution pour plusieurs raisons.

Tout d’abord, si on utilise cette technique, alors il faut reprendre l’intitulé du lien (le texte contenu entre la balise ouvrante <a> et la balise fermante </a>) dans l’attribut title ou aria-label (j’explique pourquoi ci-après). La maintenabilité de la pratique n’est donc pas toujours garantie car, à moins d’automatiser, on a vite fait d’oublier ou de se tromper ou de modifier l’un sans modifier l’autre.

Exemple :

<a href="https://www.lalutineduweb.fr" target="_blank" rel="noopener" title="La Lutine du Web - Nouvelle fenêtre">La Lutine du Web</a>

Ensuite, l’usage de ces attributs pour les liens peut poser différents problèmes.

Critique de l’usage de l’attribut aria-label

L’attribut aria-label écrase tout intitulé se trouvant dans le lien : c’est risqué si on se trompe.

Un attribut aria-label ne reprenant pas l’intitulé visible du lien posera problème aux personnes contrôlant leur ordinateur à la voix puisque, si elles nomment le lien pour aller dessus, le logiciel ne le trouvera pas (se référer au test 6.1.5 du RGAA qui contrôle la pratique).

Ainsi, si l’intitulé de mon lien entre les balises est « La Lutine du Web » et que l’attribut aria-label sur ce lien est simplement « Nouvelle fenêtre », alors le nom de ce lien est « Nouvelle fenêtre ». C’est ce que les lecteurs d’écran liront et c’est ce que le logiciel de contrôle vocal aura comme information uniquement.

Je ne recommande donc jamais cette pratique trop dangereuse.

De plus, cette pratique n’a globalement d’utilité que pour les personnes utilisant un lecteur d’écran. Les personnes malvoyantes ou ayant un handicap cognitif n’en utilisant pas ne seront pas plus avancées.

Critique de l’usage de l’attribut title

Pour l’attribut title, ça peut arriver que, selon le lecteur d’écran utilisé, sa configuration et le mode de navigation (linéaire avec les flèches, ou bien via les éléments interactifs avec tabulation), le title soit le seul restitué ou ne soit pas du tout restitué.

Si on utilise un attribut title, alors, comme on doit reprendre l’intitulé du lien, cela signifie qu’il pourra y avoir un doublon de lecture de cet intitulé par les lecteurs d’écran. Le lecteur d’écran peut lire l’intitulé + le title.

De plus, l’attribut title n’est pas une fonctionnalité accessible en tant que telle :

• Comme je le disais, il n’est pas forcément toujours lu par les lecteurs d’écran ;
• Il ne fonctionne ni sur écran tactile, ni en navigation clavier, ni via le contrôle vocal ;
• Quand on zoome dans la page, il ne s’agrandit pas.

Bref, c’est nul.

Ma recommandation : texte caché accessible et icône

Préalablement, on peut noter que la solution la plus accessible et la plus simple serait d’écrire « (nouvelle fenêtre) » dans l’intitulé de lien, visible de tout le monde mais, généralement, les éditeurices de sites web n’aiment pas trop.

Dernièrement, j’ai eu l’occasion de modifier un script qui automatise la gestion de ces liens qui s’ouvrent dans une nouvelle fenêtre. J’ai alors fait en sorte que le code puisse répondre au maximum aux différents besoins.

J’ai choisi la solution suivante, qui, je le découvre en rédigeant cet article, est assez proche de celle de l’exemple 2 dans la technique G201 des WCAG :

1. Utiliser un texte masqué en CSS de façon accessible (la fameuse « classe sr-only ») pour ajouter le texte « Nouvelle fenêtre » directement dans l’intitulé du lien. Ainsi, on répond au besoin des personnes aveugles ou malvoyantes d’être prévenues de ce changement de contexte ;
2. Ajouter une icône dans le lien afin que ces liens soient identifiables visuellement. Cette icône doit correspondre à celle qu’on a coutume de rencontrer pour cet usage : soit une flèche en diagonale du bas-gauche vers le haut-droite, soit la même flèche sortant d’un carré. Ainsi, on permet à tout le monde d’identifier ces changements de contexte mais surtout aux personnes ayant un handicap cognitif pour qui ça peut être une difficulté ;
3. Englober l’icône avec un élément span caché aux lecteurs d’écran via l’attribut aria-hidden="true" puis ajouter au span un attribut title="Nouvelle fenêtre" afin que les personnes utilisant la souris puissent quand même avoir la signification de l’icône au survol. L’attribut aria-hidden="true" est nécessaire car j’ai eu la surprise qu’un lecteur d’écran me lise ce title sans ça (ce qu’ils ne font normalement pas) ;
4. Enfin, on peut également ajouter l’explication de ce qu’est cette icône dans une page d’aide et accessibilité.

Exemple de code

<a href="https://www.lalutineduweb.fr" target="_blank" rel="noopener">
  La Lutine du Web

  <span class="sr-only">&nbsp;-&nbsp;Nouvelle fenêtre</span>

  <span title="Nouvelle fenêtre" aria-hidden="true">
    <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" aria-hidden="true"><path d="M21 13v10h-21v-19h12v2h-10v15h17v-8h2zm3-12h-10.988l4.035 4-6.977 7.07 2.828 2.828 6.977-7.07 4.125 4.172v-11z"/></svg>
  </span>
</a>

Merci à webetcaetera pour sa question qui m’aura menée à cet article.

Ressources complémentaires

• Sur l’attribut title :
  • J’avais déjà abordé cette histoire de lien qui s’ouvre dans une nouvelle fenêtre et les problèmes de l’attribut title dans Le vaste monde des alternatives textuelles : l’attribut title (3/6), 25 février 2018. (Je me suis donc répétee mais avec des choses nouvelles et orienté directement vers le sujet qui nous intéresse) ;
  • « Title Texts Suck », par Axess Lab (en anglais).
• Sur l’attribut aria-label : aria-label is a code smell, Eric Bailey, 31 octobre 2022.

Note de révision

Cet article a été publié une première fois dans l’après-midi du 12 janvier puis j’ai dû le dépublier quand je me suis rendue compte que j’avais écrit une bêtise par rapport au critère de succès et techniques WCAG. Il m’a fallu creuser un peu pour réaliser les corrections car c’est un peu le bazar dans les WCAG !

Le chapitre « Trouver les informations dans le critère WCAG concerné et les techniques associées » a donc été entièrement révisé.

Dans le chapitre suivant « L’explication du pourquoi via les techniques WCAG concernées », des phrases sur les techniques H83 et SCR24 ont été ajoutées.

Merci à Sp3r4z de m’avoir mis la puce à l’oreille et à Romain Gervois pour la vérification de bonne compréhension.