Critères de succès

WCAG 2.1.1 Clavier

Le critère de succès 2.1.1 exige que toutes les fonctionnalités du contenu soient utilisables au moyen d'une interface clavier, sans exiger de minutage particulier pour chaque frappe. C'est un critère de niveau A - l'une des exigences fondamentales du principe Utilisable, sous la règle 2.1 (Accessibilité au clavier).

Pourquoi « clavier » et pas seulement « non dépendant de la souris »

Ce critère est formulé autour de l'interface clavier précisément parce que celle-ci représente toute une catégorie de technologies d'assistance : les dispositifs à contacteur, les logiciels de commande vocale et les lecteurs d'écran passent généralement par la même interface d'événements, équivalente à celle d'un clavier réel. Une commande utilisable au clavier est très souvent utilisable par toutes ces technologies à la fois ; une commande utilisable à la souris seule les exclut toutes simultanément.

Ce que « toutes les fonctionnalités » signifie réellement

Chaque capacité interactive de la page doit disposer d'un chemin au clavier : non seulement la navigation principale, mais aussi le glisser-déposer pour réordonner, les menus déclenchés au survol, les curseurs sur mesure, les outils de dessin sur canevas, les actions contextuelles du clic droit. Si une personne utilisant la souris peut le faire, une personne utilisant le clavier doit disposer d'un moyen équivalent, même si le schéma d'interaction exact diffère - les touches fléchées au lieu du glissement, par exemple.

L'unique exception, étroite

Les WCAG n'admettent d'exception que lorsque la fonction sous-jacente exige fondamentalement une saisie qui ne peut être émulée au clavier avec une précision raisonnable - le dessin à main levée en est l'exemple de référence. C'est une réserve étroite, non un prétexte général : une liste déroulante sur mesure, une fenêtre modale ou une liste réordonnable par glissement sont toutes censées disposer d'équivalents clavier ; elles n'exigent pas fondamentalement un pointeur, elles ont simplement été construites en en supposant un.

Où cela casse en pratique

Voir Commandes inaccessibles au clavier pour les défaillances concrètes : des <div> mis en forme en boutons avec un seul gestionnaire de clic souris, des composants sur mesure sans câblage d'événements clavier, et des valeurs de tabindex positives qui perturbent l'ordre de tabulation naturel. Dans presque tous les cas, la correction est la même : privilégier les véritables éléments HTML interactifs natifs, qui apportent gratuitement le comportement clavier, plutôt que de reconstruire ce comportement sur un élément générique.

Le piège connexe : les pièges au clavier

Un critère distinct mais étroitement lié, le critère 2.1.2 (Pas de piège au clavier), exige que si le focus clavier peut entrer dans un composant, il puisse aussi en ressortir au seul clavier - ou que la personne soit informée de la façon de procéder. Une fenêtre modale que l'on peut ouvrir par tabulation mais dépourvue de bouton de fermeture accessible au clavier constitue un piège au clavier : techniquement distinct d'une non-conformité au critère 2.1.1, mais généralement présent à ses côtés.

Questions fréquentes

Qu'est-ce que le critère WCAG 2.1.1 Clavier ?

Un critère de niveau A qui exige que chaque fonction interactive soit utilisable au seul clavier, et non uniquement à la souris.

Qu'est-ce qui échoue couramment au critère 2.1.1 ?

Des commandes sur mesure construites à partir d'éléments div ou span avec un gestionnaire de clic mais aucune prise en charge du clavier, et des interactions qui ne répondent qu'au survol ou aux événements de souris.

Y a-t-il des exceptions ?

Oui - les fonctions qui exigent intrinsèquement une saisie continue fondée sur un tracé, comme le dessin à main levée, sont exemptées ; mais la grande majorité des commandes doivent être utilisables au clavier.