Par Guillaume D’Amour, animateur-coordonnateur

Introduction

Le Laboratoire d’expérimentation et de promotion de l’accessibilité du Web est fier de vous présenter les résultats très concluants de la fin de sa première phase d’activités. Dans ce rapport final, vous aurez d’abord un résumé du déroulement du projet. Ensuite, suivra une synthèse de chacun des tests effectués, après quoi les indicateurs du projet seront présentés.  Par la suite, vous pourrez lire le rapport financier. Finalement, nous présenterons nos objectifs pour la deuxième phase du projet. Pour plus d’informations sur le Laboratoire, visitez le site Internet : https://labo.raamm.org/

 

Déroulement du projet

Le Laboratoire a débuté ses activités le 30 avril 2015. L’objectif principal du Laboratoire d’expérimentation et de promotion de l’accessibilité du Web est de tester des composants de la Boite à outils de l’expérience Web. Nous avons donc conçu un site Web comme plateforme de tests pour nos groupes d’utilisateurs et d’experts. Ils sont invités à se rendre sur le site, environ une fois par mois, pour effectuer un test sur un composant spécifique. Il leur est permis de tester sur plusieurs environnements, et c’est pourquoi certains testeurs produisent plusieurs rapports de tests. Une fois le test complété, une synthèse est produite par notre animateur-coordonnateur, et des recommandations d’améliorations sont tirées de cette synthèse afin de permettre à la Boite à outils de l’expérience Web de rendre leurs composants plus accessibles. Nous avons testé huit composants lors de la première phase du Laboratoire.

Test 1 : Le Menu

Nous avons donné à nos groupes de testeurs du 18 juin au 3 juillet 2015 pour effectuer le test du Menu. 25 utilisateurs et 12 experts ont participé en produisant 46 rapports de tests. Nous avons recueilli quelques commentaires d’utilisateurs :

• « Il serait très agréable que la synthèse vocale se comporte aussi bien sur les sites Web. »
• « Très heureuse de pouvoir contribuer à l’amélioration des accès sur Internet. »
• « J’étais nerveuse, car je ne suis pas une professionnelle de l’informatique. J’ai pris beaucoup de temps à lire ce qui m’a été demandé à exécuter. Quand j’ai eu terminé, je trouvais l’examen facile à faire. »

Voici un résumé des problématiques et recommandations. Pour plus d’informations, visitez le lien : https://labo.raamm.org/test-1-rapport/

Problématique 1

Les composants de la Boîte à outils sont sous-imbriqués les uns dans les autres. Le processus d’extraction d’un composant est donc long et complexe.

Recommandation 1

Rendre plus facile l’utilisation des composants indépendamment les uns des autres, afin de permettre l’intégration d’un composant seul, sans avoir à implémenter l’ensemble des outils proposés en même temps.

Problématique 2

Ce n’est pas le fonctionnement du composant comme tel qui est fautif, mais un manque de connaissance de la part des utilisateurs.

Recommandation 2

Il nous apparait important de rendre disponible de l’aide contextuelle, afin de guider les utilisateurs peu expérimentés dans leurs opérations. 

Problématique 3

Plusieurs testeurs nous ont indiqué avoir éprouvé de la difficulté à revenir facilement au menu, après avoir sélectionné un élément les dirigeant vers le contenu de la page.

Recommandation 3

Il serait utile d’ajouter une commande permettant de facilement revenir au menu.

Problématique 4

Des comportements de perte de focus ont été relevés sur VoiceOver, iPhone et iPad.

Recommandation 4

Il faudrait que la Boite à outils de l’expérience Web prenne en charge cet environnement, au même titre que Windows.

Test 2 : Les Onglets

Nous avons donné à nos groupes de testeurs du 2 au 19 octobre 2015 pour effectuer le test des Onglets. 15 utilisateurs et 11 experts ont participé en produisant 51 rapports de tests. Nous avons recueilli quelques commentaires d’utilisateurs :

