WordPress et accessibilité : faciliter la navigation (1re partie)

Au printemps, je publiais un premier article consacré à l’accessibilité des thèmes WordPress : WordPress et accessibilité : bien structurer les modèles de pages de son thème.

Il y a 15 jours, je suis intervenue à BlendWebMix pour donner une nouvelle conférence sur ce sujet qui me tient à cœur. Vous pouvez d’ailleurs consulter mes slides : Comment améliorer l’accessibilité de votre thème WordPress ?

Cela m’amène aujourd’hui à commencer le deuxième chapitre de cette série d’articles sur WordPress, pour creuser davantage les points que j’aborde à l’oral pendant mes conférences ou notre formation design et accessibilité.

Cette fois-ci, intéressons-nous à une problématique UX particulièrement cruciale : la navigation.

Pour rendre accessible la navigation des thèmes WordPress, il y a plusieurs points à implémenter ou à vérifier :

1. fournir au moins un lien d’accès rapide vers le contenu du site ;
2. assurer un ordre de tabulation cohérent ;
3. dans un menu, lorsqu’un item est indiqué comme actif, donner une alternative à cette indication visuelle ;
4. prévoir deux systèmes de navigation au moins ;
5. s’assurer que le formulaire de recherche est accessible ;
6. structurer le contenu avec des titres pertinents.

Dans cette première partie, je vais expliquer les points 1 à 3. Dans la seconde partie, j’aborderai les points 4 à 6.

1/ Liens d’accès rapide (aussi appelés liens d’évitement)

Sans doute avez-vous déjà croisé des liens d’accès rapide lors de votre navigation sur le web : on les appelle aussi « liens d’évitement ».

Dans le nouveau thème par défaut de WordPress, Twenty Twenty, un lien d’accès rapide est bien prévu : il a pour intitulé « Skip to content », et apparaît à la première tabulation (touche Tab), en haut à gauche de l’écran.

C’était déjà le cas sur Twenty Nineteen, le thème précédent.

Les liens d’accès rapide permettent principalement aux utilisateurs qui naviguent exclusivement au clavier de contourner des zones redondantes d’une page à l’autre, grâce à des ancres.

Ainsi, les liens d’accès rapide vont servir principalement :

• aux personnes handicapées moteur qui ne peuvent pas se servir d’une souris (navigation clavier ou switch) ;
• aux personnes très malvoyantes (loupe d’écran vocalisée + clavier) ;
• dans une moindre mesure, aux personnes aveugles (lecteur d’écran + clavier), en particulier aux personnes aveugles novices ^[1] dans le maniement de leur lecteur d’écran : les utilisateurs experts quant à eux semblent plutôt utiliser les raccourcis claviers fournis par leur lecteur d’écran pour accéder directement à l’élément voulu.

Au moins un lien d’accès rapide au contenu principal

Pour permettre à tous ces utilisateurs de naviguer sur votre thème WordPress facilement, prévoyez au moins un lien d’accès rapide au contenu principal.

Si votre thème WordPress prévoit beaucoup de contenu avant le menu de navigation principal ou avant le formulaire de recherche, alors vous pouvez ajouter un lien d’accès rapide vers chacun d’entre eux, là encore pour permettre aux utilisateurs d’y accéder rapidement.

Cas particulier : un lien d’accès rapide peut être inutile lorsque le site web est constitué d’une seule page. Mais c’est une information qu’on a rarement au moment de la conception d’un thème WordPress. C’est pourquoi, dans le doute, je vous conseille d’en prévoir un malgré tout, et de laisser la possibilité aux utilisateurs de votre thème de le désactiver éventuellement.

Position des liens d’accès rapide

Côté code, il est important que les liens d’accès rapide soient placés au début du DOM : assurez-vous qu’il s’agisse des premiers éléments situés au début de la balise .

De même, veillez à ce que les liens d’accès rapide soient situés à la même place d’une page à l’autre, et qu’ils se présentent toujours dans le même ordre relatif dans le code source.

Priorité du bandeau de cookies par rapport aux liens d’accès rapide dans le DOM

À noter : si votre thème WordPress prévoit l’affichage d’un bandeau de cookies, il vaut mieux que celui-ci soit présent dans le code avant les liens d’accès rapide.

En effet, il est important que l’utilisateur ou l’utilisatrice prenne conscience des conditions de consultation du site avant de commencer à le consulter.

De la même manière, n’insérez pas le bandeau de cookies tout à la fin du DOM : une personne aveugle utilisant votre site avec un lecteur d’écran pourrait ne jamais le lire et donc ne jamais avoir conscience de la politique de confidentialité de votre site.

Apparence des liens d’accès rapide

