Web développer - Navigation clavier

S’assurer que l’utilisateur puisse naviguer uniquement à l’aide du clavier

Permettre d’utiliser les principales fonctionnalités de l’application au clavier #

Cible : tout le monde, et en particulier les personnes déficientes visuelles, cognitives, motrices et en mobilité.
Quand : dès la phase de conception et lors du développement.

Description :
Mettre en place des gestionnaires d’événements qui ne s’appuient pas uniquement sur des événements souris, permettent donc d'être pilotable au clavier et ceci sans limite de temps.

À vérifier :

  • Toutes les actions importantes effectuées à la souris peuvent aussi l’être avec le clavier, quitte à proposer une alternative spécifique pour les interactions complexes (drag’n’drop, gestes à plusieurs doigts sur mobile …) tout en évitant d'innombrables frappes.

  • Utiliser au maximum les composants HTML interactifs de base (champs, liens, boutons), ceux-ci étant nativement accessibles au clavier. À défaut, veiller à ce que les composants personnalisés soient opérables au clavier de manière classique.

Voir la façon de naviguer au clavier dans un navigateur web.

Objectif utilisateur :
Permettre aux utilisateurs qui ne peuvent pas utiliser la souris (non ou malvoyants, déficients moteurs, cognitives, web mobile, en mobilité…) d’accéder aux fonctionnalités principales de l’application au clavier.

Exemple valide :

  • Un sous-menu qui se déroule au survol doit aussi se dérouler quand l’item de menu parent reçoit le focus clavier.
  • Dans un webmail, un clic droit permet d’accéder à un menu pour vider la corbeille, un bouton « vider la corbeille » est également présent dans l’interface quand la corbeille est en cours de consultation.

Exemple non-valide :
Une fonctionnalité réalisable uniquement à l’aide du drag’n’drop et sans équivalent au clavier.

Référence WCAG :

Rendre le parcours du focus séquentiel et logique sans piège clavier #

Cible : tout le monde, et en particulier les personnes déficientes visuelles, cognitives ou avec un trouble de l’attention et en mobilité.

Quand : lors du développement.

Description :

Les éléments (liens, boutons, éléments de formulaire) doivent recevoir le focus dans un ordre séquentiel et logique (de haut en bas et de gauche à droite) lorsque l'ordre du focus est nécessaire pour la compréhension ou l'opérabilité clavier et cela même pour du contenu généré dynamiquement (modification du DOM, Ajax…). Bien-sûr, le focus ne doit ni rester piégé, ni bloqué.

Exemple, les puces numérotées indiquent l'ordre de déplacement du focus dans cette page :
Capture d'écran indiquant l'ordre de déplacement du focus dans une page

À vérifier :

  • Pour valider cette exigence, la position du focus doit être visible à tout moment (propriété outline et :focus en CSS), voir exigence "Rendre visible le focus en toute circonstance" ci-dessous.
  • Veillez à ce que l’ordre d’apparition des éléments dans le code HTMLsoit le même que l'ordre de déplacement du focus, si cet ordre impacte la compréhension du contenu ou la capacité d'utiliser l'interface. Un élément présent à la fin du code source mais positionné tout en haut de la page via CSS sera le dernier à recevoir le focus. C'est la solution la plus simple !
  • Pour la maintenabilité, éviter l’utilisation de l’attribut tabindex avec des valeurs supérieures à 0.
  • Même lors d’apparition ou de disparition de contenu, si besoin, il faut conserver ce parcours logique et séquentiel du focus.
    Ceci est vrai pour du contenu dynamiquement généré ou pour des SPA (single page application) ou applications web sur une seule page. Pour plus de détails, voir Recommandations pour les Single Page Applications et Gestion dynamique du focus

Objectif utilisateur :
Permettre la navigation logique, sans piège au clavier dans les pages de l’application. Nécessaire pour les utilisateurs ne naviguant qu’au clavier (non ou malvoyants, déficients moteurs, déficients cognitifs, en mobilité).

Exemple valide :
Dans une page dédiée à la recherche dans le site, on passe, à la navigation clavier, sur le formulaire de recherche avant d'arriver à la liste des résultats.

Exemple non-valide :
Une page contenant un lecteur vidéo dont le focus peut entrer à l’intérieur du lecteur, mais ne peut pas en sortir (piège clavier).

Référence WCAG :

Rendre visible le focus en toute circonstance #

Cible : tout le monde, et en particulier les personnes déficientes visuelles, motrices, cognitives, ayant un déficit d’attention et en mobilité.
Quand : dès la phase de conception et lors du développement.

Description :

Ne pas masquer le focus et si nécessaire accentuer sa visibilité sur tous les éléments focusables, par exemple en modifiant la propriété CSS outline.

Veiller à fournir un niveau de contraste suffisant de 3:1 pour que celui-ci soit visible par tous (cf. mesurer le niveau de contraste des couleurs).

Lorsqu’un effet est visible sur un élément au survol de la souris (:hover en CSS par exemple), cet effet doit être également affiché à la prise du focus (:focus).

