29 mars 2022 | Ted Page
Pour concevoir des formulaires, il est conventionnellement admis d’utiliser des boutons radio lorsque l’utilisateur ne peut choisir qu’une seule possibilité et d’utiliser des cases à cocher lorsque l’utilisateur dispose de choix multiples. Bien qu’il existe généralement de bonnes raisons d’adhérer aux conventions, il peut arriver qu’une règle ou une convention particulière rende un formulaire moins utilisable au lieu de l’améliorer.
Par exemple, je suis récemment tombé sur la mise en page suivante pour un formulaire PDF. Le formulaire était conforme à la convention, car il utilisait des boutons radio pour une question pour laquelle l’utilisateur ne pouvait choisir qu’une seule réponse, dans le cas présent, pour spécifier son origine ethnique.
Problème de l’ordre des tabulations
Dans l’exemple ci-dessus, la présence de plusieurs champs de texte « Autre, veuillez préciser » placés entre les boutons radio crée un problème au niveau de l’ordre des tabulations. En effet, un groupe de boutons radio mutuellement exclusifs ne constitue qu’un seul et unique élément dans l’ordre des tabulations.
L’ordre des tabulations pour ce groupe de champs est le suivant : les 13 boutons radio ne constituent qu’un seul élément suivi des cinq champs « Autre, veuillez préciser » et sont lus de haut en bas. Cela ne constitue manifestement pas un ordre de tabulations cohérent. La seule autre option de mise en page, qui consiste à disposer d’un seul champ « Autre, veuillez préciser » après le treizième bouton radio, ne serait pas aussi claire : disposer de champs « Autre, veuillez préciser » séparés (un pour chaque section) est plus logique pour l’utilisateur final.
Cases à cocher mutuellement exclusives
Dans ce cas, il aurait été préférable d’utiliser un ensemble de 13 cases à cocher mutuellement exclusives. En effet, chaque case à cocher constitue un élément unique dans l’ordre des tabulations, ce qui constitue l’une des différences essentielles entre les boutons radio et les cases à cocher.
Si des cases à cocher avaient été utilisées, l’utilisateur aurait pu faire défiler les deux premières options, puis passer au premier champ de texte « Autre, veuillez préciser » (avec une infobulle/description « Autre blanc, veuillez préciser »). L’utilisateur pourrait alors passer à la case suivante (« Caribéen blanc ou noir ») et ainsi de suite, en parcourant le formulaire dans l’ordre correct.
Tentative de contournement
L’auteur du formulaire original semble avoir été conscient du problème, car il a inséré une ligne de texte invisible au début du formulaire conseillant aux utilisateurs de lecteurs d’écran de se servir de la flèche vers le bas pour naviguer dans le formulaire plutôt que la touche de tabulation.
Toutefois, utiliser la flèche vers le bas de cette manière n’est pas une solution pour un formulaire qui comprend des cases à cocher, comme c’était le cas de la version originale de ce formulaire. En effet, il n’est pas possible de sortir du « mode formulaire » d’une case à cocher dans JAWS en utilisant la flèche vers le bas (ce qui est, soit dit en passant, tout à fait faisable dans NVDA). Les utilisateurs de JAWS seront obligés d’utiliser la touche de tabulation pour quitter une case à cocher, ce qui rend l’instruction problématique.
Notez également que l’utilisation de texte invisible de cette manière n’est pas une bonne idée, car les technologies d’assistance autres que les lecteurs d’écran le liront elles aussi. Pour les utilisateurs de logiciels d’alphabétisation (voyants), le texte invisible qui est lu à haute voix risque d’être déroutant.
Conclusion
Dans cet exemple particulier, un ensemble de cases à cocher mutuellement exclusives résout tous les problèmes et serait plus logique que de s’en tenir strictement à la convention selon laquelle il faut utiliser uniquement des boutons radio lorsqu’une seule possibilité doit être sélectionnée.