Un ticket pour accéder aux interfaces Web

Apprendre à communiquer avec les développeurs, par la compréhension des failles d’accessibilité des composants graphiques.

Introduction

Aujourd’hui, nous allons traiter un sujet très peu évoqué et mal connu, qui concerne tous ceux qui utilisent une revue d’écran, que ce soit JAWS et NVDA sur PC, Voice Over sur les produits Apple, ou encore Talk back sur le système Android. Il s’agit de vous donner les clés pour comprendre les causes des blocages qu’on rencontre, notamment sur un site internet qui a des failles d’accessibilité, et, si on prend en considération le fait que les sites ou les applications WEB parfaitement accessibles se comptent sur les doigts d’une main, on prend rapidement conscience de l’importance de comprendre d’où viennent ces blocages, et ce, afin de trouver des moyens de contournement s’ils existent et à défaut, de pouvoir transmettre le bon diagnostic aux personnes responsables du bon fonctionnement de ces interfaces graphiques. C’est justement ce point précis qui est au cœur de notre sujet.

En effet, dans nos métiers de consultants en accessibilité et d’experts en aides techniques, où nous sommes amenés à adapter des sites internet ou des applications métier pour les rendre utilisables par des employés aveugles ou malvoyants, nous constatons à chaque fois qu’il y a un fossé infranchissable entre les utilisateurs des revues d’écran et les développeurs des interfaces graphiques. Ce fossé existe parce que d’une part, les développeurs ne peuvent pas se mettre à la place des utilisateurs non-voyants, ne connaissant rien du fonctionnement des synthèses vocales, et d’autre part, les utilisateurs ne peuvent pas transmettre le problème de manière suffisamment précise pour que les développeurs en tirent des consignes techniques, ce qu’on appel dans le jargon du développement un Ticket.

Pour faire court, les principaux acteurs tentent d’établir un dialogue, alors qu’ils ne parlent pas la même langue.

Cette situation a parfois des conséquences dramatiques au sein des entreprises, des salariés se retrouvent au chômage technique pendant des semaines, ou sont affectés de services en services tels des patates chaudes qu’on se refile, et même si les développeurs tentent de remédier au problème, après une attente toujours trop longue, la solution apportée reste souvent insuffisante, voire contre-productive.

Finalement, notre objectif, c’est de vous donner des outils pour construire un pont et franchir ce fossé entre les utilisateurs d’aides techniques et les développeurs, ce qui se matérialise par l’élaboration de ce fameux ticket, qui est, rappelons-le, un ensemble de consignes destinées aux développeurs, visant à corriger le problème rencontré par l’utilisateur.

Un dernier point à préciser, ce tutoriel est destiné à tout le monde, aucune connaissance technique n’est requise pour bien comprendre, le seul pré requis demandé, c’est d’avoir déjà utilisé une interface graphique, une page internet, une boîte email, etc.. Si vous lisez cet article depuis votre téléphone ou votre ordinateur, c’est que vous avez tout ce qu’il faut pour tout assimiler et si vous avez des questions, n’hésitez pas à nous les poser, nous y répondrons avec plaisir.

Après cette longue mais nécessaire introduction, nous allons aborder le vif du sujet.

L’interface graphique

Prenons une définition triviale sur Wikipédia, et essayons d’en extraire les informations essentielles.

« En informatique, une interface graphique est un dispositif de dialogue homme-machine, dans lequel les objets à manipuler sont dessinés sous forme de pictogrammes à l’écran, de sorte que l’usager puisse les manipuler avec un dispositif de pointage, le plus souvent une souris ».

La première phrase à retenir est la suivante : « dispositif de dialogue homme-machine », autrement dit, une interface graphique vous permet de donner des instructions à un ordinateur à travers un logiciel ou un navigateur internet, c’est ce qu’ils appellent la « machine », qui elle, nous restitue les résultats de nos requêtes.