Du point de vue design, vous avez deux solutions pour présenter les liens d’accès rapide :

• soit les afficher en permanence à l’écran, dans l’en-tête du site ;
• soit les masquer de manière accessible, et ne les révéler que lorsque l’utilisateur commence à tabuler dans la page.

Liens d’accès rapide toujours visibles

En réalité, il vaut mieux que les liens d’accès rapide soient toujours visibles à l’écran.

En effet, ces liens servent en priorité à des personnes ayant un handicap moteur qui naviguent au clavier, certes, mais qui voient très bien ce qui se passent à l’écran.

De même, une personne malvoyante ayant recours à une loupe d’écran va lire l’écran séquentiellement de gauche à droite. Il vaut mieux dans ce cas que vos liens d’accès rapide soient visibles pour qu’elle puisse se repérer facilement et accéder rapidement au contenu principal de la page, plutôt que de la laisser explorer le site, morceau par morceau.

En revanche, comme je l’évoquais, les liens d’accès rapide servent a priori moins aux personnes aveugles, car elles ont plutôt l’habitude d’utiliser les raccourcis spécifiques fournis par leur lecteur d’écran pour naviguer. J’ai détaillé ce point dans mon précédent article : WordPress et accessibilité : bien structurer les modèles de pages de son thème.

Liens d’accès rapide masqués par défaut et révélés à la tabulation

Si afficher les liens d’accès rapide en permanence n’est pas possible, alors il est également possible de les masquer visuellement hors écran, à condition de les faire réapparaître à la prise de focus.

Ce comportement peut être pratique dans deux cas :

1. vous avez plusieurs liens d’accès rapide et ils prennent beaucoup de place ;
2. l’en-tête de votre thème WordPress ne dispose pas d’espace suffisant pour caser vos liens d’accès rapide, en particulier si vous corrigez un thème WordPress créé par quelqu’un qui n’a pas pris en compte ce besoin utilisateur.

C’est le choix qui a été fait sur le thème officiel de WordPress, Twenty Twenty, ainsi que sur son prédécesseur.

Ainsi, pour masquer les liens d’accès rapide visuellement hors écran, vous pouvez utiliser une méthode CSS accessible comme les classes CSS .sr-only et .sr-only-focusable ou la classe .screen-reader-text utilisée dans les thèmes officiels WordPress, par exemple.

Ces deux classes CSS permettent de masquer l’élément hors écran, tout en le laissant accessible aux lecteurs d’écran, par opposition aux méthodes radicales comme display:none ou visibility:hidden, qui rendent l’élément invisible et inaccessible aux lecteurs d’écran.

La classe .sr-only-focusable quant à elle permet de faire apparaître l’élément .sr-only lorsqu’il prend le focus, qui reste ainsi atteignable et actionnable au clavier.

<ul>
 <li>
   <a href=”#content” class=”sr-only sr-only-focusable”>
     <?php _e('Skip to content', 'textdomain'); ?>
   </a>
 </li>
</ul>

Voir une démonstration du fonctionnement.

Dans le code ci-dessous, j’ai utilisé la fonction _e() afin de pouvoir traduire l’intitulé du lien.

C’est important pour que les personnes qui vont accéder à ce lien avec un lecteur d’écran comprennent de quoi il s’agit. Or on a souvent tendance à oublier de traduire cet élément lorsqu’il est masqué par défaut…

Si vous copiez le code ci-dessus, n’oubliez pas de remplacer textdomain par le textdomain de votre thème (par exemple : twentytwenty).

Piège à éviter

Pour masquer les liens d’accès rapide, n’utilisez surtout pas de propriétés CSS qui les rendraient inactifs, telles que :

• display: none;
• visibility: hidden;
• width: 0;height: 0;
• font-size: 0;
• attribut HTML5 hidden
• propriété aria-hidden="true"

Comme dit, utilisez à la place une méthode CSS accessible comme .sr-only ou .screen-reader-text. J’insiste parce que c’est important ! 😉

Faciliter la prise de focus dans les vieux navigateurs

Enfin, bien que cela ne soit pas une exigence du RGAA 4 (Référentiel général d’amélioration de l’accessibilité), je vous recommande d’ajouter un attribut tabindex="-1" sur les cibles de vos liens d’accès rapide.

En effet, lorsqu’il est négatif, l’attribut tabindex permet de déclarer un élément HTML non interactif comme pouvant recevoir le focus (par exemple via une ancre ou via JavaScript), tout en étant exclu du parcours de tabulation.

Par exemple :

<main id="content" tabindex="-1">…</main>

