Découverte de la navigation accessible

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

• Répertorier les stratégies destinées à fournir aux utilisateurs des informations de navigation et d’action
• Expliquer l’importance de la gestion du focus dans le développement d’applications Web

Introduction

Un utilisateur devrait toujours savoir où il se trouve dans une application et les actions qu’il peut entreprendre. Fournissez aux utilisateurs des informations sur la navigation et les actions en :

• utilisant des éléments de navigation cohérents ;
• appliquant une imbrication et un ordre des titres appropriés ;
• étiquetant des régions repère ;
• utilisant un ordre d’onglets logique qui correspond à l’ordre de lecture (c’est-à-dire de gauche à droite et de haut en bas pour les langues se lisant de gauche à droite, et de droite à gauche pour les langues se lisant de droite à gauche) ;
• utilisant des indicateurs de focus visibles pour tous les éléments interactifs.

Changements de contexte

En ce qui concerne les changements de contexte, tenez compte des règles générales suivantes :

1. l’utilisateur doit s’attendre à un changement de contexte, soit parce qu’il l’a demandé, soit parce qu’il a été averti qu’un changement allait se produire ;
2. une fois le changement effectué, l’utilisateur doit savoir où il se trouve sur une page.

Pensez au bouton Afficher plus dans la barre de navigation de rapports et de dossiers. 

Lorsqu’un utilisateur clique sur Afficher plus, vous disposez de plusieurs options pour lui présenter le nouveau contenu.

1. Vous pourriez appliquer le focus sur le premier élément du nouveau contenu. S’agit-il de la meilleure option ? Potentiellement, mais les boutons indiquent Afficher plus et non Accéder à plus.
2. Vous pouvez utiliser une région aria-live pour annoncer aux lecteurs d’écran que d’autres éléments de navigation ont été ajoutés à la page.
3. Vous pouvez modifier le texte du bouton pour qu’il indique Afficher moins. Il s’agit de la meilleure option, car le succès de l’utilisateur est implicite dans le nouveau texte du bouton : « Je peux réduire l’affichage, puisqu’il est actuellement développé. »

La question que se pose désormais un utilisateur de lecteur d’écran est  : « Où se trouve le "plus" dont j’ai été averti ? » En plaçant le nouveau contenu juste devant les yeux de l’utilisateur, la réponse à cette question est plutôt claire.

Dans certains cas d’utilisation, déplacer le focus d’un utilisateur ou utiliser une région aria-live est une solution adéquate. Identifier la technique à utiliser dans une situation donnée revient à cibler les attentes de l’utilisateur. 

Par exemple, imaginez un bouton Modifier qui ouvre une boîte de dialogue. 

Le bouton Modifier sera masqué par la boîte de dialogue dès que l’utilisateur clique dessus, il n’est donc pas logique de garder le focus sur le bouton. Ici, nous déplaçons le focus sur la boîte de dialogue. En règle générale, vous ne devez jamais déplacer le focus d’un utilisateur, à moins que l’utilisateur n’ait explicitement entrepris une action. Dans ce cas, le focus doit naturellement se déplacer vers la fenêtre de modification lorsque l’utilisateur clique sur Modifier.

Il est également important de déplacer le focus de manière logique lorsque l’utilisateur entreprend une action sur un élément et que cet élément disparaît. Poursuivons avec cet exemple. Quel devrait être le focus de l’utilisateur une fois la boîte de dialogue fermée ? Le focus doit être activé sur un élément, et pas seulement sur le haut de la page. Une possibilité logique, dans ce cas, est de revenir au bouton Modifier qui a initialement ouvert la boîte de dialogue. 

Pour en savoir plus sur les changements de contexte, y compris les régions aria-live, reportez-vous à la section Ressources ci-dessous.

Gestion du focus

Une bonne gestion du focus est l’un des facteurs clés du développement d’applications Web accessibles. En général, les utilisateurs peuvent déplacer le focus sur une page en appuyant sur le bouton de tabulation pour avancer et descendre dans la page et sur Maj+tabulation pour revenir en arrière et remonter dans la page. Cela s’applique aux éléments HTML qui reçoivent automatiquement le focus, tels que les ancrages, les boutons et les contrôles de formulaire.

Les composants complexes, comme les grilles interactives, les menus, les zones de liste déroulante et les ensembles d’onglets sont parcourus à l’aide des touches fléchées. La programmation de ces interactions avancées fait partie de la promesse que vous faites aux utilisateurs lorsque vous utilisez les attributs de rôle ARIA.

Passons maintenant à la gestion du focus lorsque le contexte d’un utilisateur change. Qu’advient-il du focus d’un utilisateur lorsqu’il : 

• navigue vers une nouvelle page ?
• ouvre ou ferme une boîte de dialogue ?
• supprime un enregistrement ?
• effectue une opération de glisser-déposer ?

Les réponses à ces questions et à bien d’autres se trouvent dans les recommandations générales sur le focus de SLDS. 

Au-delà de ces recommandations, tenez compte des éléments suivants :

1. Les utilisateurs en situation de handicap, notamment les utilisateurs aveugles, naviguent généralement vers le bas de la page lorsqu’ils interagissent avec une application. Si votre conception introduit un nouveau contenu sur la page, assurez-vous que ce dernier est ajouté devant l’élément qui a déclenché la modification. Par exemple, lorsque l’utilisateur clique sur un bouton qui affiche un formulaire intégré à la page, celui-ci doit se trouver après le bouton dans l’ordre du DOM. L’utilisateur s’attend à voir apparaître le formulaire en avançant, c’est-à-dire en descendant sur la page, et non en revenant en arrière.
2. N’appliquez pas le focus sur l’initialisation des composants, sauf si cela fait partie de la spécification du composant. Une boîte de dialogue, par exemple, est censée recevoir le focus une fois initialisée.
3. Ne piégez pas le focus. Faites en sorte que l’utilisateur puisse sortir de vos composants. Sauf, encore une fois, si cela fait partie du comportement attendu du composant, comme avec une boîte de dialogue.
4. Soyez prudent avec le chargement illimité. Ne forcez pas les utilisateurs utilisant uniquement le clavier à charger et à parcourir un flux, une liste ou un tableau en entier afin d’accéder au contenu se trouvant après. Par exemple, nos fils Chatter débutent tous avec un lien « Ignorer ce fil ».

Dans le module suivant, nous nous intéresserons à l’écriture de composants accessibles. 

Ressources

Aide Salesforce : Recommandations générales de Lightning Design System sur le focus

Techniques W3C pour WCAG 2.0 : ARIA19 : Utilisation des attributs role=alert ou aria-live pour identifier les erreurs