Il est possible, avec du code Javascript, de n’afficher l’outline que lors d’une navigation au clavier (c’est à dire de ne pas afficher l’outline lors d’un clic souris, qui active également l’état :focus) :


var head = document.head || document.getElementsByTagName(’head’)[0];
var axsStyles = head.appendChild(document.createElement(’style’));
document.addEventListener(’mousedown’, function() {
	axsStyles.innerHTML = ’* {outline:none !important}’;
});
document.addEventListener(’keydown’, function() {
	axsStyles.innerHTML = ’’;
});

Démonstration de la visibilité du focus à la navigation clavier uniquement

À vérifier :
Dans beaucoup de frameworks front ou dans les reset CSS, la propriété outline (qui permet de visualiser le focus) est désactivée (outline: none;), penser à la redéfinir et vérifier que le focus est visible sur tous les éléments le recevant.

Par défaut, le focus est visible via la propriété CSS outline: 1px. Ceci n'est pas suffisant pour être bien visible, nous préconisons au moins 2px pour la propriété outline et un contraste de 3:1 par rapport à la couleur de fond.

De plus, il faut vérifier la visibilité du focus sur tous les éléments focusables, notamment, car la couleur de fond de l'élément peut être la même que le focus et donc, masquer celui-ci.

Objectif utilisateur :
Permettre la visibilité du focus sur tous les éléments actifs, notamment pour les utilisateurs de clavier (déficients visuels, moteurs ou ceux ayant des déficiences d’attention et de mémorisation ou en mobilité).

Exemples valides :
Dans les captures d’écran suivantes, le focus est positionné sur le lien « 209 SMS/mois ».
La première capture présente le comportement par défaut (focus représenté par des pointillés).
Dans la seconde capture, les pointillés ont été supprimés, mais un encadré permet d’indiquer de manière explicite l’emplacement du focus.
capture d’écran présentant l’affichage du focus par défaut
capture d’écran présentant un comportement personnalisé pour l’affichage du focus

Référence WCAG :

S'assurer que l'utilisateur puisse toujours voir où est positionné dans le viewport le composant qui reçoit le focus. #

Cible : tout le monde, et en particulier les personnes sans déficience visuelle particulière utilisant la navigation au clavier et/ou déficience(s) cognitive(s) et les utilisateurs de loupe d'écran.

Quand : dès la phase de conception mais surtout lors du développement.

Description :
Lorsqu'un composant reçoit le focus lors de la navigation au clavier, le composant ne doit pas être totalement masqué. Attention en particulier aux sticky header et footer ainsi qu'aux fenêtres modales. Attention également lorsque le focus est géré en JavaScript.

Bonne Pratique :
Il est possible d'aller plus loin en veillant à ce que le composant reste totalement visible à la prise de focus (critère 2.4.12 Focus Not Obscured (Enhanced) niveau AAA) car cela permet de garantir que l'utilisateur ait connaissance de la fonction du composant.

A vérifier :

  • Penser à utiliser la tabulation avant (tab) et arrière (Shift+ tab) pour vérifier tous les cas de figure.
  • Veiller à tester toutes les interactions susceptibles de cacher le composant qui reçoit le focus (notamment les éléments en position fixe ou sticky, modales, menus déroulants,...).
  • Attention aux cas où le viewport est réduit (responsive sur mobile, zoom, utilisation d'une loupe d'écran).

Complément :

  • Lorsque le contenu d'une interface configurable peut être repositionné par l'utilisateur, seules les positions initiales du contenu déplaçable par l'utilisateur sont prises en compte pour les tests et la conformité à ce critère de réussite.
  • Le contenu ouvert par l'utilisateur peut masquer le composant recevant le focus. Si l'utilisateur peut révéler le composant ciblé sans déplacer le focus alors le composant avec le focus n'est pas considéré comme masqué en raison du contenu créé par l'auteur.
  • Si le composant qui reçoit le focus est recouvert par un autre élément dont l'opacité est inférieure à 100 % alors le composant qui reçoit le focus n'est pas totalement masqué et le critère est validé. Attention toutefois à bien évaluer les critères sur les contrastes.

Objectif utilisateur :
Permettre aux utilisateurs de la navigation au clavier de toujours savoir où est positionné le composant qui reçoit le focus et quelle est sa fonction.

Exemple valide :
Une page avec des composants sticky susceptibles de recouvrir l'élément qui reçoit le focus lors du scroll utilisent les propriétés CSS 'scroll-padding-*'' afin d'éviter que les différents éléments de la page ne se recouvrent.

Exemple non valide :

  • Une modale apparaît à l'écran mais le focus n'est pas restreint à l'intérieur de celle-ci. Par conséquent le focus peut être positionné sur des composants recouverts par la modale.
  • Un chatbot occupe une partie du viewport et est placé au premier plan recouvrant ainsi totalement le composant qui reçoit le focus

Référence WCAG :