En effet, cela corrige un bug dans de vieux navigateurs (dont Internet Explorer, y compris la version 11) qui ne déplacent pas le focus sur les ancres n’étant pas nativement des éléments interactifs.

À noter : il y a un bug sous Firefox pour Android lorsque l’on utilise tabindex="-1" sur la cible des liens d’accès rapide. Quand on active le lien contenu, le focus se place sur le conteneur de la page HTML a priori, et non sur la cible en question.

C’est un bug isolé qui ne doit pas vous empêcher d’améliorer l’expérience pour toutes les autres configurations navigateur + système d’exploitation (OS). Sur Chrome, qui est le navigateur référencé dans l’environnement de test RGAA 4 ^[2], le bug ne se produit pas.

Ce qui va se passer si vous oubliez l’attribut tabindex="-1" sur la cible des liens d’accès rapide 

Si vous ajoutez un attribut id sur la balise main , que vous faites un lien vers cet id depuis un lien d’accès rapide, mais que la balise main n’a pas d’attribut tabindex="-1" :

• le vieux navigateur fera bien défiler la page, et l’utilisateur verra bien le contenu remonter en haut de la fenêtre ;
• mais lorsque l’utilisateur tabulera, il reprendra le parcours à partir du lien d’accès rapide, et non pas depuis le début de la zone ciblée. ^[3]

Références

• RGAA 4 : Critère 12.7 Dans chaque page web, un lien d’évitement ou d’accès rapide à la zone de contenu principal est-il présent (hors cas particuliers) ?
• WCAG 2.1 : Understanding Success Criterion 2.4.1: Bypass Blocks

2/ Ordre de tabulation

L’ordre de tabulation est un autre point important à vérifier pour l’accessibilité de votre thème.

Quand vous développez ou testez un thème WordPress, prenez l’habitude de le tester en naviguant uniquement au clavier, sans utiliser du tout votre souris ou votre trackpad.

Utilisez :

• la touche Tab de votre clavier pour accéder à l’élément interactif suivant (c’est de là que vient le verbe « tabuler » : on dit que l’utilisateur « tabule », c’est-à-dire qu’il déplace le focus dans une page web en utilisant la touche Tab de son clavier) ;
• les touches Shift+Tab pour accéder à l’élément interactif précédent.

Par « élément interactif », on entend tous les éléments qui peuvent prendre le focus, c’est-à-dire avec lesquels l’utilisateur peut interagir : liens et boutons principalement, mais également les éléments ayant un attribut tabindex.

Points à vérifier

L’ordre de tabulation doit être cohérent

L’ordre de tabulation est l’ordre dans lequel le focus se déplace d’un élément interactif à un autre.

Par défaut, l’ordre de tabulation correspond à l’ordre de succession des éléments dans le DOM. En tabulant, l’utilisateur va donc se déplacer successivement d’élément interactif en élément interactif, en parcourant ainsi la page web du début à la fin.

Aussi, dans votre thème, vérifiez si l’ordre de tabulation est cohérent, c’est-à-dire s’il suit un ordre de lecture à peu près logique ^[4].

C’est un point d’accessibilité très important pour les personnes qui naviguent au clavier, c’est-à-dire les personnes aveugles ou malvoyantes, ainsi que certaines personnes handicapées moteur, principalement.

Si votre thème est affiché dans une langue qui se lit de droite à gauche (RTL – right to left), l’ordre de tabulation doit également être cohérent avec cette orientation.

Il ne doit pas y avoir de « pièges au clavier »

Repérez s’il y a des pièges au clavier, c’est-à-dire des endroits où vous arrivez à tabuler mais dont vous ne pouvez plus ressortir en utilisant uniquement la touche Tab.

Dans le cas d’un piège au clavier, les personnes handicapées moteurs seront dans l’incapacité de quitter l’élément en cours de consultation, et seront contraintes de quitter le navigateur pour retrouver le contrôle du curseur.

À noter : il se peut que vous ayez besoin d’activer certaines options de votre navigateur et/ou de votre OS pour pouvoir parcourir les pages en tabulant. Par exemple, j’explique comment activer la prise de focus dans Firefox et Safari sur MacOS sur mon blog.

Références

• RGAA 4 :
  • Critère 12.8 Dans chaque page web, l’ordre de tabulation est-il cohérent ?
  • Critère 12.9 Dans chaque page web, la navigation ne doit pas contenir de piège au clavier. Cette règle est-elle respectée ?
• WCAG 2.1 :
  • Success Criterion 2.1.1 Keyboard (A – simple A)
  • Success Criterion 2.1.2 No keyboard Trap (A – simple A)

3/ Item de menu actif dans les menus de navigation

Dans les menus de navigation, il est d’usage de dissocier visuellement l’élément actif des autres éléments.

