nota-bene.org > Sur le web > ARIA et comportements attendus

ARIA et comportements attendus

À propos de cet article

Un article de Stéphane

Publié le 21 novembre 2012

URL courte : http://nota-bene.org/921

6 commentaires

Mots-clés (tags)

Une réponse à un article du Train de 13h37 et une question sur ARIA.

Il y a quelques mois le Train de 13h37 publiait un article d’Aurélien Levy intitulé ARIA, il serait temps de s’y mettre !, où il explique ce que c’est, à quoi ça sert et comment on s’en sert.

J’ai posé une question dans le forum associé :

Quand j’avais fait des tests, je crois que j’avais dû ajouter le role="presentation" non seulement pour la ul mais aussi pour chacun des li quand j’avais converti une liste en menu.

(d’ailleurs au final on ne l’avait pas utilisé, l’interaction clavier étant trop « nouvelle » par rapport au comportement attendu par nos utilisateurs test).

Au passage, est-ce que tu prévois de faire un deuxième article pour expliquer cette notion de « comportement attendu » de la spec ?

À quoi Aurélien répondit :

Concernant un deuxième article sur le comportement attendu je n’ai pas bien compris la question clin d'œil

Il est vrai que j’avais été un peu succinct sourire

En clair, voilà ce que je voulais dire :

Quand, dans mon service de l’époque, nous avons testé ARIA, nous avons lu la spécification du W3C, y compris les pratiques de navigation clavier, et c’est là que les choses se sont compliquées.

The TAB key moves keyboard focus to the widget, and other keys operate the features of the widget, typically cursor keys, Enter key and Space. The actual keys are up to the developer, but best practices recommend using the same key bindings that are used to control similar widgets in common GUI operating systems like Microsoft Windows, Mac OS X and other desktop operating systems like GNOME and GTK.

Un utilisateur de lecteur d’écran qui est dans une modalité de navigation web s’attend à passer d’un élément à l’autre en tabulant, or les pratiques que je viens de mentionner partent du principe qu’à l’intérieur d’un widget donné on navigue en utilisant les flèches de direction. C’est tout à fait sensé quand on se réfère à ce qui se passe au niveau du système : par exemple sous Windows un appui sur la touche F10 m’envoie dans la barre de menu principale, et les flèches de direction me promènent d’un menu à l’autre, ainsi à l’intérieur d’un menu.

Nous avons conclu que nos utilisateurs ne comprendraient pas pourquoi, dès qu’ils appuient sur la touche tab, ils sortiraient du menu. Nous en avons donc déduit que nous ne pouvions pas mettre en place ce comportement attendu sous peine de déstabiliser gravement nos utilisateurs.

Qu’en pensez-vous ? Avez-vous déjà dû mettre en place des widgets qui s’appuient fortement sur ARIA, et si oui quel choix avez-vous adopté ? Êtes-vous restés sur le comportement basique et connu dans le navigateur (tabulation de lien en lien) ou avez-vous mis en place le comportement attendu par ARIA ? Quels retours avez-vous eus de la part de vos utilisateurs ?


