Margaux – Le Cloud Girofle

Article publié sur Framablog le 21 juin 2022

Retour d’expérience sur les Contrib’ateliers « Accessibilité numérique » du 30 avril 2022

Un Contrib’atelier ?

Le 30 avril 2022, à l’occasion de la Journée Mondiale des Mobilités et de l’Accessibilité, les CHATONS [1] Alsace Réseau Neutre et le Cloud Girofle, ainsi que le hackerspace associatif strasbourgeois Hackstub, se sont mobilisés pour organiser simultanément un Contribatelier [2] sur l’Accessibilité numérique à Strasbourg et Villebon-sur-Yvette.

Une douzaine de tests ont été menés par chaque groupe sur des logiciels libres, dont la plupart sont proposés par les services des CHATONS.

Les audits consistaient en des tests d’usage réalisés par binôme, formé par une personne malvoyante en charge du test et une personne voyante en charge de sa captation. L’objectif de ces tests utilisateurices fut double : permettre aux personnes qui créent ou hébergent ces solutions de prendre conscience des problèmes et des solutions possibles, et identifier les éventuels services accessibles du collectif CHATONS sur les portails https://entraide.chatons.org et https://chatons.org.

Dans cet article, on détaille un peu comment les tests se sont passés pour nous, on met en avant les principaux soucis et perspectives liés à l’accessibilité des services libres, et on propose de structurer un groupe parlant d’accessibilité.

En direct des Contribateliers

À la médiathèque Neudorf de Strasbourg, animé par ARN et Hackstub

Avec :

Irina (organisatrice et participante), utilisatrice expérimentée d’outils libres et contributrice, membre d’Alsace Réseau Neutre, atteinte de déficience visuelle.
Gabriel (participant), président de C’Cité (Fédération des Aveugles Alsace Lorraine Grand Est), à l’aise avec le numérique au quotidien, atteint de déficience visuelle proche du stade aveugle.
Sylvain (participant), ingénieur logiciel
Valentin (organisateur et participant), ingénieur libriste militant, gérant de ReflexLibre, membre d’Alsace Réseau Neutre et contributeur de YunoHost.
Marjorie (organisatrice et participante), graphiste, artiste et programmeuse libriste, membre d’Hackstub et du collectif cyberféministe Hacqueen.

Avec le soutien également d’Éric et Thomas qui sont passés nous voir. Éric est graphiste et programmeur libriste, membre d’ARN, et Thomas est un usager régulier du hackerspace Hackstub qui s’intéresse à l’informatique, au Libre, et à leurs enjeux.

14 tests ont été effectués sur 13 logiciels en deux demi-journées. Nous avons été surprises et surpris du nombre de tests qui ont pu être conduits en une journée seulement, avec très peu de personnes testeuses. Les résultats sont mitigés, sur 14 tests, 8 se sont soldés par un succès, et 7 autres ont posé problème : on a constaté deux réussites partielles et 4 échecs. Certains des tests partiellement réussis ont nécessité une assistance, due à des défauts d’accessibilité non liés à l’outil testé. Exemple : lors du test de Mumble, un logiciel d’audioconférence libre, l’activation du micro a été ardue. Il y avait donc des problèmes liées davantage aux fonctionnalités du navigateur ou à d’autres paramètres (configuration d’outils d’assistance ou d’interfaces). Un autre constat intéressant à faire est que les tests ont été effectués avec un système d’exploitation et un navigateur propriétaire (OS Windows + navigateur Edge ou Chrome). L’outil d’assistance [3] était quant à lui libre (NVDA). On peut s’interroger sur le rapport entre le taux de réussite et l’utilisation d’outils qui ne sont pas libres : il y a plus de moyens injectés dans le propriétaire. Parmi les possibilités de tests, nous n’avons pas considérés les outils collaboratifs car ils nous effrayaient beaucoup. Nous redoutions une faible accessibilité, car écrire dans un document collaboratif en ligne prive généralement la personne déficiente visuelle des raccourcis de son outil d’assistance. Les services qui ont posé le plus de problèmes sont les outils de sondages.

