Les liens d'évitement

Sommaire :

1. Bref rappel historique
2. La généralisation du lien d'évitement
3. Bénéfices utilisateurs
4. Méthode d'implémentation générale
5. Les trois types de liens d'aide à la navigation dans la page et comment les utiliser
6. La question épineuse de l'intégration graphique
7. Relation entre les liens d’aide à la navigation dans la page et un sommaire
8. Conclusion

1- Bref rappel historique :

A l'origine, le lien d'évitement ("skip link") est décrit comme un mécanisme permettant de passer un regroupement de liens.

C'est le sujet de l'item WCAG 13.6 : "Regrouper les liens de même nature, identifier le groupe (pour les agents-utilisateurs), et jusqu'à ce que les agents utilisateurs le permettent, donner un moyen de s'affranchir du groupe."

On peut voir ce type d'implémentation en action sur les pages du W3C, notamment pour passer le très long menu de gauche :

<h2 class="navhead"><a name="technologies" id="technologies" shape="rect">W3C A to Z</a></h2>
<ul>
<li class="invisible">__<a class="navlink" title="Skip W3C A-Z" href="#news" shape="rect">Skip to News</a>__</li>
</ul>

2- La généralisation du lien d'évitement :

La notion de "skip link" s'est peu à peu étendue à des mécanismes de portée plus globale destinés à faciliter la navigation dans la structure de la page.

C'est, par exemple, l'objectif du critère 12.4 d'Accessiweb : "Y a-t-il des liens facilitant la navigation dans la page ?".

Leurs implémentations et leurs rôles regroupent des réalités assez différentes; chacune de ces aides à la navigation requiert des dispositions particulières.

On peut distinguer trois types d'aide à la navigation dans la page :

• Les liens d'accès rapide, comme "aller au menu", "aller au contenu", "aller à la recherche".
• Les liens d'évitement comme "passer à la section…".
• Les liens de navigation interne, comme le fameux "Retour en haut de page".

Vous remarquerez le distinguo entre liens d'accès rapide et liens d'évitement; il est important de le faire car leurs objectifs ne sont pas totalement identiques.

3- Bénéfices utilisateurs

Le bénéfice recherché est très simple : ces liens permettent de faciliter la navigation dans la structure de la page; ils concernent tous les utilisateurs, indépendamment de leur situation et de leurs outils.

Un focus particulier est donné, néanmoins, à certains utilisateurs : ceux qui ne peuvent pas utiliser de souris.

Pour ces utilisateurs, la présence de ces liens est vitale; il s'agit, bien souvent, de la seule aide que nous pouvons leur apporter.

Il est facile de le comprendre sur des pages très complexes et sur lesquelles on rencontre un grand nombre de liens et de sous-menus.

C'est le cas, par exemple, d'un célèbre site de vente en ligne où pour commander le premier livre d'une sous-section (par exemple, livres, jeunesse, 0 – 3 ans) il faut 272 tabulations entre la page d'accueil et la saisie du paiement alors qu'il ne faut que 8 clicks de souris.

La simple implémentation d'un lien d'accès rapide au contenu, par exemple, permettrait à ces utilisateurs d'économiser plus de 205 tabulations (charge finale : 67 tabulations), rendant "possible" ce qui, en l'état, relève du parcours du combattant.

On voit bien, dans ce cas de figure, malheureusement très répandu, combien la présence de ces liens peut être utile, voire cruciale et, surtout, combien il est important qu'ils demeurent visibles.

4- Méthode d'implémentation générale.

Ces liens fonctionnent avec deux éléments : le lien lui-même et une ancre qui en constitue la cible.

Du point de vue de la spécification HTML, la cible peut être n'importe quel élément doté d'un identifiant (attribut id ou name)

Il est préférable et plus robuste, notamment pour IE, d'implémenter l'ancre au moyen d'un "lien réel" (balise a) sur le modèle :