• « Heureusement que vous avez précisé qu’après avoir activé un onglet, il fallait désactiver le mode interactif avec la touche plus. Je l’aurais probablement découvert, mais ça m’a facilité la tâche. »
• « J’ai bien aimé cette expérience. »

Voici un résumé des problématiques et recommandations. Pour plus d’informations, visitez le lien : https://labo.raamm.org/test-2-rapport/

Problématique 1

Jaws ne mentionne pas d’emblée la présence d’onglets dans la page, ce qui peut rendre la navigation plus complexe. Il y a un manque de clarté au niveau des messages d’entrée du panneau d’onglets.

Recommandation 1

Ajouter, dans le sommaire de la page, la présence d’onglets ou d’autres éléments interactifs. Programmer la sortie automatique du mode formulaire dès que l’onglet est sélectionné. Modifier le message de début du panneau d’onglet.

Problématique 2

NVDA ne mentionne pas le début et la fin du panneau d’onglets, ce qui rend difficile la navigation.

Recommandation 2

Il faut que NVDA mentionne le début et la fin du panneau d’onglets.

Problématique 3

Pour iOS, il faudrait trouver une façon d’indiquer à l’utilisateur qu’il s’agit d’onglets sachant que VoiceOver n’en fait pas la mention. Le focus est très mal géré par VoiceOver sur iPad.

Recommandation 3

Tester l’utilisation d’onglets « focussables » et contacter Apple pour voir comment on pourrait améliorer la gestion du focus.

Test 3 : La Validation de formulaire

Nous avons donné à nos groupes de testeurs du 16 au 30 novembre 2015 pour effectuer le test de la Validation de formulaire. 13 utilisateurs et 12 experts ont participé en produisant 43 rapports de tests. Nous avons recueilli quelques commentaires d’utilisateurs :

• « Il serait bien que tous les sites utilisent cette approche. C’est la première fois que je rencontre une façon aussi simple de remplir un formulaire. »
• « Je me suis bien amusé en faisant apparaitre et disparaitre les messages d’erreur. »
• « Je l’ai trouvée intéressante et surtout pratique, car c’est une situation que l’on rencontre de plus en plus fréquemment. »

Voici un résumé des problématiques et recommandations. Pour plus d’informations, visitez le lien : https://labo.raamm.org/test-3-rapport/

Problématique 1

Les erreurs liées à un champ précédent sont mentionnées après la lecture du label du champ suivant. Si une erreur est commise, l’attention de l’utilisateur devrait être attirée plus rapidement. Une fois que la lecture du label du champ suivant est terminée, l’utilisateur peut commencer à écrire immédiatement, ce qui fera en sorte qu’il n’entendra pas nécessairement le texte de l’erreur.

Recommandation 1

Il faudrait donc que l’erreur soit mentionnée avant la lecture du champ suivant. Il faudrait également une indication claire, à savoir dans quel champ on se trouve au moment de la correction.

Problématique 2

Il existe un problème de stabilité avec Jaws 14. Il ne mentionne pas nécessairement les erreurs commises au fur et à mesure. Il faut parfois attendre la liste des erreurs après avoir envoyé une première fois le formulaire.

Recommandation 2

Il faudrait que Jaws 14 soit capable de reconnaitre et d’avertir l’utilisateur des erreurs de champ, en cours de route.

Test 4 : Les Boites de dialogue

Nous avons donné à nos groupes de testeurs du 29 janvier au 11 février 2016 pour effectuer le test des boites de dialogue. 18 utilisateurs et 8 experts ont participé en produisant 62 rapports de tests. Nous avons recueilli quelques commentaires d’utilisateurs :

• « Expérience très intéressante. Je n’ai jamais osé faire des transactions sur le Net. Cela m’a permis de me familiariser avec cette notion sans craindre. »
• « J’ai tendance à penser que les choses sont plus compliquées qu’elles le sont dans la réalité. »
• « Simple d’utilisation et facile à comprendre. »

Voici un résumé des problématiques et recommandations. Pour plus d’informations, visitez le lien : https://labo.raamm.org/test-4-rapport/