Pour ce qui est de l’ambiance, nous avons apprécié l’accueil de la médiathèque Neudorf avec laquelle il a été facile de travailler dans une dynamique de coopération. Gabriel nous a également fait part de son enthousiasme quant à la convivialité de l’événement, malgré le peu de participation. Ce faible taux de participation, tant du côté des personnes malvoyantes que des personnes développeuses, nous a questionné sur les liens que nous entretenons avec les associations et publics déficients visuels, et nous a démontré qu’il y avait un vrai travail de sensibilisation à mener auprès de la communauté libriste. Il a toutefois permis un cadre assez intimiste, favorisant l’attention portée aux personnes participantes.

À Villebon-sur-Yvette, animé par le Cloud Girofle

Avec :

Nicolas (participant), informaticien de métier atteint d’une déficience visuelle dégénérescente
Agathe (participante), libriste expérimentée et vidéaste à ses heures perdues
Maxime (organisateur et participant), membre du Cloud Girofle, libriste militant
Margaux (organisatrice et participante), membre du Cloud Girofle

Nous nous sommes retrouvés à 4 à la MJC Bobby Lapointe de Villebon-sur-Yvette (91), gentiment mise à disposition par Charles, également membre du Cloud Girofle. Avec l’aide d’Agathe, libriste et vidéaste à ses heures perdues, nous avons accueilli Nicolas, « informaticien d’avant Windows ! » atteint d’une déficience visuelle dégénérescente. Son ordinateur tourne sous Debian et le passage à la ligne de commande a été plus aisé pour lui quand sa vue a commencé à se détériorer. Il utilise encore des outils visuels, des fonctionnalités intégrées au gestionnaire de fenêtres Compiz comme le zoom et l’inversion de contraste, mais de plus en plus les outils vocaux, qui représentent environ 80 % de son usage : le lecteur d’écran libre Orca et la synthèse vocale propriétaire Baratinoo, en attendant de trouver une synthèse vocale libre, en français, de qualité suffisante [4]. Par ailleurs, Nicolas utilise EMACS, un éditeur de texte libre navigable intégralement au clavier développé par Richard Stallman, le « papa du libre », qui dispose de son propre lecteur d’écran (dans ces cas-là, il coupe Orca, qui est le lecteur d’écran pour systèmes GNU Linux). Il l’utilise beaucoup parce que c’est très adapté à son usage, mais ce n’est malheureusement pas toujours possible : en effet, le navigateur EWW intégré dans cet outil n’interprète pas le Javascript, un langage qui est aujourd’hui massivement présent sur le web !

Le cadre intimiste nous a permis d’échanger de manière très qualitative, et nous nous sommes concentrés sur Nicolas toute l’après-midi. Il nous aura fallu vivre cet atelier pour prendre conscience de la difficulté (pour être honnête, de la quasi-impossibilité) d’utiliser beaucoup de services libres en ligne quand on est déficient⋅e visuel⋅le (malvoyant⋅e, non-voyant⋅e).

Une dizaine de tests filmés ont été effectués par Nicolas, sans assistance extérieure, sur des services proposés par le Cloud Girofle : créer un compte sur Nextcloud, accéder à un espace de discussion Mattermost, lire un document OnlyOffice partagé par email, etc. Les captations rendent compte de ce qui se passe sur l’écran et de la synthèse vocale.

Lien vers le protocole des tests

capture d'écran montrant la connexion à nextcloud avec un lecteur d'écran — Navigation sur Nextcloud lors du Contribatelier : l’utilisateur doit utiliser un niveau de zoom très élevé, en plus d’une synthèse vocale (enregistrée par l’enregistreur visible à droite).

Conclusion : c’est pas glorieux

Alors, les logiciels des CHATONS, c’est accessible comment ? Pour nous, les résultats sont édifiants (et décevants). La quasi-totalité des missions a échoué du côté de Villebon-sur-Yvette, et le taux de réussite à Strasbourg ne dépasse pas 50%. Les tests qui ont rencontré le plus de succès ont été menés avec du matériel et des outils propriétaires (à l’exception du logiciel d’assistance), et il s’agissait aussi des manœuvres les plus simples.

Florilège :