WordPress ajoute automatiquement des classes CSS aux menus de navigation en fonction du type de l’item actif, afin que vous puissiez le styler et le différencier des éléments inactifs :

• .current_page_item ;
• .current-post-ancestor ;
• .current-menu-item ;
• .current-menu-parent ;
• .current-menu-ancestor ;
• .current_page_parent.

Tout cela est super, sauf qu’il faut le rendre accessible : en effet, une personne déficiente visuelle ne va pas forcément bien percevoir le style de l’élément actif par rapport aux autres (en particulier si vous utilisez les couleurs verte ou rouge, qui posent des soucis en particulièrement aux personnes daltoniennes).

De plus, une personne aveugle ne perçoit pas du tout les styles de la page, donc elle ne saura pas le distinguer non plus si aucune alternative à cette indication visuelle n’est prévue.

Solutions

Aussi, si vous dissociez visuellement l’item actif des autres items, pensez également à indiquer dans le code HTML du menu que tel élément est actif, en plus de sa classe CSS spécifique.

Pour faire ça, la solution qui couvre le plus de cas utilisateurs est la suivante :

• côté HTML : ajouter un attribut title sur l’élément actif, sur le modèle suivant : title="<Intitulé de l’item> – page active". Par exemple : Accueil. L’attribut title va générer une infobulle qui s’affichera lorsque l’utilisateur ou l’utilisatrice survolera quelques instants le lien ;
• côté design : compléter l’éventuel changement de couleur de texte et/ou d’arrière-plan en ajoutant une forme adjacente au lien, par exemple une icône ou un souligné, afin d’indiquer la page active aux utilisateurs qui perçoivent mal ou pas les contrastes de couleurs.

À noter qu’il serait également possible d’ajouter un texte masqué hors écran dans l’intitulé de l’item actif :

<ul>
 <li class="menu-item current-menu-item">
   <a href="https://example.com">Accueil<span class="sr-only"> – page active</span></a>
 </li>
 <li class="menu-item">
   <a href="https://example.com/portfolio">Portfolio</a>
 </li>
 …
</ul>

Cet intitulé, masqué proprement avec CSS comme on l’a vu précédemment, sera bien restitué par les lecteurs d’écran.

Par contre, rebelote, assurez-vous d’ajouter une forme adjacente au lien (une icône ou un souligné par exemple), pour permettre aux personnes qui perçoivent mal les couleurs et qui n’utilisent pas de lecteur d’écran de bien repérer où se situe l’élément actif.

J’ai écrit une fonction PHP pour ajouter le texte masqué dans un menu WordPress. Vous pouvez la copier et la coller dans le fichier functions.php de votre thème. À noter que vous pouvez très bien modifier cette fonction pour générer un title plutôt qu’un texte masqué hors écran.

À noter : dans WordPress, par défaut, l’item actif est toujours un lien, même quand on se trouve déjà sur la page à laquelle mène ce lien.

Références

• RGAA 4 :
  • Critère 3.1 Dans chaque page web, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?
  • Critère 10.9 Dans chaque page web, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle respectée ?
  • Critère 10.10 Dans chaque page web, l’information ne doit pas être donnée par la forme, taille ou position uniquement. Cette règle est-elle implémentée de façon pertinente ?
• RGAA 3 :
  • Critère 12.12 Dans chaque page web, la page en cours de consultation est-elle indiquée dans le menu de navigation ? (AAA – triple A)
• WCAG 2.1 :
  • Success Criterion 1.3.1 Info and Relationship (A – simple A)
  • Success Criterion 1.4.1 Use of Color (A – simple A)
  • Success Criterion 2.4.8 Location (AAA) (AAA – triple A)

Conclusion

Dans ce premier article, nous avons vu plusieurs façons de rendre la navigation au sein de votre thème WordPress plus accessible pour les personnes handicapées :

1. les liens d’accès rapide : il en faut toujours au minimum un, qui mène au contenu principal ;
2. l’ordre de tabulation : il doit être cohérent. De plus, le site ne doit pas présenter de piège au clavier ;
3. l’alternative à la mise en forme de l’item actif dans un menu, pour que cette information soit également accessible aux personnes déficientes visuelles et aveugles.

Dans la seconde partie de cet article, qui sera publié prochainement, nous verrons ensemble d’autres méthodes de navigation qui nécessitent un soin tout particulier : la présence d’au moins deux systèmes de navigation, le formulaire de recherche, ainsi que l’utilisation des titres dans la page (balises title, h1, h2, etc.).

Suivez Access42 sur Twitter et/ou sur LinkedIn pour ne rien manquer ! 😊