Passons à la deuxième phrase qui est : « objets à manipuler dessinés sous forme de pictogrammes ». Ce qu’ils appellent pictogrammes nous allons les appeler composants graphiques. Ce sont tous les objets avec lesquels on peut interagir pour donner des instructions à la machine. Voici les plus répandus :

• Les boutons ;
• Les champs d’édition ;
• Les liens ;
• Les cases à cocher etc.

La dernière phrase à retenir est la suivante : « dispositif de pointage ». Ce sont tous les outils qui permettent de manipuler l’interface graphique, donc, d’interagir avec les composants graphiques. Le plus utilisé est la souris, mais dans notre cas nous allons nous intéresser uniquement au clavier, car les non-voyants utilisent exclusivement ce dernier pour interagir avec les interfaces.

Nous pouvons dors est déjà tirer une première conclusion importante quant aux conditions nécessaires à l’accessibilité d’une interface graphique, la voici :

Tout composant graphique doit fonctionner au clavier sans utiliser la souris. Sachez que 90% des failles d’accessibilité sont induites par la nécessité d’utiliser une souris.

L’idée que l’utilisation de la souris ne soit que facultative perturbe énormément les concepteurs et les développeurs, tant ils ont l’habitude de se baser sur des modalités visuelles.

Il existe d’autres dispositifs de pointage utilisés par les non-voyants, que les développeurs doivent prendre en compte, au même titre que le clavier.  L’écran tactile en est un, nous n’allons pas développer davantage cet aspect, mais il rentre en ligne de compte, pour l’élaboration de notre fameux ticket.

Maintenant que nous avons établi un langage commun, à travers ces différentes définitions, nous allons passer à la méthodologie de diagnostic des failles d’accessibilité d’un composant graphique. Pour dire les choses plus simplement, nous allons voir quelles sont les conditions nécessaires pour qu’un composant graphique soit accessible. Accessible dans notre cas, vous l’aurez compris, est le fait qu’une interface graphique soit utilisable via une revue d’écran.    

Principe de la méthode LIRE

Le principe que nous allons énoncer est suffisamment simple pour le mémoriser, il vous permettra de diagnostiquer la cause de dysfonctionnement d’un composant graphique, lorsque vous utilisez une revue d’écran.

Il se résume en quatre critères fondamentaux, qui sont le label, l’interaction, le rôle et l’état. Ce qui donne en initiales le mot LIRE, une belle mnémotechnique pour retenir ces critères. Voyons ensemble à quoi ils correspondent.

Le label

Le label est généralement un bout de texte qui sert d’intitulé à un composant graphique et qui renseigne sur sa fonction. Sa présence est obligatoire. Aussi, le label doit être explicite, c’est-à-dire qu’il ne doit pas engendrer d’ambiguïté quant à la fonction du composant graphique.

L’interaction

L’interaction est la façon dont un composant graphique réagit aux touches du clavier. L’interaction est intimement liée au rôle, car chaque type de composant graphique est prévu pour être activé par certaines touches ou combinaison de touches du clavier. Voici quelques exemples :

Composant graphique (rôle)	Interaction
Valider un bouton	Entrée ou barre espace
Cocher une case à cocher	Barre espace
Sélectionner un bouton radio	Flèches gauche et droite
Ouvrir une liste déroulante	Alt + Flèche bas
Fermer une liste déroulante	Alt + Flèche haut ou Échap

Le rôle

Le rôle est donné par la revue d’écran, il renseigne la revue d’écran sur la nature ou le type du composant graphique. Sans les rôles, un utilisateur ne pourrait pas naviguer en allant d’un bouton à un autre ou de titre en titre par exemple. Le rôle doit également être en adéquation avec le type du composant. Par exemple, il arrive souvent qu’on assigne a un lien le rôle d’un bouton, alors que le lien renvoie vers une autre page.

L’état

Le changement d’état d’un composant graphique doit être donné aux utilisateurs pour savoir par exemple si une liste déroulante est ouverte ou fermée, si un menu déroulant est étendu ou réduit ou encore si une case est cochée ou non.

