Retour sur le Contribatelier « Accessibilité numérique » organisé lors de la Journée Mondiale des Mobilités et de l’Accessibilité

Le 30 avril 2022, à l’occasion de la Journée Mondiale des Mobilités et de l’Accessibilité, deux structures membres du collectif CHATONS, Alsace Réseau Neutre et Le Cloud Girofle, ainsi que le hackerspace associatif strasbourgeois Hackstub, se sont mobilisées pour organiser simultanément un Contribatelier sur l’Accessibilité numérique à Strasbourg et Villebon-sur-Yvette (91). Nous leur laissons le clavier pour nous partager un compte-rendu de cette action et des pistes envisagées pour la suite.

À cette occasion, une douzaine de tests ont été menés sur des logiciels libres, dont la plupart sont proposés comme services en ligne par des membres du collectif CHATONS. Les audits consistaient en des tests d’usage réalisés par binômes, composés d’une personne malvoyante en charge du test et d’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 sur https://entraide.chatons.org et https://chatons.org.

Cet article est l’occasion de détailler comment les tests se sont passés et de mettre en avant les principaux soucis et perspectives liés à l’accessibilité des services libres, dans l’optique de structurer un groupe parlant d’accessibilité au sein du collectif.

Comptes-rendus des sessions

CR du contribatelier animé par ARN et Hackstub à la médiathèque Neudorf de Strasbourg

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 si peu de temps, avec très peu de personnes testeuses. Parmi les possibilités de tests, nous n’avons pas sélectionné les outils collaboratifs car nous redoutions une faible accessibilité de ces outils : écrire dans un document collaboratif en ligne prive généralement la personne déficiente visuelle des raccourcis de son outil d’assistance. Les résultats sont mitigés : sur 14 tests, 8 se sont soldés par un succès et 6 ont posé problème (deux réussites partielles et 4 échecs). Les services qui ont posé le plus de problèmes sont les outils de sondage. 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és davantage aux fonctionnalités du navigateur ou à d’autres paramètres (configuration des outils d’assistance ou des 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 é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 : y a-t-il plus de moyens injectés pour l’accessibilité dans les outils propriétaires ?

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.

CR du contribatelier animé par Le cloud de Girofle à Villebon-sur-Yvette (91)

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 il utilise 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. Par ailleurs, Nicolas utilise EMACS, un éditeur de texte libre navigable intégralement au clavier développé par Richard Stallman, 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. Un protocole de test et des scénarios de tests avaient été préparé en amont et étaient mis à disposition. Les captations rendent compte de ce qui se passe sur l’écran et de la synthèse vocale.

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.

Quelques exemples :

un test consistant à se créer un compte Nextcloud en recevant une invitation par email a pris une demi-heure (et nous parlons d’un test réalisé par un informaticien) !

un autre test sur le service Framadate (outil de planification de date) ne propose pas « oui/non/peut-être » comme réponses, mais « chaussure de ski » et « drapeau dans un trou » !

toujours sur Framadate, 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 !

Et lors d’un test pour éditer un document en ligne (OnlyOffice) partagé avec Nextcloud, on se rend compte que le bouton pour ouvrir le document n’est pas accessible à la navigation au clavier, que même si on pose le curseur dessus, les options pour l’ouvrir ne sont pas lues par la synthèse vocale et que même si le document est ouvert, la synthèse vocale ne lit pas le document. On découvre ainsi 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 et 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.

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).

Bilan et perspectives

Le contribatelier, un outil de sensibilisation à l’accessibilité

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). Les expériences ont globalement été appréciées de toustes les participantes. Que ce soit du point de vue de l’accueil ou du travail réalisé, ces séances ont offert un cadre 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 pendant un test. 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ù elle ne pourra jamais accéder au service par ses propres moyens.

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

celui 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 ainsi 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 ou 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 utilisateurices 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.

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.

Et après ?

Nous souhaitons proposer à nouveaux des contribateliers sur l’accessibilité numérique afin de finir les tests prévus. De plus, nous préparerons d’autres tests à 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 réaliser plusieurs fois un même test n’est pas futile. Au contraire, cela rend compte des différences rencontrées en fonction des 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 de culture numérique.

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 documentation à été produite lors de ces ateliers : 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, au 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 structures membres du collectif 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 sur cette thématique sera proposé lors du camp CHATONS 2022 (18-22 août).

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.

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é ?

En tant que défenseur⋅euses des logiciels libres, on s’interroge : la liberté numéro zéro, 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éveloppeur⋅euses ou permettent aussi d’autonomiser les utilisateurices ?