Introduction à l’accessibilité de JavaScript

Par James Edwards

Il fut un temps où l’accessibilité de JavaScript signifiait simplement assurer une dégradation élégante lorsque JavaScript n’était pas disponible. Mais, avec la percée d’Ajax et des Applications Internet Riches (RIA), JavaScript n’est plus seulement utilisé pour améliorer l’utilisabilité à la marge, il constitue désormais la base des applications web. De nos jours, parler de l’accessibilité de JavaScript c’est s’assurer que le code JavaScript est accessible en lui-même.

Ce que nous réserve l’avenir

Le protocole d’accessibilité des applications Internet riches (NdT : ARIA en anglais, pour Accessible Rich Internet Applications) est une des évolutions les plus importantes de ces dernières années dans l’accessibilité web. Il a été conçu par le groupe Initiative pour l’Accessibilité du Web (WAI) et définit une sémantique permettant de rendre le contenu interactif accessible aux technologies d’assistance telles que les lecteurs d’écran. WAI-ARIA est apparu par nécessité, l’explosion du Web 2.0 s’étant faite presque sans aucune considération d’accessibilité. JavaScript est désormais utilisé dans le code d’applications web critiques et les technologies d’assistance doivent donc impérativement pouvoir interpréter le contenu dynamique.

Aujourd’hui

Malheureusement, ARIA n’est pas encore très bien pris en charge. Seules les dernières versions des (très coûteux) lecteurs d’écran offrent un début de prise en charge, et aucun d’entre eux ne l’offre intégralement. De plus, ce qui est supporté n’est pas forcément bien implémenté. Et même quand ARIA sera largement pris en charge, ce ne sera pas pour autant la réponse à tout car l’accessibilité de JavaScript ne se résume pas à ce qui est défini par ARIA. Pour que les fondations de ce protocole soient solides, elles doivent associer une véritable compréhension du besoin utilisateur et des développements basés sur les standards.

Sitepoint va consacrer plusieurs articles à l’accessibilité de JavaScript. Nous commençons par un aperçu des choses simples que vous pouvez faire dès à présent pour rendre votre JavaScript plus accessible. Plus tard, nous entrerons plus en détails dans le monde d’ARIA. Mais avant toute chose, nous devons revoir quelques concepts théoriques

Le cœur de l’accessibilité

L’accessibilité de JavaScript peut être divisée en trois grands groupes de besoins utilisateurs. Ce chapitre décrit ces groupes de manière détaillée.

Les utilisateurs de technologies d’assistance

Le premier groupe comprend les personnes qui utilisent des lecteurs d’écran, plages Braille ou d’autres aides techniques de ce genre. Les aveugles sont majoritaires dans ce groupe, mais il inclut également les personnes souffrant de handicaps visuels ou cognitifs, pour qui les lecteurs d’écran facilitent la lecture et la compréhension.

Les technologies d’assistance présentent toutes les informations sous forme de texte structuré. Par conséquent, toutes les fonctionnalités JavaScript doivent adopter une forme qui puisse être présentée textuellement. Une barre de progression scriptée telle qu’illustrée ci-dessous fournit des informations visuelles, elle devrait donc être complétée par un texte fournissant les mêmes informations.

Une barre de progressions dont la position, 76%, est indiquée visuellement et à l’aide d’un nombre en pourcentage.

Le texte en lui-même ne suffit pas, s’il ne possède pas de structure ou de liaisons interprétables par les technologies d’assistance. Un texte est souvent structuré de façon très simple, sous forme de listes et de tableaux. Les technologies d’assistance comprennent aisément ce type de structure, il ne nous reste donc qu’à les utiliser correctement.

En utilisant par exemple des listes non ordonnées et des libellés de structure comme base d’un menu déroulant, les technologies d’assistance peuvent interpréter le sens à partir de la sémantique et de la hiérarchie de ces éléments. Nous pouvons également construire des widgets de calendrier où chaque mois est représenté par un tableau HTML. Il suffit alors de déclencher son affichage par un bouton et de le décrire à l’aide d’une légende. Une sémantique solide des éléments doit constituer la base de tout contenu interactif.

Les utilisateurs qui naviguent au clavier

Le deuxième groupe est formé par les personnes qui utilisent uniquement le clavier. Ce groupe comprend les non-voyants utilisant un lecteur d’écran, mais également les personnes voyantes qui ne peuvent pas utiliser la souris en raison d’un handicap moteur, ainsi que les personnes ayant une déficience cognitive et pour suivre les éléments qui possèdent le focus aide à se concentrer. Pour s’adapter aux besoins de ce groupe, toutes les fonctionnalités JavaScript doit être accessibles au clavier. Les interactions par exemple doivent être limitées aux touches les plus intuitives : tabulation, les flèches, la touche Entrée et la touche d’échappement.

La prise en charge du clavier se fait souvent à moindre coût, pour peu que vous partiez du principe que le meilleur événement est toujours celui qui est le plus indépendant du périphérique. Ainsi, la validation du formulaire doit être liée à l’événement submit du formulaire, tandis que les événements d’activation primaires devraient être liés à l’événement clic universel, plutôt que des événements spécifiques comme mousedown, touchstart ou KeyDown.

Pour les interactions plus complexes, il est souvent nécessaire de combiner les événements. Les Règles d’Accessibilité pour les Contenus Web (NdT : Web Content Accessibility Guidelines, ou WCAG en anglais) parlent d’association d’événements : il s’agit de coupler les événements souris avec leur équivalent clavier le plus similaire. Un exemple est le couplage des événements mousedown et keydown. Ce n’est toutefois pas la bonne façon de voir les choses car on se concentre ici sur la technique plutôt que sur la finalité d’une action. Tant que l’objectif est atteint, peu importe que les modalités au clavier soient totalement différentes de l’action à la souris.