Ainsi, dans l’un des tests, créer un compte sur Nextcloud en recevant une invitation par email a pris une demi-heure (et nous parlons d’un test réalisé par un informaticien) !
Dans un autre, Framadate, l’outil de planification de date ne propose pas « oui/non/peut-être », mais « chaussure de ski » et « drapeau dans un trou » !
Sur le même logiciel, un autre testeur nous indique que la seule manière qu’il a trouvé de l’utiliser est de copier-coller les options dans un tableur, de le remplir, puis de reporter les options dans le tableau en ligne. Une gageure !
Résumé de la procédure pour éditer un document en ligne (Onlyoffice) partagé avec Nextcloud : se rendre compte que le bouton pour ouvrir le document n’est pas accessible à la navigation au clavier ; se rendre compte que même si on pose le curseur dessus, les options pour l’ouvrir ne sont pas lues par la synthèse vocale ; se rendre compte que même si le document est ouvert, la synthèse vocale ne lit pas le document ; se rendre compte que même s’il y a un plugin de synthèse vocale installé dans OnlyOffice, le menu pour y accéder n’est… pas accessible ; se rendre compte que même si on clique sur ce bouton, la synthèse vocale ne fonctionne pas…

À chaque fois, la tentation d’abandonner est forte : impossible de savoir si la fonction qu’on essaye d’utiliser va réussir, ou si l’on va échouer pour une raison parfois bête (un bouton sans label, un message d’erreur qui s’affiche mais qui n’est pas lu).

Assister en direct aux difficultés rencontrées par une personne malvoyante sur un ordinateur est une expérience édifiante. Nous pensons que tout le monde devrait la faire au moins une fois, pour se rendre compte des enjeux associés à l’accessibilité numérique.

capture d'écran montrant un mail lu avec un lecteur d'écran au zoom très important — Lecture d’un mail lors du Contribatelier : l’utilisateur doit utiliser un niveau de zoom très élevé, en plus d’une synthèse vocale (enregistrée par l’enregistreur visible à droite).

Ce qu’on en retire

Le Contribatelier accessibilité comme outil de sensibilisation et de prise de conscience

Participer à ce Contribatelier a été très éclairant à la fois sur l’urgence de la situation des personnes déficientes visuelles (beaucoup de services restent bloquants, et pour certains sur des points assez élémentaires), et sur ce qu’implique concrètement la manipulation d’outils d’assistance tels que les lecteurs d’écran. On se sent plus outillé, et plus armé pour défendre ce grand sujet. C’est un format idéal pour provoquer une prise de conscience auprès de personnes non initiées, qui a le double avantage de sensibiliser tout en étant dans le “faire”, en l’occurrence, contribuer au libre. De plus, nos expériences de ces Contribateliers ont globalement été appréciées de tous, du point de vue de l’accueil comme du travail produit, ces séances offrent donc généralement un cadre assez convivial, surtout en petits groupes.

Le point sur les difficultés rencontrées

Nous nous sommes interrogés sur le degré d’intervention des personnes qui ne sont pas en situation de handicap lors d’un blocage. Nous avons conclu de cet échange qu’il valait mieux laisser du temps pour dénouer la situation avant d’intervenir, afin de véritablement éprouver l’accessibilité de l’outil, mais que si on se retrouvait face à une impasse, il fallait accompagner la résolution du problème rencontré.

Si la personne déficiente visuelle ne prend pas aisément le service en main, il y a différents types d’échec :

Celui où elle devra d’abord explorer l’interface pour la comprendre et consulter la documentation ;
Celui où des astuces/manipulations lui sont indiquées par une autre personne ;
Celui où la personne déficiente visuelle ne pourra jamais accéder au service par ses propres moyens.

Côté développement, on peut aussi distinguer différents cas :

Le cas où il suffirait de corriger quelques détails ;
Celui où les modifications sont complexes mais le service partiellement utilisable ;
Celui où il faudrait quasiment tout revoir.

On découvre plusieurs catégories de problèmes :

des problèmes de conception : pages web trop complexes (comment s’y retrouver quand des centaines d’informations non hiérarchisées – il n’y a pas de couleurs en synthèse vocale – sont lues), notifications non accessibles, synthèse vocale indisponible dans certains environnements (canevas notamment) ;
des erreurs d’implémentation : boutons sans label, titres des vidéos qui ne sont pas indiqués, parties du logiciel non navigables au clavier ;
des problèmes de version : avec la course aux fonctionnalités, les navigateurs web un peu anciens sont de moins en moins supportés. Or ce sont souvent ces navigateurs qui équipent les systèmes adaptés aux non-voyant⋅es. Choisir de ne pas les prendre en compte, c’est se priver de certain⋅es utilisateur⋅ices qui utilisent des systèmes spécifiques, pour lesquels les mises à jour sont parfois compliquées.