Nous avons rencontré plusieurs difficultés avec le composant de la Boite à outils de l’expérience Web :

• Le dialogue n’est pas identifié comme tel. La mention « document » donnée par JAWS n’est pas claire.
• L’utilisateur de JAWS n’est pas restreint au contenu de la Boite de dialogue et peut continuer à lire le contenu de la page à la fin de la Boite de dialogue. Les commandes de listes (de liens, de titres, etc.) donnent aussi accès au contenu du reste de la page, ce qui ne permet pas à l’utilisateur de distinguer le contenu du dialogue, auquel il doit répondre, du reste du contenu de la page.
• On ne peut pas fermer le dialogue avec la touche échappement.

Nous avons donc cherché une meilleure solution et avons utilisé la Boite de dialogue de l’Accessible Modal Dialog. Voici le lien pour plus d’informations : http://github.com/gdkraus/ accessible-modal-dialog

Problématique 1

Il est important que le dialogue soit visible dans l’écran, sinon les boutons ne sont pas accessibles.

Recommandation 1

Permettre aux boites de dialogue le défilement de leur contenu, vers le bas. On peut ainsi atteindre le bouton et fermer la Boite de dialogue même si le contenu de celle-ci, de prime abord, dépasse les marges de l’iPhone.

Problématique 2

En fermant la boite, le focus retourne au début de la page

Recommandation 2

Un retour à l’élément a été ajouté, quand on quitte la boite de dialogue.

Problématique 3

Il n’est pas possible de fermer la boite de dialogue facilement.

Recommandation 3

Il est maintenant possible de fermer les boites de dialogue avec la touche Échappement, pour une plus grande facilité d’utilisation.

Test 5 : L’Accordéon

Nous avons donné à nos groupes de testeurs du 19 février au 2 mars 2016 pour effectuer le test de l’Accordéon. 19 utilisateurs et 8 experts ont participé en produisant 49 rapports de tests. Nous avons recueilli quelques commentaires d’utilisateurs :

• « J’ai l’impression de me faire jouer un tour tellement j’ai trouvé cela facile »
• « Dans le Laboratoire, tout marche très bien »

Voici un résumé des problématiques et recommandations. Pour plus d’informations, visitez le lien : https://labo.raamm.org/test-5-rapport/

Nous avons développé une solution maison en corrigeant les problématiques rencontrées dans le modèle d’alerte repliable de la BOEW. Autrement dit, nous avons adapté le composant d’accordéon du framework Bootstrap pour le rendre accessible selon nos analyses. La nouvelle structure (code source) proposée peut être consultée ici : http://jsfiddle.net/kcvLx0ju/2/

En résumé :

• Nous avons utilisé des titres pour identifier chaque item d’Accordéon.
• Chacun des titres comporte un bouton permettant de déployer le contenu de l’item.
• Des attributs permettent d’identifier si les items sont ouverts ou fermés.
• Lorsqu’un item d’Accordéon est ouvert, le focus du lecteur de l’écran est automatiquement déplacé au début de son contenu.

Test 6 : Les Notes de bas de page

Nous avons donné à nos groupes de testeurs du 23 mars au 6 avril 2016 pour effectuer le test des Notes de bas de page. 16 utilisateurs et 9 experts ont participé en produisant 48 rapports de tests. Nous avons recueilli quelques commentaires d’utilisateurs :

• « Je ne vois pas comment on pourrait simplifier davantage une telle démarche »
• « L’objet du test m’inquiétait, mais ce fut plus facile que ce à quoi je m’attendais »
• « Test intéressant et utile. Le sujet choisi m’a accroché au point qu’il m’a incitée à lire tout l’article. »
• « Utile d’offrir de l’aide! »

Voici un résumé des problématiques et recommandations. Pour plus d’informations, visitez le lien : https://labo.raamm.org/test-6-rapport/

Problématique 1

Jaws et NVDA annoncent six éléments dans la liste des notes, ce qui porte à confusion puisqu’il n’y a que trois notes.

