Questions sur les scripts utilisant certaines touches du clavier

Salut !

J'ai quelques questions relevant de l'accessibilité, mais avant, j'expose la mise en situation :

Faisant partie de l'équipe de support d'un logiciel de forum opensource écrit par un Belge francophone, je suis donc impliquée dans le développement, avec des suggestions, en plus d'écrire de la documentation et des MODs. Déjà, j'ai proposé une modifications pour permetttre d'utiliser <img /> au lieu des backgrounds CSS pour les images porteuses de contenu, et c'est sur la bonne voie pour être implémenté sur la prochaine bêta de la version 1.0 dudit logiciel.

Mais lors de la présentation de la première bêta de la 1.0 il y a quelques mois, il y a eu un ajout qui consiste à un menu de navigation en javascript sur le côté, et celui-ci utilise les touches du clavier pour passer à la page suivante, à la page précédente, etc. Par exemple, "page suivante" utilise la touche "c" et "page précédente" utilise la touche "w".

Or, je me demande si cela est risqué au niveau de l'accessibilité, sachant que certaines applications, dont certaines extensions Firefox, utilisent de tels raccourcis ne requérant pas de combinaisons de touches. Puisque je n'ai jamais testé avec un lecteur d'écran (il faudrait un moment donné que je teste Orca, qui est inclus par défaut sur Ubuntu), je ne sais pas s'il y a des risques d'interférences avec les médias alternatifs et la navigation au clavier.

La version n'étant pas en état de gel de fonctionnalités, j'ai donc encore le temps de demander votre avis, afin que je puisse ensuite les transmettre au développeur, qui est d'ailleurs très ouvert à toutes suggestions pour améliorer l'accessibilité de son bébé.

Merci d'avance.

Ishimaru

Bonjour,

Compte-tenu des difficultés classiques liées aux raccourcis clavier dans les interfaces Web, ATAG recommande en effet :
* d'en limiter l'usage quand il s'agit d'une application Web, et de privilégier les liens d'accès rapides aux différents menus. Voir Implementing Success Criterion A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided. (Level AA)
* ou, mieux, de fournir des raccourcis claviers personnalisables (voir Implementing Success Criterion A.3.1.5 Customize Keyboard Access: Keyboard access to the authoring tool can be customized. (Level AAA) )

Enfin, il faut aussi, pour certains widgets au moins, voir du côté d'ARIA : WAI-ARIA Keyboard Bindings and Behaviors
Modifié par Laurent Denis (03 Aug 2010 - 06:33)

Pour mieux comprendre, je vous donne le lien du forum de tests : http://beta.connectix-boards.org
Il faut cliquer sur "Navigation" qui se trouve en haut à droite, pour dérouler le menu JS, et vous verrez de quoi je parle. Il faut bien sûr avoir autorisé Javascript sur le site si on utilise une extension du genre Noscript.

Pour le moment, c'est le seul point que je veux vous parler dans l'immédiat, même s'il reste d'autres améliorations à faire (dont une en vois d'être réglée, soit les images porteuses de contenu), et pour ça, je pourrais bien l'inviter ici.
Modifié par IshimaruChiaki (03 Aug 2010 - 11:25)

Hillo,

Désolé pour cette question : je ne parviens pas à tester la fonction dont tu parle. As-tu un exemple de page où ça peut être testé ?

La question du clavier m’intéresse aussi.

De tels raccourcis ne peuvent que difficilement fonctionner avec les lecteurs d'écran. En l'occurence, pratiquement toutes les lettres simples sont déjà utilisées pour la navigation rapide.

Partez du principe que les évènements onkeydown/press/up ne fonctionnent jamais normalement lorsque le navigateur est utilisé conjointement à un lecteur d'écran. Suivant les versions des logiciels, le contexte et les combinaisons de touches, ils peuvent ne jamais être envoyées, l'être plusieurs fois, l'être mais à retardement... bref, ne les utilisez pas en-dehors des champs de formulaires.

Note : il se peut que ça fonctionne quand même avec jaws en faisant précéder la combinaison d'insert+3... mais alors l'intérêt de ce genre de raccourci est sérieusement amoindri.

hibou57 a écrit :
Hillo,

Désolé pour cette question : je ne parviens pas à tester la fonction dont tu parle. As-tu un exemple de page où ça peut être testé ?

La question du clavier m’intéresse aussi.

Pour te répondre : Avant toute chose, si tu utilises une extension comme Noscript, il faut autoriser les javascripts du site pour pouvoir le voir

Ainsi, lorsque Javascript est activé, tu dois normalement voir ceci en haut à droite :


En cliquant dessus, tu as ceci qui se déroule :


C'est donc de ce widget dont je parle et donc je me questionne sur l'impact de l'utilisation des touches du clavier sur l'utilisation des navigateurs (et leurs extensions) et des médias alternatifs, pour quelqu'un qui ne peut pas utiliser la souris.

Puisque déjà QuentinC a apporté une réponse qui peut encore être approfondie, je vais transmettre le lien à Martin.
Modifié par IshimaruChiaki (04 Aug 2010 - 07:41)

Pour préciser les choses :
* pour les raccourcis clavier dans le web au sens classique, lire l'un des deux classiques: Accesskey le grand échec de l'accessibilité du Web et Accesskey, l’essai non transformé de l’accessibilité, mais en sachant qu'ils ont vieilli et que la question est tout de même différente dans le cas d'une application en ligne
* C'est en effet un widget, et c'est du côté d' ARIA, comme indiqué plus haut, qu'il faut aller trouver la solution
* pour compléter ou corriger le retour de Quentin, voir Docs/Keyboard navigable JS widgets.

En très résumé :
* l'ouverture du widget devra déjà être atteignable au clavier via la tabulation (ce qui, si je ne me trompe pas, n'est pas le cas actuellement)
* une fois entré dans le widget, il y a un choix de conception à faire (voir les Design Choice dans DIY Accessible UI Controls with ARIA and HTML (5) : soit l'enseble des contrôles du widget sont directement utilisables via la touche TAB, soit des touches spécifiques leur sont associées en respectant des usages courants.
* virer les raccourcis claviers s'ils ne sont pas personnalisables via les préférences utilisateur
Modifié par Laurent Denis (04 Aug 2010 - 11:03)

L'exemple de tree view indirectement pointée par Laurent marche déjà pas mal, mais il y a quand même de gros problèmes. Testé avec XP+JFW11+(IE8|FX3.6). ON arrive directement sur le contrôle (autofocus) et il se manipule aisément, mais il est difficile de le quitter pour lire le reste de la page, car jaws désactive le mode virtuel... C'est pareil avec IE8 et firefox 3.6. IL faut magouiller un moment avant d'avoir le comportement souhaitable, c'est-à-dire que ce composant peut être activé et quitté en activant et désactivant le mode formulaire. C'est pas mal, mais ce n'est malheureusement pas encore au point, il faudra encore attendre un peu avant qu'ARIA fonctionne bien. J'ai pas testé avec NVDA mais je pense que ça doit aussi marcher.
Modifié par QuentinC (04 Aug 2010 - 18:10)