De manière générale, bien qu’une bonne moitié des interfaces graphiques des logiciels « en dur » sont inutilisables ou difficilement utilisables, elles restent mieux gérées par la synthèse vocale que dans les applications web, qui sont d’expérience peu accessibles. Les standards d’accessibilité sont peu respectés, et la conception de pages complexes rend la lecture des pages plus difficile encore.

Par ailleurs, alors qu’aujourd’hui la majorité des personnes utilisent un très petit nombre de navigateurs web (Firefox, Chrome et Safari, qui se partagent la majorité du marché et concentrent toute l’attention des personnes développeuses), les personnes déficientes visuelles utilisent parfois d’autres navigateurs (Edge, Lynx, etc.), en plus de matériels d’assistance variés. Suivant les profils, on peut trouver des plages ou afficheurs braille, de la vocalisation, des outils visuels (zoom, couleurs, contraste), etc. Certains logiciels d’assistance définissent leurs propres raccourcis clavier, qui peuvent entrer en conflit avec les raccourcis natifs du système ou ceux d’autres programmes. L’interopérabilité de tous ces équipements n’est donc pas triviale.

photo d'un lecteur braille — Un lecteur braille – Photo by Sigmund on Unsplash

Il y a également un autre paradoxe : la plupart des logiciels libres populaires dédient une partie de leur documentation à l’accessibilité, chacun expliquant comment les logiciels sont accessibles. Nous reconnaissons les efforts faits pour améliorer la situation, pourtant, en regardant les cas de OnlyOffice et de Mattermost, nous regrettons :

Que ces pages ne soient pas plus mises en avant, par exemple au moment de se connecter au logiciel, et pas seulement en faisant une recherche sur le site de l’entreprise qui développe le logiciel ;
Que les informations fournies dans ces pages soient parfois incomplètes, par exemple en ne précisant pas les limitations induites par le mode lecture ;
Que ces procédures ne fonctionnent souvent pas ! Mattermost peut se naviguer au clavier, mais sur la version de Firefox utilisée par un de nos testeurs, celle-ci ne fonctionne pas. Autre exemple : le plugin de synthèse vocale d’OnlyOffice ne peut pas être activé facilement, et nécessite une configuration administrateur qui n’est pas faite par défaut.

Une personne dans le groupe strasbourgeois a rencontré des difficultés liées au verrouillage de son système, configuré par une entreprise qui fournit des systèmes adaptés aux personnes déficientes visuelles. Cette dernière n’installe que des versions de logiciels dont l’accessibilité a été évaluée, et parfois légèrement modifiées pour les rendre plus accessibles. L’entreprise dispose donc de son propre dépôt de paquets Debian, et configure les machines de ses clients et clientes pour utiliser ce dépôt en priorité, afin d’éviter qu’iels ne fassent des mises à jour non testées. L’inconvénient de cette méthode “verrouillée” est qu’il est ardu d’accéder aux dernières versions logicielles, faute de mises à jour, qui sont souvent disponibles sur le tard (plusieurs années sont parfois nécessaires). Le principe est pertinent, mais la prudence excessive, ou peut-être le manque de personnel compétent pour le travail d’adaptation, rend l’utilisation d’une machine sous ce système laborieuse. Par ailleurs, ce contrôle à distance du paramétrage peut donner le sentiment d’être dépossédé de sa machine, d’autant plus si la communication sur les changements apportés fait défaut. Il est possible de contourner le verrouillage “à la main”, mais cela demande une certaine aisance en informatique, et lève la garantie d’assistance en cas de soucis. Ainsi, des problèmes sont persistants avec Firefox car la version fournie n’est pas la dernière, ce qui a été bloquant pour mener à bien les tests : la personne est mobilisée pour la résolution du problème plutôt que pour la réalisation des tests. Ça pose la question du processus de développement logiciel : aujourd’hui on fournit des logiciels qui évoluent sans cesse, dont les anciennes versions ne sont pas supportées facilement, voire pas supportées du tout.

La suite