Recommandation 1 

Notre solution est de remplacer les balises de listes de définition par des balises de listes à puce. Suppression des dl, dt, dd et remplacement par des ul, li.

Problématique 2

Une fois dans la liste des notes, après avoir sélectionné l’appel de note, les lecteurs d’écran lisent le numéro de la note, le texte de la note, ainsi que le lien de retour de la note. Pourtant, il n’est pas possible d’activer le retour sur la note sans appuyer de nouveau sur la flèche vers le bas, afin de trouver réellement le lien de retour sur la note.

Recommandation 2 

Puisqu’il y a confusion, nous intégrons la balise identifiant la note dans une balise paragraphe. Le lien mène maintenant vers le premier <p> de la note de bas de page. Le id est maintenant dans ce <p>.

Problématique 3

Lorsque l’on sélectionne le lien de retour dans la note de bas de page, le focus est amené sur la balise du numéro exposant de la note.

Recommandation 3 

Il faudrait changer la cible du retour à la référence qui se fait maintenant sur le lien de départ, plutôt que l’exposant. Le retour à la référence se fait maintenant sur la balise <a>, et non sur la balise <sup>.

Problématique 4

Le focus retourne toujours à la première occurrence, lorsqu’il y a plusieurs liens qui mènent à la même note.

Recommandation 4 

Permettre au composant de reconnaitre les multiples occurrences d’une même note et de pouvoir retourner au lien de départ approprié.

Test 7 : Le Calendrier d’événements

Nous avons donné à nos groupes de testeurs du 4 au 18 mai 2016 pour effectuer le test du Calendrier d’événements. 17 utilisateurs et 10 experts ont participé en produisant 48 rapports de tests. Nous avons recueilli quelques commentaires d’utilisateurs :

• « Je ne suis pas une adepte des calendriers virtuels, mais présentés de cette façon, j’ai trouvé cela intéressant »
• « C’était très facile, il faut dire que vous aviez donné les commandes pour se déplacer »

Voici un résumé des problématiques et recommandations. Pour plus d’informations visitez le lien : https://labo.raamm.org/test-7-rapport/

Problématique 1

Il est difficile de quitter le calendrier pour aller directement au contenu de la page.

Recommandation 1

Permettre de quitter le calendrier avec la touche ESC.

Problématique 2

Une fois dans la liste des événements du calendrier, il faut retourner au début du calendrier pour y avoir accès.

Recommandation 2

Ajouter des boutons permettant de revenir aux événements dans le calendrier.

Problématique 3

Lorsque l’on entre dans le calendrier, ce dernier est nommé comme tableau.

Recommandation 3

Mentionner « calendrier » plutôt que « tableau » lorsque l’on navigue sur le composant.

Test 8 : L’Aide contextuelle

Nous avons donné à nos groupes de testeurs du 18 au 28 juin 2016 pour effectuer le test de l’Aide contextuelle. 13 utilisateurs et 7 experts ont participé en produisant 43 rapports de tests. Nous avons recueilli quelques commentaires d’utilisateurs :

• « C’est une excellente façon de fonctionner. Cela évite des pertes de temps considérables et nous rend plus efficaces. »
• « C’est intéressant de constater qu’on a le choix pour obtenir de l’information personnalisée tenant compte du contexte. »
• « C’est très simple de s’y retrouver tant avec l’afficheur braille qu’avec la synthèse vocale. »
• « J’ai particulièrement aimé ce test. J’espère que cette façon de faire se concrétise et devienne réalité rapidement. »

Voici un résumé des problématiques et recommandations. Pour plus d’informations, visitez le lien : https://labo.raamm.org/test-8-rapport/

