ARIA role=application, ou la totale incompréhension

Il semblerait qu'une des tandance actuelles soit d'appeler « application web » à peu près n'importe quel site web 2.0 utilisant javascript et AJAX. « Application web », ça sonne forcément plus cool que « page web » ou « site web interactif » ou autres appellations similaires.

Parralèlement à cela, et c'est fondamentalement une très bonne chose, les attributs ARIA améliorant l'accessibilité de telles pages dynamiques sont de plus en plus utilisés. La plupart ne sont normalement pas trop difficiles à comprendre et à implémenter de manière raisonnablement correcte (je devrais peut-être écrire un article d'introduction sur le sujet), mais il en existe malgré tout certains qui paraissent néanmoins échapper à la compréhension générale et collective. Je dis ça parce que, en-dehors de mes développements personnels, je n'ai à ce jour rencontré encore aucun site les utilisant réellement comme il faut.

Le rôle ARIA application fait partie de ces derniers. C'est sur celui-là que j'aimerais m'attarder aujourd'hui, car il est tellement mal compris et mal implémenté qu'il pose des problèmes sur la quasi-totalité des sites web qui croient bien faire et qui l'utilisent malheureusement le plus souvent totalement incorrectement sans raison véritablement valable, hormis que ça paraît peut-être plus cool pour le commun des mortels que son site web soit considéré comme une application plutôt que comme un site.

En fait, personne ne paraît vraiment comprendre ce que ce rôle implique vraiment, de même que quand il devrait, et quand il ne devrait pas être utilisé.

Le mieux pour bien comprendre est de commencer par aller relire la définition du W3C :

When the user navigates an element assigned the role of application, assistive technologies that typically intercept standard keyboard events SHOULD switch to an application browsing mode, and pass keyboard events through to the web application.

Traduction approximative :

Lorsque l'utilisateur navigue dans un élément affublé du rôle application, les aides techniques, qui interceptent habituellement les frappes du clavier doivent passer dans un mode application, et passer les raccourcis clavier courants habituellement interceptés à la page web.

Concrètement, qu'est-ce que ça signifie ?

Il faut savoir qu'en temps normal, les aides techniques, et particulièrement les lecteurs d'écran, proposent un mode de navigation et des raccourcis spécifiques pour faciliter la navigation sur le web.

De base, un navigateur web qui fonctionne sans lecteur d'écran ne permet typiquement au clavier que de naviguer que de lien en lien avec les touches Tab et Maj+Tab, et ne permet normalement pas de positionner le curseur où on le souhaite (on ignorera ici le cas de la sélection et du copier-coller). Pour que les pages web soient lisibles par un lecteur d'écran, ce dernier ajoute à cela, en se superposant au navigateur et au système d'exploitation, des raccourcis spéciaux pour naviguer avec un curseur qui se déplace sur la page web comme s'il s'agissait d'une zone de texte dans un éditeur comme word ou le bloc-notes. Par exemple, la touche H avec jaws et NVDA déplace ce curseur vers le titre suivant, ce qui permet de commencer ou continuer la lecture à partir de celui-ci en sautant tout ce qui se trouve avant. De même, les touches fléchés servent généralement à lire le texte ligne par ligne ou caractère par caractère. On appelle ce mode de navigation normal sur le web le mode curseur virtuel ou parfois le mode document (peut-être qu'un article sur le curseur virtuel serait aussi utile, pour que les novices comprennent bien ce que c'est).

Il faut bien comprendre que dans ce mode, quand on appuie sur une touche comme H, l'évènement n'est pas envoyé à la page web. En d'autres termes, aucun évènement javascript keydown n'est déclenché. Le lecteur d'écran intercepte silencieusement cet appuie et effectue l'opération demandée par l'utilisateur, ici sauter au titre suivant.

Quand on passe en mode application, au contraire et comme prescrit par le W3C, l'aide technique n'intercepte plus les touches normalement dédiées à la navigation comme H et transmet l'appui directement à la page web. Autrement dit, dans ce mode, l'évènement keydown est effectivement envoyé et un script javascript peut y répondre. Les lecteurs d'écran comme jaws et NVDA ont suivi les recommandations du W3C et entrent en mode application dès lors que le curseur réel ou virtuel se retrouve à l'intérieur d'un élément doté de ce rôle.

Le souci, c'est que dans ce mode, la navigation à laquelle l'utilisateur de lecteur d'écran est habitué ne fonctionne plus. Tant qu'on est en mode application, et c'est le cas tant qu'on se trouve dans la zone définie par le rôle application, on n'a tout simplement plus accès à la navigation rapide de titre en titre et les autres raccourcis du genre. La touche Tab, qui est en fait gérée par le navigateur et le système d'exploitation et non pas par le lecteur d'écran, elle, continue à fonctionner. Mais toutes les autres, non.

Venons-en donc à l'aspect pratique de la chose: si le site web qui demande le mode application le fait bien et propose une navigation au clavier entièrement gérée par javascript, alors il est possible d'améliorer grandement l'utilisabilité de son site web.

Par exemple, on pourrait imaginer que dans un webmail accessible, les touches haut et bas pourraient servir à passer à l'e-mail précédent ou suivant dans la liste des messages, entrée pour ouvrir, Ctrl+R pour répondre, etc. Pareil pour une application twitter où ces mêmes touches pourraient permettre de passer du twitt précédent au suivant. Dans une grille comme dans un tableur, les flèches pourraient similairement servir à se déplacer aisément de cellule en cellule dans les quatres directions. Vers 2005, j'avais codé un petit jeu de sudoku en javascript qui utilisait cette idée pour passer d'un champ à l'autre, sans ARIA car à l'époque ça n'existait pas, mais qui fonctionnait pas trop mal outre cela.

Mais tout cela implique que les scripts javascript de la page sachent gérer tous les aspects de la navigation clavier correctement et jusque dans les moindres détails, comme si on avait à faire à une application native, comme Thunderbird pour l'exemple du client mail, ou Excel pour le tableur. S'il en était toujours ainsi, les applications web bien conçues ressembleraient à s'y méprendre à de véritables applications natives. ET la tendance veut qu'en effet, visuellement en tout cas, le web et donc le navigateur s'intègrent de plus en plus et se fassent de plus en plus transparent sur le bureau. IL n'y a qu'à voir ce que fait Windows 8 pour bien comprendre l'idée du mode site, qui ouvre en fait un Internet Explorer totalement intégré de sorte que l'utilisateur ne se rende pas vraiment compte qu'il est sur le web avec IE. Au fait, pour qu'une application native soit accessible, elle se doit de gérer tout cela. Eh bien sur le web, ça devrait être pareil !

Malheureusement, il se trouve que le mode application est demandé sur énorméement de pages web unt temps soit peu dans la mouvance 2.0, plus ou moins conscient de l'accessibilité et de ce que ARIA peut apporter dans le domaine, mais en implémentant un peu au hasard sans réellement comprendre, et derrière ce mode application, il n'y a rien, ou autrement dit une gestion variant de très insuffisante à totalement incomplète du clavier. Par demander le mode application, j'entends par là que le rôle application a été attribué à une ou plusieurs zones du site web visé.

Si le clavier est mal géré dans une application native, il n'y a aucun compromis: elle n'est pas accessible, ou au moins certaines choses ne le sont pas. Certains frameworks sont connus pour faire des applications très accessibles, certains autres pas du tout. Sur le web c'est pareil ! Sauf que d'ordinaire, si on ne demande pas explicitement le mode application, alors les aides techniques font au mieux pour que la page soit raisonnablement lisible, et si on a suivi au moins un peu les normes WCAG, il n'y a rien à faire d'autre pour que la navigation par titre, par champ de formulaire, ou autre chose, fonctionne assez bien. Et heureusement, la norme WCAG, en tout cas la 1.0, commence à passer gentiment dans les moeurs.

Par contre, En demandant le mode application et en gérant mal ou pas du tout la navigation clavier derrière, on met l'utilisateur d'aide technique en prison. Ce qui se passe est que l'utilisateur entre dans ce mode sans nécessairement bien savoir de quoi il s'agit, et comme la page ne gère pas les choses une fois qu'on est entré dans ce mode, on arrive plus à en sortir ou seulement au prix de grans efforts. Donc, voilà comment rendre un site totalement inaccessible en 5 secondes: mettez un role=application sur le body et ne faites rien de plus. Tous les lecteurs d'écran n'auront plus que Tab et Maj+Tab pour pleurer... et encore, seulement si vous n'avez pas fait de bêtise avec tabindex.

La moralité de l'histoire, c'est que le rôle application n'est à utiliser que dans des cas vraiment très spécifiques. Si vous programmez une application web qui pourrait ressembler à une application native, si vous êtes capables de gérer adéquatement tous les aspects en détail de la navigation clavier, et si cette navigation est plus intuitive, plus rapide, plus simple et plus riche que la navigation de base proposée par les lecteurs d'écrans et autres aides techniques sur le web, alors, utilisez le mode application: votre application web ne pourra que en être meilleure, et ce mode est fait pour ça. Par contre, si vous ne programmez pas une application web qui pourrait se substituer ou être considérée comme une native, si vous n'êtes pas capables de gérer le clavier correctement jusqu'au bout, ou si c'est juste pour ajouter un ou deux raccourci isolé comme T pour rédiger un nouveau twitt en empêchant tous les autres raccourcis de navigation habituels, alors, abstenez-vous, car vous risquer de créer plus de problèmes que vous n'allez en résoudre.

Le mode application, c'est avant tout une chance: la chance de pouvoir faire sur le web des applications plus accessibles et plus user-friendly que jamais ! Mais c'est aussi une chance inouïe de produire une véritable catastrophe totalement inaccessible et inutilisable. S'il vous plaît, je vous en prie, rangez-vous du bon côté.

J'aimerais terminer en vous donnant un bon exemple, et un mauvais exemple que je connais bien.

Comme mauvais exemple, regardez où facebook et les forums du site du zéro (leur forum HTML/CSS, par exemple et comme par hasard) (à l'état du 02.10.2013) ont utilisé le mode application. Ils n'on't absolument rien assuré du tout derrière, ils auraient donc mieux fait de s'abstenir. Le mode application n'étant que dans des zones bien précises et pas sur le body, on peut encore en sortir en tabulant plusieurs fois; mais c'est une gêne extrêmement agaçante.

Le bon exemple, désolé mais il n'y en a pas 36.... le but n'est pas de faire de la publicité ni de me vanter, mais je suis obligé de vous donner le mien, car je n'ai tout simplement encore jamais trouvé une vraie bonne utilisation du mode application ailleurs sur le web: le client web du Salon.

Merci de m'avoir lu et à bientôt pour un autre article.