Pour le glisser-déposer par exemple, il n’y a pas d’équivalent à l’événement mousemove, mais nous pouvons quand même rendre cette fonctionnalité accessible au clavier. Il s’agit en fait de deux interactions distinctes. La première permet de déplacer des éléments vers le haut ou le bas pour les réorganiser, ce qui peut tout simplement se faire grâce aux flèches haut et bas. La seconde interaction concerne l’action d’attraper et de déplacer, pour déplacer des fichiers d’un dossier à un autre par exemple. Cela peut se faire par exemple avec la touche Espace pour sélectionner l’élément, la touche Tabulation pour sélectionner la destination, et la touche Entrée pour déposer.

Lorsque des touches non-standard sont utilisées, un texte d’accompagnement devrait figurer pour l’expliquer. Dans les faits, certaines interactions seront immanquablement plus compliquées que leur équivalent à la souris. Mais ce n’est pas bien grave, du moment que le résultat est atteignable. L’accessibilité c’est l’équivalence, pas l’égalité.

Une autre considération importante concernant l’accessibilité au clavier est de garder un ordre logique du contenu. Des bulles d’aide enrichies, par exemple, doivent être insérées immédiatement après l’élément qu’elles concernent pour qu’on y accède directement en tabulant une seule fois, et afin que les lecteurs d’écran puissent les lire dans la foulée.

Les utilisateurs sensibles au clignotement ou aux limites de temps

Le dernier groupe comprend les personnes sensibles aux clignotements ou aux brusques changements de luminosité, ou qui ne peuvent pas réagir aux événements en temps réel comme les autres. Le contenu clignotant affecte les personnes souffrant d’une épilepsie photosensible, chez qui cela peut provoquer une crise, ainsi que les personnes souffrant de déficience cognitive, qui ont du mal à se concentrer lorsque les choses bougent dans leur vision périphérique. Les limitations sur les contenus qui clignotent sont assez bien formulées par les règles d’accessibilité pour les contenus web et synthétisées par le seuil de trois clignotements maximum.

Les limites temporelles peuvent également s’avérer problématiques car écouter un contenu vocalisé prend plus de temps que de le lire. Naviguer au clavier prend également plus de temps qu’à la souris. De ce fait, les actions JavaScript basées sur le temps doivent être contrôlables par l’utilisateur. Les limites sur des activités temporelles ne sont pas trop spécifiques, car il y a différents cas de figure à prendre en considération.

Le grand principe pour les limites temporelles est que si une activité doit être effectuée dans un certain laps de temps, l’utilisateur est prévenu quand la limite est sur le point d’expirer et se voit proposer une façon de la rallonger. Par exemple, un site de banque en ligne peut avoir des limites de temps strictes sur l’inactivité de session, mais l’utilisateur doit pouvoir l’allonger à l’aide d’un simple dialogue de confirmation (comme ceux qu’on peut voir sur les guichets automatiques qui vous demandent si vous avez besoin de davantage de temps).

Lorsque du contenu est animé, l’animation ne devrait pas durer plus de cinq secondes, à moins que l’utilisateur ait un moyen de la contrôler. Une animation peut être purement décorative, la limite de temps est donc utile pour les personnes qui souffrent de déficience cognitive et pour qui une animation continue en périphérie rend plus difficile le fait de se concentrer sur le contenu principal.

Pour une animation telle que le défilement ou le déplacement d’un contenu, la restriction impose de permettre aux utilisateurs de terminer leur tâche sans changements de contexte inattendus. Un lecteur d’actualités qui défile automatiquement par exemple devrait avoir un bouton pause, pour laisser l’utilisateur lire chaque actualité à son propre rythme et en étant assuré que les choses ne bougeront pas pendant qu’il la lira ! Cela est également valable lorsque de grands blocs de contenus ou des pages entières sont automatiquement rechargés. C’est très courant sur les sites de bourse en ligne ou de résultats sportifs. Vous ne devriez jamais faire cela, à moins de fournir des contrôles spécifiques à l’utilisateur sur la fréquence de rafraîchissement (qui devrait être à never (jamais) par défaut).

Mais les limites temporelles font souvent partie intégrante des activités pour lesquelles elles sont utilisées. Beaucoup de jeux comportent intrinsèquement des limites de temps et les supprimer nuirait au principe même du jeu. Dans de tels cas, on peut dire que le contenu ne peut être rendu accessible sans changer sa signification. Les règles d’accessibilité autorisent cette possibilité, du moment que le contenu est clairement décrit comme tel.

Conclusion

Nous venons de voir que l’accessibilité de JavaScript peut se résumer à trois principes fondamentaux.

La prochaine fois, nous nous éloignerons de la théorie, pour voir quelques petites choses simples mais pratiques que vous pouvez mettre en œuvre dès à présent pour rendre une fonctionnalité JavaScript plus accessible. Et nous ne parlons pas de techniques à peine prises en charge, non testées ou avant-gardistes mais bien de ce que nous faisons déjà depuis des années.


http://www.sitepoint.com/javascript-accessibility-101/

Fiche technique

À propos de l'auteur

James Edwards alias Brothercake est un développeur web freelance basé au Royaume-Uni, et spécialisé dans les programmations DHTML avancées, ainsi que dans le développement de sites web accessibles. A la fois avocat passioné et sobre modérateur, il est aussi l’auteur du premier menu accessible.

Article du même auteur

Articles similaires

Voici la liste des dix articles les plus récents en rapport avec cet article :

Accessibilité

JavaScript

© 2001-2024 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! - RSS / ATOM - About this site