<a href="#contenu">Aller au contenu</a>
Avec comme cible
<a href="#" id="contenu" name="contenu"></a>

A noter que l'ancre cible n'aurait pas besoin, en théorie, de référence href, mais qu'il s'agit là d'un moyen pratique de corriger un défaut d'IE : en effet, la prise de focus d'une ancre avec la souris désynchronise la tabulation sous IE lorsque l'ancre cible est dépourvue de référence href. Autrement dit, si vous cliquez sur "aller au contenu", vous obtenez bien le focus sur l'ancre cible, mais si vous tabulez à la suite, la tabulation ne suit pas et reste là où vous en étiez auparavant.

Une autre manière de résoudre ce problème pour IE est de conférer, au moyen de CSS, un état "layout" à l'ancre cible. Notez, cependant, que cette solution, aussi élégante soit-elle, posera un problème, sur IE, lorsque CSS sera désactivé.

Je ne m'étendrais pas sur ce sujet et je vous recommande plutôt d'implémenter vos ancres cibles sous forme d'un lien "<a>" avec un href, un id et un name. A la vérité cela va créer une gêne pour les lecteurs d’écrans qui vont restituer ces liens, à la différence d’une ancre sans href. Mais, comme vous pourrez le constater, l’essentiel du propos étant d’en limiter l’usage à ce qui est vraiment utile, la gêne occasionnée peut être considérée comme "acceptable".

Ce sera à vous de choisir la bonne méthode en fonction de votre page et du nombre d'ancres nécessaires.

Enfin, le positionnement de l'ancre cible doit permettre de recueillir toute les informations nécessaires, notamment de titre, permettant d'identifier clairement la section ou l'élément atteint.

Une erreur commune consiste à implémenter la cible après un élément de titre :

<h2>Contenu</h2>
<a href="#" id="contenu" name="contenu" /></a>

Ce positionnement ne permettra pas à l'utilisateur, par exemple de lecteur d'écran, de relier explicitement la cible au titre de la section, ce qui peut créer une ambiguité.

5- Les trois types de liens d'aide à la navigation dans la page et comment les utiliser.

5.1- Les liens d'évitement :

Comme nous l'avons vu, il s'agit de liens permettant de passer un groupe de liens ou, par généralisation, de passer d'une section à une autre.

Ils s'implémentent dans le corps même de la structure, comme premier lien disponible de la section qu'ils permettent de sauter, comme dans l'exemple de la page du W3C que je résume ci-dessous :

<h2>Menu de navigation</h2>
<ul>
<li><a href="#actu">Passer à l'actualité</a></li>
....
</ul>

Vous devrez respecter une uniformité dans la manière de présenter ces liens, ce sera soit "passer la section x ou y" soit "passer à la section x ou y" mais jamais un mélange des deux formules !

De même l'implémentation d'un lien d'évitement "générique" par exemple "passez à la section suivante" est fortement déconseillée : ces liens ne seront pas explicites et donc difficiles d'utilisation, notamment pour les utilisateurs de lecteurs d'écran.

Enfin, inutile d'implémenter des raccourcis clavier sur ces liens car ils vont être utilisés au fil de l'eau.

Attention cependant à la maintenance nécessaire pour les liens d'évitement : n'oubliez pas qu'il s'agit de liens contextuels, susceptibles de changer d'intitulé et de cible en fonction de chaque page, notamment en cas de modification du contenu. De fait, ils peuvent finir par poser un problème similaire à la maintenance des attributs tabindex, ce qui nécessite un "suivi" de leur implémentation.

5.2- Les liens d'accès rapide :

Ce sont les rois des liens d'aide à la navigation dans la page; leur usage commence à rentrer dans les moeurs et c'est une excellente chose.

Ils doivent se plier à un certain nombre de règles :