Exemple

Prenons un bouton de menu d’un site internet. Quand le curseur d’une revue d’écran se positionne sur un tel composant, la synthèse va énoncer le nom du bouton “Menu” puis ajoute le mot “bouton” puis une troisième information va être énoncée qui est “réduit”. Ce qui donne l’énoncé suivant “Menu, bouton, réduit”, Le premier mot est le label, le deuxième, le rôle et le troisième est l’état du bouton de menu.  Le label nous permet de connaître la fonction du composant graphique et le rôle du composant est un bouton, ce qui nous permettra de savoir comment interagir avec ce bouton de menu (avec la touche Entrée).

L’état réduit du bouton de menu nous permet quant à lui de savoir si le menu est ouvert ou fermé. Pour l’instant, tout est parfait, il ne reste plus qu’à vérifier si l’interaction est en adéquation avec le rôle. Si le bouton s’ouvre et se ferme en utilisant la touche Entrée et que l’état du bouton change en fonction de cela, alors on peut dire que ce composant graphique respecte les 4 critères de l’accessibilité.

Établir le ticket

Maintenant que vous pouvez diagnostiquer un composant graphique, nous allons voir sous quelle forme doit-on écrire le ticket et ce qu’il contient. Je vous rassure, il n’y a rien de bien compliqué à l’horizon.

Comme nous l’avons expliqué auparavant, un ticket est une liste d’instructions concernant des modifications à apporter sur des composants graphiques qui présentent des failles d’accessibilité, dans le but d’identifier le problème afin qu’il soit corrigé. Il s’agit d’un document destiné aux personnes responsables du bon fonctionnement de l’interface graphique.

Le ticket doit permettre au développeur de :

1. Cibler le composant graphique à corriger ;
2. Comprendre la cause du dysfonctionnement ;
3. Disposer d’instructions ou de recommandations pour remédier au problème.

Ces trois informations peuvent être structurées de deux manières. En forme de tableau, avec une colonne pour chaque information et une ligne par composant graphique. Au format CSV, ce format est très simple à mettre en place, il suffit de séparer les trois informations par des virgules, on aura ainsi une ligne par composant à corriger, ces lignes devront être séparées par des points virgules. Ce format est très pratique car on peut très facilement le transformer en tableau. En voici un exemple :

Bouton de menu principal, label absent, ajouter le label “Menu” ;

Bouton Panier (page principale), interaction au clavier inadéquate, rendre le bouton activable avec Entrée et barre espace ;

Voilà c’est fini, vous savez tout, ce n’était pas si compliqué n’est-ce pas ?

Travaux pratiques

Alors, maintenant que vous êtes au point en termes de connaissances, nous allons mettre tout cela en pratique, histoire de vous entraîner un peu, en prenant des exemples concrets et à la fin de vos tests, vous mettrez votre diagnostic (vos tickets) dans la section commentaire. Prêt ? C’est parti !

Je vous ai concocté quelques composants graphiques qui comportent des failles d’accessibilité courantes. Pour y accéder, vous n’aurez qu’à télécharger le fichier suivant : Exemples de composants graphiques et l’ouvrir avec votre navigateur préféré.

Une précision importante pour terminer. La méthode exposée ici n’a pas la prétention de se substituer à un audit professionnel, ni d’englober tous les critères des normes d’accessibilité, mais plutôt de vous aider à mieux appréhender les problèmes que vous pouvez rencontrer au travail ou dans la vie de tous les jours face à une interface WEB inaccessible. Elle vous permettra aussi de communiquer votre expérience d’utilisateur de manière objective avec un langage compréhensible par les techniciens.

Nous espérons que cet article vous aura plu et qu’il vous sera utile dans votre utilisation des aides techniques. N’oubliez pas de nous envoyer vos tickets !

Voir la vidéo « Comprendre les failles d’accessibilité des sites web avec la méthode L.I.R.E »

Écouter et télécharger le podcast

Podcast: Download (32.7MB) | Embed