widget-keyboard-focusable
Les widgets devraient être atteignables au clavier
Signale, pour une revue manuelle, un élément doté d’un rôle de widget qui ne peut pas recevoir le focus ou qui est hors de l’ordre de tabulation, ainsi qu’un widget composite sans arrêt de tabulation.
Applicabilité. Éléments que la page affiche, dotés d’aria-activedescendant, et ceux dont le rôle, issu de l’attribut role ou des ElementInternals d’un élément personnalisé, est un widget qu’actionne l’utilisateur :
- widgets simples : button, link, checkbox, switch, radio, slider, spinbutton, textbox, searchbox, combobox ;
- widgets composites : grid, treegrid, listbox, menu, menubar, tree, tablist, toolbar, radiogroup.
Laissés de côté :
- un élément hors de l’arbre d’accessibilité (
aria-hidden="true"), ou désactivé (disabled, ouaria-disabled="true"sur lui ou sur un ancêtre) : il n’offre rien à actionner ; - un widget situé dans un widget composite, ou dans un élément qui peut recevoir le focus et dont l’
aria-activedescendantpointe vers un élément (par id, ou défini par script commeariaActiveDescendantElement; un attribut vide ne pointe vers rien) : le composite déplace le focus entre ses éléments (un tabindex itinérant, ou roving tabindex) ou le conserve et pointe vers l’élément actif, si bien que c’est l’élément extérieur qui est jugé à la place (pour un sous-menu, sa menubar) ; - un élément doté d’un
onclicken ligne, ou d’un écouteur de clic qu’a vu le hook d’écouteurs (listenerHookScript), que jugeclick-handler-keyboard-operable.
Attendu. Une personne qui utilise le clavier peut atteindre le widget avec la touche Tab (WCAG 2.1.1). Seule la focalisabilité indiquée par le balisage est lue : un script peut déplacer le focus ou traiter les touches d’une façon que le balisage ne montre pas, si bien qu’un constat est une question, jamais un échec.
- Un widget simple qui est dans l’ordre de tabulation, ou qui contient un élément qui l’est, réussit.
- Un widget simple qui ne peut pas recevoir le focus, et ne contient rien qui le puisse : cantTell (
WIDGET_NOT_FOCUSABLE). Vérifiez qu’une personne qui utilise le clavier peut l’atteindre, ou accéder à ce qu’il fait, d’une autre façon. - Un widget simple qui ne reçoit le focus que par script (
tabindex="-1") : cantTell (WIDGET_NOT_IN_TAB_ORDER). La touche Tab ne l’atteint jamais ; vérifiez qu’un script y déplace le focus, ou que ce qu’il fait est proposé ailleurs. - Un widget composite réussit lorsqu’il est dans l’ordre de tabulation (avec ou sans
aria-activedescendantpointant vers son élément actif) ou qu’il contient un élément qui l’est. Celui qu’aucun autre élément ne nomme dansaria-controlsouaria-owns(une fenêtre surgissante ouverte par un bouton ou un combobox reçoit le focus de celui-ci) et qui n’a ni l’un ni l’autre : cantTell (COMPOSITE_NO_TAB_STOP). - Un élément de n’importe quel rôle portant
aria-activedescendantqui ne peut pas recevoir le focus : cantTell (ACTIVEDESCENDANT_HOST_NOT_FOCUSABLE). L’élément actif n’est annoncé que tant que cet élément a le focus. Un tel élément ne gère pas le focus des widgets qu’il contient, qui sont donc jugés pour eux-mêmes.
Ce que rapporte un constat.
role: le rôle de l’élément.focusable: si l’élément lui-même peut recevoir le focus.scriptFocusable: pour un composite, si un élément qu’il contient reçoit le focus par script (tabindex="-1").
Ces champs de data.details aident à lire et à reproduire un constat. À part reasonCode et les quelques champs que la page Schéma de sortie donne comme stables, ils ne constituent pas un contrat stable : un champ peut être renommé ou supprimé dans une version mineure, ne vous appuyez donc pas dessus.
Exemples
<div role="button" tabindex="0">Save</div>
Le bouton personnalisé est dans l’ordre de tabulation.
<div role="button">Save</div>
L’élément se présente comme un bouton, mais la touche Tab ne l’atteint jamais. Une personne vérifie qu’une personne qui utilise le clavier peut l’atteindre, ou accéder à ce qu’il fait, d’une autre façon.
Comment vérifier
Quand cette règle ne peut pas trancher, elle renvoie cantTell et laisse la question à une personne. Chaque question qu’elle peut poser figure ici sous son code de raison, avec les étapes pour y répondre. Un constat porte les mêmes étapes dans howToCheck, dans la langue de l’analyse. Voir Schéma de sortie.
ACTIVEDESCENDANT_HOST_NOT_FOCUSABLE
- Repérez l’élément indiqué par le rapport ; il utilise aria-activedescendant pour désigner son élément actif.
- En n’utilisant que le clavier, ouvrez ou atteignez le widget (par exemple en tapant dans son champ de recherche) et observez si c’est bien cet élément, et pas un autre, qui reçoit le focus.
- Appuyez sur les touches fléchées avec un lecteur d’écran en marche et écoutez si chaque élément actif est annoncé.
- Si les éléments ne peuvent pas être atteints ainsi, vérifiez si les mêmes choix peuvent être faits autrement au clavier seul, par exemple en saisissant la valeur dans un champ de texte. Cela ne compte que si chaque choix est disponible ainsi et qu’un lecteur d’écran l’annonce.
Réussite. L’élément reçoit le focus et le lecteur d’écran annonce chaque élément actif quand les touches fléchées se déplacent, ou les mêmes choix peuvent être faits autrement au clavier seul et le lecteur d’écran les annonce.
Échec. L’élément ne peut pas recevoir le focus : parcourir les éléments n’annonce rien ou ils ne peuvent pas être atteints, et les choix ne peuvent pas être faits autrement au clavier, ce qui ne respecte pas le critère WCAG 2.1.1.
COMPOSITE_NO_TAB_STOP
- Repérez le widget indiqué par le rapport (un menu, une zone de liste, une liste d’onglets, une barre d’outils, une grille ou une arborescence).
- Cliquez juste avant lui et appuyez sur Tab, puis observez si le focus y entre ou atteint l’un de ses éléments.
- S’il s’agit d’une fenêtre contextuelle, ouvrez-la au clavier depuis son bouton et voyez si le focus s’y déplace.
- Une fois à l’intérieur, vérifiez que les touches fléchées permettent de passer d’un élément à l’autre.
- Si le focus n’y entre jamais, vérifiez si ce que fait le composant peut être fait autrement au clavier seul, par exemple les mêmes choix proposés sous forme de liens ou de boutons ailleurs dans la page. Cela ne compte que si chaque option du composant est disponible ainsi.
Réussite. Tab (ou le bouton qui l’ouvre) place le focus dans le composant et les touches fléchées passent d’un élément à l’autre, ou tout ce que font ses éléments peut être fait autrement au clavier seul.
Échec. Le focus n’entre jamais dans le composant ni dans ses éléments au clavier, et ce qu’ils font ne peut pas être fait autrement au clavier, ce qui ne respecte pas le critère WCAG 2.1.1.
WIDGET_NOT_FOCUSABLE
- Repérez le widget indiqué par le rapport et notez ce qu’il fait quand on clique dessus ou qu’on le touche.
- Cliquez juste avant lui, puis appuyez sur Tab et observez si le focus arrive un jour sur lui.
- S’il ne reçoit jamais le focus, cherchez un autre contrôle accessible au clavier qui fait la même chose.
- Si l’élément ne fait rien, son rôle est peut-être erroné ; notez-le plutôt.
Réussite. Le widget reçoit le focus clavier et fonctionne au clavier, ou la même fonction est proposée par un autre contrôle accessible au clavier.
Échec. Le widget ne peut pas être atteint ni utilisé au clavier et sa fonction n’est proposée nulle part ailleurs, ce qui ne respecte pas le critère WCAG 2.1.1 (F42).
WIDGET_NOT_IN_TAB_ORDER
- Repérez le widget indiqué par le rapport et notez quand il apparaît (par exemple à l’ouverture d’un menu ou d’une boîte de dialogue).
- N’utilisez que le clavier pour ouvrir ou atteindre cette partie de la page, et observez si un script déplace le focus sur le widget, ou si les touches fléchées l’atteignent.
- Si le focus ne l’atteint jamais, cherchez un autre contrôle accessible au clavier qui fait la même chose.
Réussite. Le focus est déplacé sur le widget par un script ou par les touches fléchées quand c’est nécessaire, ou sa fonction est proposée ailleurs.
Échec. Ni Tab ni les touches fléchées n’atteignent jamais le widget et rien d’autre ne propose sa fonction, ce qui ne respecte pas le critère WCAG 2.1.1.