- Vous devez en limiter le nombre et l'usage : Il ne s'agit surtout pas de construire un sommaire de la page (nous reviendrons plus bas sur les relations entre ces deux mécanismes). Généralement, en fonction de la structure du haut de la page, une paire de liens d'accès rapide comme "aller au contenu" et "aller au menu" suffit pour qu'ils remplissent parfaitement leur office. Contentez-vous de pointer sur l'essentiel, posez-vous la question de savoir s'il est vraiment utile d'implémenter un lien "aller à la recherche" si votre formulaire de recherche ne se trouve qu'à 3 ou 4 tabulations de là.

Finalement, vous allez implémenter quelque chose du genre :

<ul>
 <li><a href="#menu">Menu</a></li>
 <li><a href="#contenu">Contenu</a></li>
 <li><a href="#recherche">Recherche</a></li> (Si c'est vraiment nécessaire)
</ul>

4 ou 5 liens est la limite au delà de laquelle il faut s'alerter sur le bien fondé de la construction de cette liste. Cela ne signifie pas qu’il ne faut jamais dépasser 5 liens d’accès rapide mais qu’il faut simplement avoir une bonne raison de le faire…

Vous pouvez, en revanche, compléter ponctuellement cette liste s'il est nécessaire de pointer une région particulière de la page, par exemple, une vidéo embarquée ou un formulaire de saisie.

Certains considèrent que le doublement des liens "menu" et "contenu" est redondant et que la simple utilisation d'un lien d'évitement "passer le menu" suffit. C'est un peu vrai et un peu faux, en particulier dans le cas où ces liens sont équipés de raccourcis clavier, ce qui est toujours une bonne idée, même si on connait les limitations de l'utilisation de accesskey.

- Laissez-les toujours à la même place dans vos pages. Il n'y à qu'une seule place intelligente : en haut du code, avant ou après le titre principal de la page, peu importe.

- Ne les cachez pas ! Si il y a une chose à retenir de ces liens, c'est bien celle-ci : de grâce, laissez-les visibles. Il n'y a rien de pire que des liens d'accès rapide cachés par CSS, quelle qu'en soit la méthode, pour trois raisons importantes au moins :

• Les utilisateurs de lecteurs d'écran ont leurs propres fonctionnalités qui permettent de naviguer de titre en titre ou de section en section. Le gain des liens d'accès rapide pour cette catégorie d'utilisateurs est donc peu évident.
• Des liens d'accès rapide cachés par CSS provoquent une grave rupture de navigation dans la page pour les utilisateurs de la navigation clavier. En effet, bien que cachés, ces liens continuent à réagir au focus de la tabulation, ce qui est particulièrement gênant.
• Enfin, ils sont généralement la seule véritable aide que l'on peut implémenter pour ces utilisateurs.

5.3- Les liens de navigation interne :

Cela ne concerne, en général, que le lien "retour en haut de page".

Il est également implémenté dans le code de la page, à intervalles réguliers, et permet simplement de revenir en haut de page, plus précisément au premier contenu de la page.

Vous trouverez beaucoup d'implémentations de ce lien qui se contentent d'utiliser l'élément body comme cible :

<body id="top">
<a href="#top">retour en haut de page</a>

Ne faites jamais ça ! Pour les raisons expliquées plus haut (2. méthode générales d'implémentation), cela rendra inopérant son utilisation pour la navigation clavier sous IE. Utilisez comme cible un vrai lien <a>; par exemple, juste avant les liens d'accès rapide, de cette manière, vous serez certain que le retour en haut de page sera synchronisé avec la tabulation.

Implémentez ces liens de retour en haut de page à bon escient de manière régulière et toujours à la même place. Accessiweb recommande d'en utiliser dés lors que la page fait plus de trois écrans en résolution 1024.

D'autres liens de navigation interne peuvent être utilisés : dans le cas de listes de liens particulièrement longues, il peut être intéressant d'avoir régulièrement des liens " retour au début de la liste …". Ces liens s'apparentent fortement aux liens d'évitement même si, en l'occurence, il ne s'agit pas d'éviter mais de "revenir". Il faut en limiter l'usage au strict nécessaire pour ne pas surcharger la page.

6- La question épineuse de l'intégration graphique

Généralement, les designers ou les clients détestent ces liens vécus comme une insupportable contrainte en terme de design.

Il n'y a pas de réponse toute faite; deux compromis s'offrent à vous :

6.1- Liens semi-visibles :

Cette technique est à réserver exclusivement aux seuls liens d'accès rapide; ne l'employez surtout pas pour les liens d'évitement et de navigation interne car elle aura un effet très pertubant.

La technique est simple à comprendre : il s'agit de cacher les liens et les faire apparaître au survol, au moyen de CSS.

Vous pouvez les cacher en leur attribuant une couleur de police identique à celle de la couleur de fond ou en les rejetant en dehors de la zone d'affichage avec une technique comme celle de Paul Bohman.

Le plus important est de ne surtout pas oublier de traiter, pour les faire réapparaitrent, les deux événements : hover (souris) et focus (tabulation) :

a.aide:hover, a.aide:focus{
 color:#000;
}

Certains, comme Mike Cherim (accessites.org) poussent la logique jusqu'à habiller ces liens et la méthode d'apparition.

Ce compromis, s'il est satisfaisant du point de vue de l'intégration graphique, pose néanmoins un problème : on ne sait pas que les liens existent au chargement de la page et leur apparition/disparition peut être pertubante. Quoi qu’il en soit, si c’est la seule solution à votre portée, utilisez là sans état d’âme, toute considération de confort mis à part, l’essentiel sera préservé.

6.2- Liens iconographiques :

Vous pouvez également décider de les intégrer dans le graphisme en employant des images iconographiques.

<a href="#top" title="retour en haut de page"><img src="top.gif" width="10" height="10" alt="retour en haut de page" /></a>

Cette technique est très élégante et valorisante pour les designers, bien acceptée par les clients; elle fonctionne très bien pour les utilisateurs de lecteurs d'écran. Oui.. mais... elle pose un redoutable problème, comme d'habitude, si j'ose dire, pour les utilisateurs de la tabulation clavier : malheureusement, l'affichage du title d'un lien ne réagit que sur l'événement "hover", ce qui signifie qu'un utilisateur de la navigation clavier ne verra pas s'afficher le title et ignorera la fonction du lien.

Vous n'avez pas beaucoup de solutions à votre disposition :

- Vous trouvez des icones suffisamment explicites : Une petite maison ou une flèche vers le haut est généralement bien compris pour le lien "retour en haut de page". De même, une "flèche droite" pourrait être envisagée pour les liens d'évitement. En revanche, pour les liens aller au "menu/contenu", il serait fort étonnant que vous trouviez une iconographie universellement reconnue.

- Vous implémentez une méthode pour informer visuellement l’utilisateur de la fonction du lien. Je vous en propose deux :

1. La méthode javascript consiste à reprendre le contenu de l’attribut title du lien et l’insérer dans un élément créé dynamiquement.

Les méthodes de l’objet node nous fournissent le moyen de le faire proprement : pour javascript il faut deux fonctions que vous pouvez implémenter dans le head de la page.

function showTitle(elm){
 if(document.createElement){
    span=document.createElement("span");
    txt=document.createTextNode(elm.getAttribute("title"));
    span.appendChild(txt);
    span.className="tooltip";
    elm.appendChild(span);	
 }
}
function hideTitle(elm){
   elm.removeChild(elm.lastChild);
}

Associées à une classe CSS :

.tooltip {
    display:block;
    font-size:0.9em;
    width:8em;
    color:#4b4b4b;
    position:relative;
    margin:-15px 0 0 5px;
    padding:3px;
    background-color:#fffff4;
    border:1px solid #cacaca;
    text-decoration:none;
  }

Et pour le html, les deux appels de fonctions sur les événements focus et blur :

[code] <a href="#" title="Ceci est un essai" onfocus="showTitle(this)" onblur="hideTitle(this)"><img src="icn_recherche.gif" alt="ceci est un essai" width="17" height="17" /></a> [/code]

Ce qui nous donne en pratique :

Rien ne vous empêche d’externaliser ces fonctions et surtout de traiter les événements focus et blur avec une routine d’initialisation afin de préserver un code html propre.

Cette méthode est avantageuse car elle ne s’appuie que sur du contenu existant, elle fonctionne bien sur la plupart des navigateurs (IE5+, Gecko, Opera…). Oui mais voilà, pas de javascript, pas de bulle d’aide !

2. La seconde méthode est 100% CSS :

Elle nécessite l’implémentation d’un élément qui va reprendre le contenu de l’attribut title.

Du point de vue de l’accessibilité ce n’est pas formidable, le risque est important de provoquer une double lecture du lien par les lecteurs d’écran. Nous verrons plus bas comment tenter de contourner ce problème, intéressons nous pour l’heure à la technique d’implémentation :

Pour le html, nous rajoutons un élément span associé à deux classes et une classe alternative pour IE, qui ne comprends pas la pseudo-classe focus pour les liens (ce qui est proprement scandaleux) :

<a href="#summary" accesskey="4"  title="Aller à la recherche"><img src="icn_recherche.gif" alt="Aller à la recherche" width="17" height="17" /><span class="hidden">Aller à la recherche </span></a>

La classe CSS pour cacher par défaut la bulle d’aide (version Paul Bohman) :

.hidden {
   position:absolute;
   left:0;
   margin-top:-1000px;
   width:1px;
   height:1px;
   overflow:hidden;
}

La classe CSS pour faire apparaitre la bulle d’aide en s’appuyant sur un simple sélecteur enfant :

a:focus span.hidden {
    display:block;
    font-size:0.9em;
    width:8em;
    height:1em;
    color:#4b4b4b;
    position:relative;
    margin:-15px 0 0 5px;
    padding:3px;
    background-color:#fffff4;
    border:1px solid #cacaca;
    text-decoration:none;

Pour IE nous utiliserons une classe appelée avec un commentaire conditionnel en utilisant la pseudo-classe active qui, bug de circonstance, produira le même effet :

a:active span.hidden { … }

Le résultat est plus robuste que la méthode javascript pour plusieurs raisons :

• Cela fonctionne tout le temps
• Lorsque CSS est désactivé, le texte du span supplémentaire apparaît à coté de l’icône ce qui est particulièrement utile !

En revanche, comme nous l’avons dit, le risque existe de provoquer une double lecture par les lecteurs d’écran. Pour contourner ce problème nous allons utiliser un comportement habituel de ces aides techniques.

La plupart d’entres elles restitue en effet le texte le plus long qu’elles vont trouver entre le title, le alt et le contenu. Il nous suffit donc de créer un texte de title plus long que le contenu du span pour assurer au mieux qu’il sera le seul contenu restitué pour le lien. En passant, et comme je suis sur que vous aimez le travail bien fait, n’oubliez pas que les images sont toujours susceptibles d’être désactivées; Lorsque ce sera le cas, c’est le contenu de l’attribut alt qui sera affiché. Donc contentez vous d’un simple mot, ce sera suffisant à la compréhension et limitera les risques de superposition en mode "images désactivées".

Au final, notre lien html devra ressembler à ceci :

 <a href="#summary" accesskey="4"  title="Aller à la recherche"><img  src="icn_recherche.gif" alt="Rechercher" width="17" height="17" /><span  class="hidden">Rechercher </span></a>

Le contenu long de title sera restitué en priorité par les lecteurs d’ écrans, le alt sera suffisamment court pour être lisible en mode "images désactivées" et le span assurera la bulle d’aide pour la navigation clavier. Cette méthode à été testée avec succès avec les principaux lecteurs d’écrans, notamment jaws et window eyes.

Le seul petit soucis concerne la restitution sur les navigateurs en mode texte qui afficheront, impertubablement les deux textes (le alt et le span). Il n’y à malheureusement pas de solution, mais ce défaut me semble acceptable eu égard aux bénéfices pour la navigation clavier.

Vous pouvez voir ce dispositif en action sur webonorme.

Pour en terminer sur le chapitre des icones : n'oubliez pas de décrire dans votre page d'aide, la fonction de chacune des icones; ce qui viendra parfaire le dispositif.

7- Relation entre les liens d’aide à la navigation dans la page et un sommaire

Avant d’en terminer avec ce tour d’horizon, je voudrais vous dire un mot sur la problématique associée à l’utilisation simultanée de ces liens et d’un sommaire ou d’une TOC (Table of Content).

La nécessité d’implémenter un sommaire ou une TOC est plutôt réservé à certains usages comme la publication en ligne d’une documentation technique ou d’une spécification, à l’image des sommaires du W3C par exemple. On peut également être amené à implémenter une TOC en tête d’un contenu volumineux ou comprenant beaucoup de liens.

Il n’y à pas d’opposition majeure à l’utilisation simultanée de ces deux mécanismes à la condition de garder à l’esprit un certain nombre de point :

• Un sommaire ou une TOC ne sont pas des aides : l’objectif n’est pas de faciliter la navigation mais bien de décrire la structure d’un contenu, d’en donner une vision globale et les moyens d’utiliser efficacement le contenu.
• L’implémentation de liens d’aides à la navigation doit, encore plus que dans le cas d’un site web classique, être envisagée avec comme seul objectif de soutenir la navigation au moyen du sommaire ou de la TOC.
• Un utilisateur aura naturellement tendance à vouloir revenir en permanence au sommaire pour naviguer, il faut alors privilégier, par exemple, le lien de navigation interne "retour en haut de page".
• De même, si vous avez la présence simultanée d’un sommaire et d’un menu de navigation assurez vous que l’utilisateur aura les moyens d’aller rapidement au sommaire, au menu ou au contenu. L’objectif est que les deux mécanisme se complètent tout en évitant qu’ils ne viennent que s’ajouter l’un à l’autre ce qui aurait pour effet de compliquer exagérément la navigation.

8- Conclusion

Ce sujet des liens d'aide à la navigation dans la page est plus riche qu'il n'y paraît de prime abord. Retenez ceci :

• Ne chargez pas votre page en systématisant l'usage de ces liens : privilégiez la simplicité et la sobriété.
• Portez une attention particulière à leur dénomination : essayer de l'uniformiser et tenez-vous y; il n'y a rien de pire que le mélange des genres.
• Ne les cachez surtout pas !
• Si vous traitez ces liens sous forme d’icone, fournissez un moyen crédible d'informer de leur fonction l'utilisateur de la navigation clavier.
• Si vous utilisez simultanément un sommaire ou une TOC, posez vous la question de l’interaction entre les deux mécanismes : Ils doivent être complémentaires et privilégier l’accès au sommaire ou à la TOC.

Pour finir, voici ce que dit Gez Lemond au sujet de l'intégration des liens d'évitements au design, ce qui reste l'un des principaux freins à leur généralisation : Ce n'est pas impossible pour un bon designer d'intégrer des liens d'évitement visibles qui répondent aux attentes des utilisateurs, sans pour autant desservir le design, cela demande juste d'être créatif et d'avoir l'esprit ouvert.

Transmis à tous les "bons designers" et intégrateurs qui auront eu le courage de lire ce billet jusqu'ici...

Pour en savoir plus :

• WCAG 1.0 – Techniques Html – 6.2 Grouping and bypassing links (en)
• Plongez dans l'accessibilité - Jour 11 - Eviter les liens de navigation
• Guide AccessiWeb - Fiche 12.4 : Y a-t-il des liens facilitant la navigation dans la page ?
• Accessites - Skip Link Pros and Cons (en)
• Jim Tatcher - Skip Navigation Links(en)