Commentaires

    • 21 novembre 2012

    Une petite réponse rapide quand à mon interprétation très personnel de la spec sur cette question. L’interprétation que j’en fait ce base sur l’observation des comportements des formulaires HTML tel qu’ils existent aujourd’hui.

    La touche TAB permet de passer d’un widget à l’autre et rien d’autre. Sur un élément select ou input+datalist, la navigation à l’intérieur du widget se fait à l’aide des flèches. Par bien des égard, c’est ce comportement que la spec souhaite voir reproduire par les utilisateurs d’ARIA.

    Et donc les menus. Le problème viens du fait qu’un lien est lui aussi un widget (tout du moins c’est le role que je lui donne à la vue du comportement de tous les navigateurs en la matière). Or, un menu comporte des liens (mais potentiellement aussi des éléments de formulaire comme un champs de recherche par exemple... conceptuellement, ça ne me choque pas)

    Nous sommes donc dans un cas ou la spec ne dit rien (que ce passe-t-il quand un widget est positionné dans un autre widget ?). Mon interprétation en creux de la spec c’est que la TAB doit envoyer vers le widget présent à l’intérieur du premier widget (pas de règle spécial selon la spec, donc on suis l’ordre du flux, le fait que les widgets soient imbriqué n’ayant aucun incidence). Puisque je considère les liens comme des widgets (il sont tabulable et activable au clavier, ergo, ce sont des widgets). Ainsi, si je tabule sur un menu, la prochaine fois que je presserai la touche tabulation, j’activerai le premier lien présent dans le menu. Ça c’est pour respecter la spec.

    Et si j’appuie sur les flèches de direction ? Je passerai aussi d’un lien à l’autre dans le menu... parce que c’est le comportement attendu. Oui, personnellement, je met les deux comportements.

    Et que faire si le menu comporte moult liens que l’utilisateur pourrait souhaiter "éviter" ? Dans ce cas, mon partie pris (forcément puisque la spec ne dit rien sur le sujet) c’est de proposer un raccourcis clavier pour ça. Le problème c’est qu’il n’y a pas d’habitude connu pour ça. Donc dans ce cas, j’utilise le label du widget pour avertir l’utilisateur et lui dire que faire pour "éviter" le widget et en sortir facilement (selon le contexte, double tabulation ou combinaison du type ALT+TAB)

    Voila comment je m’en sort quand je doit faire ce genre de chose. Je suis sur qu’il y a d’autre façon de faire clin d'œil En gros, je respecte toujours la spec à la lettre (sauf si elle va à l’encontre des comportements attendu) ; j’applique les comportements attendu, et si rien n’est prévus, je crée un nouveau comportement que je signale explicitement à l’utilisateur.

    Répondre à Jeremie

    • 21 novembre 2012

    Bonjour,
    Il est vrai que les widgets sont encore très nouveaux et méconnus pour nous, utilisateurs de lecteurs d’écran. D’autant que les implémentations en production sont encore très rares. Cette question m’en amèneune autre : la spec aria permet-elle d’associer une sorte de description à un élément ayant le rôle application ? Ceci permettrait, par exemple de transmettre cette description au lecteur d’écran pour expliquer à l’utilisateur comment naviguer dans le widget.

    Répondre à tanguy

    • 22 novembre 2012

    Bonjour,
    C’est le sujet qui fait le plus débat au sein du groupe d’experts référents qui bûche sur le projet de procédure de labellisation HTML5/ARIA pour AccessiWeb. En gros la question tourne autour de : faut-il imposer l’accès à tout élément focusable via TAB, ou pas ? Comment gérer l’info à l’utilisateur en cas de comportement spécifique (typiquement : navigation avec les flèches dans un widget donné) ?
    Et il y a débat car en fait on n’a pas encore trouvé de réponse définitive. Tout simplement parce que... ça dépend. Un tab panel d’OS est navigable avec les touches ; mais depuis le début du Web, on a habitué les utilisateurs à naviguer dans des ersatz de tabpanels avec TAB. Est-ce une bonne idée de changer ça, sachant que co-existeront durant longtemps les deux approches ?
    Un datepicker se prête à merveille à la navigation par flèches. Auquel cas imposer TAB relève du ridicule. Pour d’autres, comme le tabpanel, c’est moins évident.
    Que faire avec les widgets imbriqués ? Genre, un datepicker dans un formulaire dans un tabpanel ? Le ruban d’Office 2010 nous donne un bel exemple d’interface qui respecte son schéma de navigation clavier à la lettre ; sauf qu’on n’y comprend rien, tant l’ensemble est hétérogène en types de widgets de base.
    Mettre des messages pour l’utilisateur, pour expliquer comment marche le widget ? Très bien ! Mais qu’est-ce que ça donne si on a une dizaine de widgets dans la page ? Et une fois le message affiché, que l’utilisateur a compris, il va sans doute trouver ça lourdingue qu’on le lui répète à chaque accès à ce widget, non ?
    Bref, pas de réponse univoque à ce jour, ce qui pose cet épineux problème : à quel moment, et sur quelle base théorique, peut-on dire que tel dispositif est acceptable (et donc, en l’occurrence, le certifier conforme aux attendus) ?
    Réflexion toujours en cours...
    Désolé d’apporter plus de questions que de réponses clin d'œil, mais il me semblait important d’amener un maximum de pièces à ce débat crucial.

    Répondre à Olivier Nourry (@OlivierNourry)

  • Olivier : Ah mais moi ça me va très bien, une réponse en forme de question. Ça veut bien dire que je creuse au bon endroit, et surtout ça me rassure sur ma capacité de veille-tout-seul-dans-mon-coin clin d'œil

    Blague à part, merci pour les exemples en tout cas.

    Répondre à Stéphane

  • hello,
    même constat qu’Olivier et mêmes interrogations. Je trouve, par ailleurs, la lecture des specs de Jérémie plein de "bon sens".
    Cependant, force est de constater que les utilisateurs ne sont pas mûr pour utiliser, sans se poser de question, les flèches de direction dans un widget.
    Donc, autant que faire se peut, doubler les commandes (Tab + flèches de directions) dans un widget me semble inévitable. C’est un peu lourd mais pour l’instant pas le choix !
    En faisant ça, on défend au mieux l’utilisateur !

    Mais nos devons aussi être moteur dans le respect des spécs et des normes (c’est un peu notre boulot, non ?!) et donc, quand cela s’y prête (typiquement un calendrier), éduquer l’utilisateur au déplacement grâce aux flèches directionnelles dans un widget tout en l’avertissant.

    Dernier point, il me semble essentiel de s’appuyer sur la dichotomie entre internet et intranet (appli métier). Je m’explique en environnement maitrisé, avec des appli sur lesquelles ont a été formé, qui sont utilisées très régulièrement, c’est là que l’on peut plus facilement "imposer" des comportements et donc notamment l’utilisation des flèche de direction. C’est peut être le bon moyen de sensibiliser les utilisateurs !

    Répondre à sanvin

  • Olivier Nourry (@OlivierNourry) :

    tu parles d’OS et ça me fait penser qu’une même « page » web (application plutôt) va bientôt pouvoir être affichée dans un navigateur web (Firefox, Chrome, IE10) et une manipulation plus tard dans un OS : Firefox OS, Chrome OS et le truc qui s’est un temps appelé « Windows 8 en mode Metro ». La frontière est bien mince !

    Pour ce qui est d’éviter de répéter 10 fois le même message et ce à chaque nouvelle page, il est imaginable de surveiller l’usage du clavier dans ces widgets et de désactiver les messages une fois les « nouvelles touches » utilisées par cet utilisateur ? En les réactivant toutes les 24H au cas où, en laissant un lien d’aide pas trop loin si le long et complexe message n’a pas été digéré du premier coup (liste des touches par exemple)...

    Répondre à Felipe

Qui êtes-vous ?
Votre message
  • Pour créer des paragraphes, laissez simplement des lignes vides. Tous les liens sortants comporteront un attribut rel="nofollow". Merci de ne pas spammer.

Ceci est la version Bureau Afficher la version Mobile