À la suite de notre premier test, nous avions réalisé que même pour un composant accessible, plusieurs utilisateurs avaient besoin d’une aide contextuelle pour comprendre comment l’utiliser. De plus, avec le test sur les onglets, nous avions compris que cette aide pouvait être différente pour chaque type d’outils d’adaptation utilisé. Le défi était donc de proposer une façon d’offrir de l’aide contextuelle de façon à ce qu’un utilisateur puisse aller le plus directement possible aux consignes qui le concernait, sans avoir à lire tout ce qui touchait aux autres outils d’adaptation. Comme le test sur la Boîte de dialogue avait été jugé particulièrement intuitif et qu’il permettait d’offrir de l’information sur demande, en l’isolant du reste de la page, et que le test sur l’Accordéon, également très intuitif, permettait de se concentrer seulement sur l’information pertinente, nous avons pensé combiner ces deux composants pour offrir l’aide contextuelle dont les utilisateurs ont besoin. La facilité d’utilisation de ces deux composants est effectivement un atout important puisque nous ne pouvons offrir de l’aide contextuelle sur l’utilisation de l’aide contextuelle.

Fonctionnement

Premièrement, il est important de faire la mention du ou des composants qui suivront dans la page. L’utilisateur peut ainsi décider s’il a besoin de consulter l’aide ou non.

Par la suite, se trouve un bouton clairement identifié qui permet d’ouvrir une boite de dialogue.

Dans la boite de dialogue, se trouvent d’abord les informations générales qui concernent la navigation sous tous les outils d’accessibilité.

Ensuite, se trouve un Accordéon pour chaque outil avec une particularité de navigation. L’Accordéon est utilisé à l’intérieur de la Boite de dialogue (aide contextuelle) pour séparer le contenu des différents outils d’accessibilité (NVDA, VoiceOver, JAWS).

Il est possible de quitter la Boite de dialogue à tout moment avec la touche d’échappement et de retourner facilement à la page.

Ce composant permet de transmettre l’information nécessaire à la navigation, de façon simple et efficace. Il permet à l’utilisateur de trouver l’information utile rapidement avec l’Accordéon et de retourner à la page sans souci.

 

Indicateurs du projet Labo

D’entrée de jeu, nous avons établi les indicateurs avec le comité d’orientation. Ces indicateurs sont divisés en deux catégories : les indicateurs d’activités et les indicateurs de résultats.

Indicateurs d’activités

Nombre de participants utilisateurs :

Sur deux campagnes de recrutement, 35 utilisateurs se sont inscrits ; 24 ont participé aux tests. Seulement 6 se sont désinscrits pour manque de temps.

Nombre de participants à titre d’experts en accessibilité :

Nous avons 24 experts d’inscrits venant de plusieurs organismes et entreprises différents. Seulement 17 ont participé aux tests.

Nombre d’organisations partenaires :

7 organisations partenaires ont participé au Laboratoire en allouant des ressources humaines ou financières. Voici la liste des partenaires :

1. INLB;
2. Fondation Hector-Cyphiot;
3. STM;
4. Desjardins;
5. Loto Québec;
6. Canadialog;
7. Ministère du Travail, de l’Emploi et de la Solidarité sociale.

Nombre de cycles de rétroaction par composant :

Nous avons travaillé à l’amélioration des composants en les testant sur plusieurs cycles de rétroaction. Nous testons d’abord le composant tel quel sur le site de la Boite à outils de l’expérience Web. Après quoi, notre intégrateur le modifie pour nos besoins et intègre le composant sur notre site Web. Le comité de pilotage refait une série de tests afin de s’assurer qu’il n’y a aucun bogue d’intégration. Les groupes de testeurs sont invités par la suite à venir tester le composant sur le site du Laboratoire et remplir un formulaire. Avec la synthèse des problématiques trouvées par nos groupes de testeurs, le comité de pilotage travaille à trouver des solutions pratiques et faciles d’implantation. Finalement, des recommandations sont produites et transmises à la Boite à outils de l’expérience Web.

Indicateurs de résultat

Nombre de composants expérimentés, améliorés et validés :

Voici la liste des composants testés :

1. Menu;
2. Onglets;
3. Validation de formulaire;
4. Boites de dialogue;
5. Accordéon;
6. Notes de bas de page;
7. Calendrier d’événements;
8. Aide contextuelle.