Nous souhaitons reconduire les Contribateliers sur l’Accessibilité numérique afin de finir les tests prévus, et en préparerons d’autres à mener, avec comme priorité les services qui répondent à des usages du quotidien (communication, collaboration, sondage, traitement de texte, etc.). Nous envisageons néanmoins des tests sur des outils plus techniques dans un second temps (services proposés par YunoHost par exemple, un système d’exploitation qui facilite l’administration d’un serveur et participe à la démocratisation de l’auto-hébergement).

Par ailleurs, il est intéressant de noter que les tests doublons ne sont pas futiles, au contraire : ils rendent compte des différences selon les systèmes et configurations, mais aussi selon les handicaps. La diversité des profils est très importante pour les tests. Il faut bien prendre en compte la différence de handicaps et de niveaux.

Nous pensons aussi qu’il serait pertinent de mettre en avant les manipulations qui facilitent la prise en main des outils et logiciels. Il y a parfois des astuces simples, qui s’avèrent très utiles pour contourner les difficultés rencontrées, même s’il est regrettable de devoir presque recourir au hack pour pouvoir utiliser un service.

Beaucoup de matière documentaire à été produite : des vidéos et des notes principalement. Nous entrons désormais dans la phase de restitution de ces tests, nous allons créer et publier des reports de bugs d’accessibilité sur les forges Git des logiciels concernés et les suivre. Deux personnes parmi nous, Irina et Valentin, ont fait deux rapports de bug antérieurement autour de Network Manager et de Mumble. Les protocoles pour soumettre les bugs d’accessibilité peuvent être laborieux, selon leur retour.

Lors de notre débrief, nous nous sommes demandés comment mobiliser davantage sur l’accessibilité numérique, en regard du faible nombre de personnes participantes. Nous aurions en effet souhaité que l’opération se déroule simultanément au sein de multiples CHATONS en France, afin de fédérer sur la question, et de lui donner plus de résonance.

Actions envisagées

Nous avons relevé plusieurs type d’action à envisager, en dehors de la reconduite de Contribateliers sur le sujet, et de la publication de ce communiqué :

Faire émerger un groupe “Accessibilité” : une interstructure Accessibilité a déjà été créée sur La Litière, le wiki des CHATONS. Il serait intéressant de constituer un groupe national de travail, s’étendant à des structures telles que la FFDN, et qui peut-être ne se cantonnerait pas qu’au Libre pour réellement servir l’accessibilité numérique, qui dépend aujourd’hui de beaucoup d’outils propriétaires déployant les moyens. Un atelier sera aussi proposé au camp CHATONS 2022 !
Rédiger des rapports de bug à destination des développeur⋅euses de logiciels ;
Mettre à disposition sur les mails de connexion envoyés par les logiciels un lien vers des page décrivant les raccourcis clavier et options d’accessibilité proposées par le logiciel, ainsi que la liste des fonctions qui sont inopérantes ;
Mettre plus en évidence l’accessibilité dans les critères pour intégrer le collectif CHATONS ;
Faire infuser l’accessibilité numérique dans la communauté libriste à travers des ateliers de sensibilisation et d’auto-formation, en organisant des permanences en milieux associatifs rassemblant des publics déficients visuels, en veillant à ce que les formats proposés considèrent l’accessibilité et en parlent, etc.
Construire une relation de confiance et créer du lien entre associations de personnes déficientes visuelles et développeuses ;
Aller chercher des gens plus compétents sur ces questions, et saisir des structures telles que les tiers-lieux numériques, les universités, les milieux étudiants, etc.
Compiler et traduire la documentation et les ressources existantes sur l’accessibilité numérique.

Pourquoi ça nous parle ?

En tant que défenseur⋅euses des logiciels libres, on s’interroge : la liberté numéro zéro [5], c’est celle d’utiliser le logiciel libre. Que faire quand une partie de la population se retrouve exclue contre son gré de l’utilisation de logiciels libres ? Voulons-nous des logiciels qui ne libèrent que les développeurs ou permettent aussi d’autonomiser les utilisateurs ? (notion de logiciel libérateur)

Quelques parti-pris non consensuels

