Évaluer des composants JavaScript avec un lecteur d’écran

Pourquoi ce guide ?

L’implémentation progressive de l’API ARIA, de 2008 à 2014, a considérablement amélioré l’accessibilité des composants développés avec JavaScript, mais a aussi singulièrement compliqué la tâche du développeur.

ARIA permet de standardiser les informations nécessaires à l’accessibilité par l’intermédiaire de propriétés transmises aux APIs d’accessibilité, notamment les comportements au clavier.

Mais ces composants – fenêtres modales, calendriers de saisie et autres systèmes d’onglets – qui ne reposent que sur ARIA pour pouvoir être utilisés correctement par les personnes en situation de handicap peuvent poser des problèmes de restitution.

L’essentiel de ces problèmes est dû à la prise en charge limitée de certaines propriétés ARIA par les navigateurs, mais surtout aux comportements quelquefois erratiques des lecteurs d’écrans eux-mêmes, mêmes si les éditeurs font de considérables efforts.

Cela conduit parfois à devoir modifier légèrement le modèle de conception proposé par l’API ARIA, ou à l’enrichir de propriétés destinées à améliorer sa restitution.

Enfin, et les développeurs en font un jour ou l’autre l’amère expérience, même si le modèle est parfaitement respecté, le composant n’est pas isolé dans la page et peut interagir avec d’autres éléments du contenu, ce qui peut provoquer d’autres problèmes de restitution.

Une obligation de tests de restitution

C’est la raison pour laquelle le RGAA exige que ces composants soient testés directement avec les lecteurs d’écran de la base de référence du RGAA 3 afin de s’assurer que tout se passera bien pour l’utilisateur final.

Ces tests ne sont pas triviaux, il faut apprendre à se servir des trois principaux lecteurs d’écran, apprendre à tester et savoir ce qu’on attend du point de vue des restitutions.

Une ressource indispensable

Ce guide répond à ces problématiques : comme toutes les ressources du RGAA, il est résolument pragmatique et pensé pour accompagner les débutants dans le monde merveilleux des lecteurs d’écran !

Il devrait se trouver à portée de main de toute personne, développeur, intégrateur ou testeur, soucieuse de l’accessibilité de ses contenus.

Présentation du guide

Comme chaque ressource d’accompagnement du RGAA, le guide comprend une introduction, qui explique le contexte du guide, à qui il s’adresse et quels sont les lecteurs d’écran concernés.

Les lecteurs d’écran traités par le guide sont donc Jaws et NVDA sous Windows ainsi que VoiceOver sous MacOS.

Dans cette introduction, le guide rappelle :

• ce qu’est un lecteur d’écran,
• quelles solutions de lecteurs d’écran existent pour chaque système d’exploitation
• et comment ils restituent l’information.

Une première partie décrit ensuite pas à pas comment installer et configurer chacun des trois lecteurs d’écran traités. En effet, chaque logiciel de lecture d’écran fonctionne différemment. Si deux d’entre eux doivent être téléchargés, car absents par défaut du système d’exploitation, le troisième se trouve sur chaque ordinateur fonctionnant sous MacOS. Chaque lecteur d’écran a ses propres raccourcis. Chacun a son propre mode de configuration.

Si, pour un utilisateur ordinaire, certains paramétrages n’ont pas d’importance, ils sont nécessaires pour permettre l’évaluation d’un composant donné. Par exemple, pour qu’un lecteur d’écran puisse vocaliser une info-bulle, il faut que, dans ses paramètres, la case permettant la vocalisation de cette info-bulle soit cochée.

La seconde partie du guide explique comment tester les différents composants JavaScript avec les trois lecteurs d’écran.

Il s’agit des 12 composants traités dans une autre ressource d’accompagnement du RGAA, la – Bibliothèque de référence Implémentation des composants ARIA.

Les composants présentés dans cette bibliothèque ont été développés pour tester les restitutions obtenues avec les modèles de conception ARIA, ils ont servis d’illustration pour décrire pas à pas la conduite d’un test.

Seul le composant pour l’auto-complétion est issu d’une autre ressource, car la restitution du composant autocomplete de la bibliothèque par les lecteurs d’écran n’était pas assez fiable.

Parmi les autres composants présentés dans ce guide, on retrouve :

• un potentiomètre, slider;
• une barre de progression (pour les téléchargements par exemple), progressbar;
• une fenêtre de dialogue modale, dialog;
• un système de navigation par onglets, tabpanel
• une info-bulle, tooltip;
• des boutons (avec l’indication s’ils sont activables ou non), button;
• des exemples de cases à cocher, checkbox;
• une barre de menus, similaire à celles qu’on trouve dans une application classique, menubar;
• un système d’accordéon, accordeon;
• une arborescence que l’on peut développer ou réduire, tree;
• un sélecteur de date datepicker.

Chaque composant est tout d’abord présenté de façon générique, c’est-à-dire comment l’utiliser à l’aide du clavier et comment il doit être restitué. Pour chaque lecteur d’écran, les manipulations au clavier sont décrites étape par étape et il est indiqué ce que le lecteur d’écran est censé vocaliser. Il se peut qu’en fonction du paramétrage du lecteur d’écran, certaines restitutions diffèrent légèrement.

Informations complémentaires

Comme tous les autres guides, ce document est disponible pour consultation et téléchargement sur le Compte Github de la Dinsic. Il est sous licence ouverte 1.0 ou ultérieure, équivalente à une licence Creative Commons BY.

Vous pouvez faire part de vos retours et remarques par l’intermédiaire de la plateforme Github : Guide lecteurs d’écran.