Organisations publiques et privées contactées pour en faire la promotion

Nous avons contacté Desjardins et la Société de Transport de Montréal pour faire la promotion du Laboratoire. Nous souhaitons mettre plus d’emphase sur la promotion du Laboratoire lors de la deuxième phase du projet.

Organisations publiques et privées qui utilisent un ou plusieurs de ces composants, après un an d’activités du projet

Nous avons obtenu la confirmation de la Société de Transport de Montréal qu’elle a pour projet d’implanter les composants testés par le Laboratoire.

Nombre de participants utilisateurs qui considèrent avoir amélioré leur niveau de compétence dans l’utilisation du Web, grâce à leur participation à ce projet

15 utilisateurs participants sur 24 considèrent que le Laboratoire leur a permis d’améliorer leur niveau de compétence dans l’utilisation du Web. Plusieurs mentionnent qu’ils ont appris beaucoup durant les expérimentations :

• « Ça m’a forcé à réviser ma connaissance des outils. »
• « J’ai trouvé intéressant de faire l’expérience. »
• « J’ai surtout appris à me sensibiliser avec les termes. »
• « C’est plus clair maintenant avec les onglets, entre autres. »
• « Heureuse d’apprendre qu’on se soucie de rendre les sites plus accessibles. L’Internet reste un grand moyen d’information pour les personnes avec déficience visuelle. »
• « Les explications pour effectuer une tâche sont utiles. Il serait intéressant d’avoir un document de formation résumant les éléments ou commandes importantes dans un contexte précis sur le Web. »

 

Deuxième phase

Nous souhaitons continuer notre projet de Laboratoire d’expérimentation et de promotion de l’accessibilité du Web pour une deuxième phase, qui se déroulera sur une deuxième année. Nous voulons terminer de tester l’ensemble des composants restant de la Boite à outils de l’expérience Web. Voici la liste des sept composants à tester :

1. Lecteurs multimédia, audio et vidéo;
2. Tableaux multipages;
3. Boutons à bascule;
4. Gadgets de partage;
5. Interface à onglets – carrousel;
6. Expiration de la session;
7. Aide contextuelle 2.

Nous devons aussi mettre à jour nos résultats pour les tests réalisés en fonction des correctifs apportés par l’équipe de développement de la Boîte à outils et pour tenir compte des améliorations proposées par les nouvelles versions des différents lecteurs d’écran.

Nous insisterons d’autant plus sur la promotion du Laboratoire, lors de notre deuxième phase. Nous allons débuter avec une présentation du Laboratoire au colloque A11yQC 2016 qui aura lieu le 11 octobre.

Nous voulons également rechercher de nouveaux partenaires pour nous soutenir dans le projet. Plusieurs utilisateurs dans notre groupe de testeurs nous ont proposé Vidéotron, La Presse, et d’autres.

Plusieurs avenues de financement sont possibles pour la deuxième phase. Une campagne de socio-financement sera également mise sur pied.

Nous désirons aussi développer le contenu de formation pour les spécialistes en réadaptation, car la formation qu’ils dispensent aux utilisateurs est un levier indispensable pour en arriver à un Web plus accessible et plus convivial pour tous les utilisateurs aveugles ou malvoyants, et pas seulement pour les plus aventureux ou les plus expérimentés.

 

Conclusion

Le Laboratoire d’expérimentation et de promotion de l’accessibilité du Web remercie ses partenaires, ainsi que tous ceux qui ont participé au projet, de proche ou de loin. Nous voulons remercier les membres du Comité de pilotage qui ont suivi le projet quotidiennement, plus particulièrement Jean-Marie D’Amour sans qui ce projet n’aurait pas été une réussite.

Nous espérons que la deuxième phase du projet se déroulera aussi bien que la première.

Merci et au plaisir de pouvoir continuer ce projet avec votre soutien.

Aidez-nous à vous aider à rendre le Web plus accessible.