ARIA et comportements attendus

Commentaires

• Jeremie (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 ;) 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

• tanguy (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

• Olivier Nourry (@OlivierNourry) (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 😉, mais il me semblait important d’amener un maximum de pièces à ce débat crucial.

  Répondre à Olivier Nourry (@OlivierNourry)

• Stéphane (22 novembre 2012, en réponse à 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 ;)

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

  Répondre à Stéphane

• sanvin (22 novembre 2012, en réponse à 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

• Felipe (23 novembre 2012, en réponse à Olivier Nourry (@OlivierNourry))

  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