L’inaccessibilité numérique renforce la fracture numérique et ne concerne pas que les personnes atteintes d’un handicap visuel mais aussi les personnes éloignées du numérique de manière générale, comme les personnes âgées ou les personnes neurodifférentes ;
Renforcer l’accessibilité numérique pour les personnes déficientes visuelles renforce aussi l’accessibilité numérique tout court !
L’accessibilité numérique n’est pas un patch, un plugin à ajouter, mais bien une philosophie, une manière de voir les choses qui doit infuser dès la base du développement (on parle d’accessibilité native) ;
Que choisir : du libre à tout prix, ou l’accessibilité ?

Et tant d’autres encore… rejoignez-nous pour en parler !

Les tests en détail

Protocole des tests

Lien vers le protocole des tests

Ils ont été écrits pour être reproduits facilement. Vous pouvez par exemple copier-coller le contenu dans un autre pad à éditer, et conduire à votre tour les tests de votre choix.

Résultats des tests

Lien vers les résultats des tests effectués

Notes

[1] Collectif des Hébergeurs Alternatifs, Transparents, Ouverts, Neutres et Solidaires.

Lien vers le site des CHATONS.

[2] Les Contribateliers ne nécessitent pas de compétences techniques spécifiques pour participer, on peut ainsi « contribuer au libre sans rien y connaître ».

Lien vers le site des Contribateliers.

[3] Les outils d’assistance utilisés pour ce Contribatelier sont le lecteur d’écran et la synthèse vocale, ils désignent des assistants logiciels pour personnes déficientes visuelles, mais il existe d’autres dispositifs adaptés (plage braille, logiciel grossisseur de caractères, etc.).

Un lecteur d’écran (également appelé revue d’écran) « est un logiciel d’assistance technique destiné aux personnes “empêchées de lire” (aveugles, fortement malvoyantes, dyslexiques, dyspraxiques…) : il retranscrit par synthèse vocale et/ou sur un afficheur braille ce qui est affiché sur l’écran d’un ordinateur tant en termes de contenu que de structure et permet d’interagir avec le système d’exploitation et les logiciels applications ».

Une synthèse vocale « est une technique informatique de synthèse sonore qui permet de créer de la parole artificielle à partir d’informations textuelles. »

(source : Wikipédia)

[4] Il existe un autre moteur libre pour la synthèse vocale eSpeak sous GNU Linux, alternatif à celui délivré avec le lecteur d’écran Orca : Pico TTS (Text To Speech), développé par SVOX. Ce moteur de synthèse a été popularisé par Android, et est aujourd’hui développé par Google, qui met toujours son répertoire à jour sur Github. La qualité de l’expérience est toutefois discutable sous Debian (qualité sonore, gestion des langues et des caractères spéciaux, etc.). Par ailleurs, seul le français, l’anglais, l’italien, l’espagnol et l’allemand sont disponibles.

Lien vers la documentation du moteur de synthèse vocale Pico TTS.

[5] Un logiciel est considéré comme libre (au sens de la Free Software Foundation) dès lors qu’il confère à la personne qui l’utilise quatre libertés (numérotées de 0 à 3) : 0 – La liberté d’utiliser (ou d’exécuter) un programme ; 1 – de l’étudier ; 2 – de le partager ; 3 – de le modifier.

En savoir plus

C’Cité

Anciennement Fédération des Aveugles Alsace Lorraine Grand Est, association qui représente, accompagne et défend les personnes aveugles et malvoyantes dans le Grand Est.

Lien vers le site de C’Cité

Accessibilité numérique

« Sur les 250 démarches administratives les plus utilisées par les Français, seules 15% respectent les normes d’accessibilité. » – Manifeste pour l’accessibilité numérique des personnes mal voyantes de l’association Valentin Haüy

Alsace Réseau Neutre

Fournisseur de services internet associatif local basé à Strasbourg.

Lien vers le site d’ARN

Cloud Girofle

Hébergement web libre et gentil basé à Bourg-la-Reine.

Lien vers le site du Cloud Girofle

Hackstub

Hackerspace associatif basé à Strasbourg qui promeut la culture du Libre et mène un travail d’éducation populaire auprès du public local.

Lien vers le site d’Hackstub

Sport et handicap

La MJC de Villebon sur Yvette anime un groupe de spéléologie pour les personnes mal ou non voyantes ! Ça nous a inspiré, et on vous partage ces deux émissions sur le sport et l’accessibilité :

Le handisport : projection et conférence

L’espoir bleu : le cœur de l’équipe de France de paratriathlon