De septembre 2014 à mars 2015, j'ai fait un stage à la fondation Accès pour tous à Zürich. Pendant ce stage, j'ai développé une application permettant de créer des cours et des tests interactifs accessibles dans le format epub3. Cette application a été également le sujet de mon projet de master, nommé Accessible course material with epub3, pour lequel j'ai récemment obtenu la note de 6 (équivalent à 20 en France). Ce travail me permet de conclure en apothéose mes études à l'EPFL; je suis maintenant officiellement ingénieur informaticien EPF !
Le format epub3 est intéressant car il a été conçu dès le départ pour être accessible, il est standardisé et ouvert, et il intègre les ternières technologies web (HTML5, CSS3 et JavaScript), auxquels ont été ajoutés divers autres sous-standards pour répondre aux besoins spécifiques des livres numériques que n'ont pas les sites web, par exemple la navigation entre les documents, la pagination et la consultation hors ligne. Il a tous les atouts pour devenir un format de choix pour diffuser un large éventail de documents accessibles, que ce soit des cours, des tests interactifs, des livres plus ou moins riches et complexes intégrant de l'interactivité et du multimédia, ou même pourquoi pas des documents administratifs grâce aux possibilités de signature numérique potentiellement offertes. IL est bien supérieur à word ou PDF pour ce faire, tant dans le domaine de l'accessibilité que de celui d'une probable maintenance. Le plus grand obstacle à sa diffusion réside très probablement dans la'ttachement populaire à des technologies archaïques telles que PDF, et au semblant manque de volonté dont les étideurs font encore preuve malgré que la version 3 de ce format ait été développé il y a quelques années déjà.
Lorsqu'on achète en livre électronique aujourd'hui, dans le meilleur des cas il est encore à la version 2 du format epub, quand on a de la chance et que ce n'est pas encore du PDF ou des fichiers aux formats propriétaires volontairement conçus pour être non-interopérables. Corrollaire, les logiciels de lecture compatibles avec la version 3 et qui de plus est accessibles sont encore très rares, et c'est par conséquent le serpent qui se mord la queue: pas de logiciel de lecture, pas de support des étideurs, et pas de support des éditeurs, pas de logiciels de lecture. Il faut admettre qu'il va encore probablement falloir faire avec ce satané PDF pendant de nombreuses années.
En outre, l'achat de livres en ligne est souvent un problème pour une personne non-voyante, car on a constamment le risque de se retrouver avec un objet dûement acheté mais partiellement ou totalement inexploitable, et il n'y a aucun moyen sûr de savoir avant d'acheter l'ouvrage à quel point il sera ou non accessible. De plus les moyens pour se faire rembourser une fois le constat malheureux établi va de « tu peux te brosser » à possible mais plutôt compliqué. JE vous avais déjà parlé aussi d'autres possibles problèmes de l'achat en ligne, ou du moins celui proposé par certains éditeurs. Avec le recul, l'application en question s'est avérée, sans aucune surprise, particulièrement décevante, et ce n'est pas près de changer vu leur mentalité.
JE suis d'avis que PDF devrait disparaître sans délai, au moins pour les raisons suivantes :
IL est possible de rendre un PDF accessible, il existe une norme et des outils pour cela; mais c'est compliqué, long, demande une maîtrise extrême avec des logiciels totalement contre-intuitifs, et par conséquent coûte rapidement très très cher. Adobe n'a pas intérêt à rendre Acrobat plus simple pour des raisons économiques et personne à part eux (et encore, j'ai sérieusement des doutes) n'est capable de comprendre suffisament en détail ISO-32000-2008 et PDF/UA pour espérer faire mieux.
Le point fort principal de PDF, c'est l'impression papier; or nous arrivons à une ère où on imprime de moins en moins et où on consulte de plus en plus directement sur des écrans; des écrans qui ont des tailles très variables entre le smartphone, la tablette et le PC, et bientôt la télé, le mur du salon et le micro-ondes. Mème si de nouveau il existe des outils pour faire des PDF qui présentent bien en toute circonstance, cette variété rend la chose très compliquée.
L'apparence d'un PDF est en principe plus ou moins figée et fixée par le designer; or il y a autant de maladies de l'oeil différentes qu'il n'y a de malvoyants sur Terre et chacun devrait pouvoir personnaliser le texte selon ses exigeances afin de se mettre à l'aise: couleurs, polices, zoom, disposition générale, etc.
LE PDF ne jure que par son aspect visuel, ce qui rend par définition difficile toute représentation non visuelle de l'information qu'il contient. Ce qui signifie que si demain on invente un nouveau moyen de communiquer, on est coincé. Au contraire, le contenu et la structure des livres epub sont complètement détachés des aspects purement visuels, en reprenant les principes de base de la séparation des couches déjà bien connue des concepteurs web.
Pour en revenir à l'application que j'ai développée, il s'agit d'un éditeur de documents epub3 sous forme d'une application web open source. L'objectif était de permettre à quiconque de produire des documents accessibles dans ce format sans trop de difficultés, au départ des cours et des test interactifs, prévue pour des profs.
A l'issue des 6 mois de stage, on est encore à des années lumières d'une exploitation à grande échelle et même d'un minuscule déploiement réaliste, mais si vous êtes curieux, vous pouvez aller voir sur GitHub: répertoire GitHub du projet. Mon stage est terminé depuis mars mais le projet ne l'est pas pour autant; pour le moment, il est en stand-by, en espérant qu'il pourra repartir ultérieurement.
Les notions d'encodage sont mal connues de la plupart des développeurs et donnent souvent lieu à des problèmes pas toujours évidents à corriger.
JE n'ai ni le temps, ni les compétances, ni l'envie de révolutionner le domaine, mais voici une petite contribution qui pourrait vous être utile: un petit utilitaire tout simple en ligne de commande pour windows servant à déterminer l'encodage de caractères utilisé par un fichier et de le changer si besoin.
J'ai conçu cet utilitaire à la suite d'un problème courant et très simple qui m'est arrivé, et je n'avais pas de moyen rapide pour y remédier.
Je voulais convertir, si possible automatiquement, une série de pages HTML statiques de ISO-8859-1 en UTF-8. Pour compliquer la tâche, j'avais déjà modifié et converti certains fichiers au passage, je ne rappelais plus exactement lesquels, et pour faire encore mieux c'était avec le bloc-notes par défaut de windows, qui a la magnifique habitude grotesque, dépassée et inutile d'ajouter un BOM au début de tous les fichiers qu'il encode en UTF-8. Le plus gros problème était alors de supprimer automatiquement le BOM des fichiers déjà convertis, et de convertir les autres.
Il peut parfois être intéressant que le lecteur d'écran installé et en cours d'exécution s'il y en a un, se mette automatiquement à parler ou afficher des messages en braille sur commande d'une application spécifique.
Par exemple, une application de chat IRC pourrait demander au lecteur d'écran de lire le message qui vient d'arriver. De même, un client SSH pourrait lui demander de lire le résultat de la dernière commande dès qu'il est disponible. Dans d'autres applications comme un lecteur multimédia, il pourrait s'agir de lire les sous-titres d'une vidéo, ou informer que le bouton à bascule « lecture en boucle » a changé d'état après avoir appuyé sur une combinaison de touches.
Traditionnellement, cela se fait à l'aide de scripts spécifiques à chaque lecteur d'écran, ce qui permet d'éviter de modifier l'application pour supporter cette fonctionnalité. A la base, c'est une très bonne chose que ce soit indépendant du code de l'application, car comme on le sait, l'accessibilité n'est le plus souvent pas du tout prise en compte par les concepteurs.
Cependant, les méthodes pour détecter l'arrivée de nouveau texte ou d'un changement d'état ne sont que moyennement fiables. Elles se basent sur des indices graphiques comme la couleur d'une icône précise ou le mouvement du curseur clignotant, qui ont une logique complexe, et qui, surtout, varient beaucoup d'une application et d'une configuration à l'autre.
Par exemple, on peut constater que jaws se perd rapidement dans la lecture des sorties dans l'interpréteur de commandes de windows 7 dès lors que le curseur atteint le bas de la fenêtre, ou que de multiples fenêtres se recouvrant partiellement les unes les autres sont présentes à l'écran. De même, on notera que quand bien même des scripts existent pour le client SSH PuTTY, il devient rapidement difficile d'utiliser des interfaces distantes qui font plus que de la simple ligne de commande, ne serait-ce que l'éditeur de texte nano sous linux dans lequel le curseur n'est pas suivi correctement une fois sur deux par le lecteur d'écran sous windows. ET pour finir, tout utilisateur de lecteur d'écran a déjà au moins une fois été embêté par ce qu'on appelle les pop-up fantômes ou les info-bulles mal programmées, ces petites fenêtres qui sont bel et bien à l'écran mais qui ne peuvent pas prendre le focus, qui ne veulent pas disparaître, et qui gênent la lecture des fenêtres normales.
Alors, que faire pour améliorer l'accessibilité de ces applications ?
Pour une fois, la solution ne se trouve pas du côté des lecteurs d'écran, qui font déjà tout ce qu'il est dans le domaine de leurs possibles pour restituer la bonne information au bon moment. Non; la solution est du côté des applications, qui devraient avoir la possibilité de signaler aux aides techniques comme les lecteurs d'écran quand une information vient d'arriver ou a été mise à jour.
Dans le domaine du web, le W3C a compris: dans le cadre de son standard ARIA, il propose un attribut, aria-live. Le principe est très simple, chaque fois que le contenu de l'élément possédant cet attribut est modifié, cela signifie qu'une information mise à jour est disponible, et le lecteur d'écran peut, ou non, la lire dès que l'occasion s'y prête.
Du côté des applications, en tout cas sous windows, il n'y a rien de cela. Un moyen qui fonctionne pas trop mal pour amener le lecteur d'écran à lire quelque chose de précis est de placer le focus dans une zone de texte et de sélectionner la portion à faire lire. Mais ça reste du bricolage et ce n'est pas toujours très fiable.
Les modèles de composants accessibles comme MSAA ou IAccessible2 n'ont absolument pas prévu ce cas de figure. Ces deux standards Microsoft ont pour but que les composants graphiques des applications puissent être décrits, interprétés et restitués de manière appropriée par l'aide technique, mais il n'y a rien en ce qui concerne le signalement de mises à jour pour qu'une lecture soit faite automatiquement.
Du coup, chaque lecteur d'écran a développé cette possibilité indépendament les uns des autres, et il n'y a pas de standard. Si on veut faire parler jaws, NVDA et windows eye, c'est trois API différentes qu'il faut gérer dans son application, en plus de devoir détecter correctement lequel des trois lecteurs d'écran est en cours d'utilisation si tant est qu'il y en a un.
Voici donc la brèche que j'ai voulu combler aujourd'hui: une seule API, pour faire parler le lecteur d'écran actuellement en cours d'exécution. Voici UniversalSpeech.
Pour le moment il n'est disponible que pour windows, mais je rêverais de pouvoir le porter sous mac, linux, et pourquoi pas même les téléphones mobiles et les tablettes.
J'ai bien envie de remettre en ligne mes bonnes vieilles compositions musicales datant de l'ancien site, ou du moins, les plus réussies. C'est alors que m'est revenue tout naturellement la question des lecteurs directement intégrés sur les pages web, et leur accessibilité, au demeurant relativement décevante en règle générale.
Pour que l'accessibilité fonctionne bien, il est en général souhaitable que le contenu des pages web soit le plus possible « rendu » de la même manière visuellement qu'avec un lecteur d'écran. Il est malgré tout parfois utile que certains contenus soient exclusifs aux lecteurs d'écran mais effectivement non affichés, tandis que, au contraire, certains éléments bien affichés ne soient pas rendus lorsqu'on consulte la page avec un lecteur d'écran.
Ce mini-tutoriel va vous expliquer dans quels cas ça peut effectivement être utile, dans quels cas ça ne l'est pas, et comment faire concrètement.
Il semblerait qu'une des tandance actuelles soit d'appeler « application web » à peu près n'importe quel site web 2.0 utilisant javascript et AJAX. « Application web », ça sonne forcément plus cool que « page web » ou « site web interactif » ou autres appellations similaires.
Parralèlement à cela, et c'est fondamentalement une très bonne chose, les attributs ARIA améliorant l'accessibilité de telles pages dynamiques sont de plus en plus utilisés. La plupart ne sont normalement pas trop difficiles à comprendre et à implémenter de manière raisonnablement correcte (je devrais peut-être écrire un article d'introduction sur le sujet), mais il en existe malgré tout certains qui paraissent néanmoins échapper à la compréhension générale et collective. Je dis ça parce que, en-dehors de mes développements personnels, je n'ai à ce jour rencontré encore aucun site les utilisant réellement comme il faut.
Le rôle ARIA application fait partie de ces derniers. C'est sur celui-là que j'aimerais m'attarder aujourd'hui, car il est tellement mal compris et mal implémenté qu'il pose des problèmes sur la quasi-totalité des sites web qui croient bien faire et qui l'utilisent malheureusement le plus souvent totalement incorrectement sans raison véritablement valable, hormis que ça paraît peut-être plus cool pour le commun des mortels que son site web soit considéré comme une application plutôt que comme un site.
En fait, personne ne paraît vraiment comprendre ce que ce rôle implique vraiment, de même que quand il devrait, et quand il ne devrait pas être utilisé.
Lua2Exe, comme son nom l'indique, permet de convertir rapidement et simplement un ou plusieurs scripts lua en exécutables autonomes.
Lua est un langage très facile à apprendre, mais particulièrement puissant étant donné sa simplicité. Sa machine virtuelle est extrêmement compacte et tient en une bibliothèque de quelques centaines de Ko à peine, ce qui fait qu'il est régulièrement utilisé comme langage pour scripter des jeux ou des applications.
Mais lua est aussi un langage de script drôlement pratique pour réaliser des petites tâches automatisées ou répétitives, et même des plus grandes. Pas envie de ressortir un gros java, un perl compliqué, un php pas forcément très adapté pour cette utilisation, ou un python capricieux ? Pas non plus envie de programmer en C/C++ ? Lua pourrait vous convenir.
A l'origine de cet éditeur, une frustration grandissante à l'encontre du bloc-notes de windows, très rapide et très accessible mais manquant cruellement de fonctionnalités importantes quand on fait de la programmation.
Pour la programmation, il y a bien sûr des environnements de développement. Mais je les trouve soit trop inaccessibles, soit trop lents, ou tout simplement usines à gaz. Je préfère travailler avec des choses simples et la ligne de commande. En ce qui concerne les éditeurs dits légers tels que notepad2 et notepad++, leur accessibilité n'est pas suffisante. C'est pourquoi j'ai décidé de créer mon propre éditeur de texte, que j'ai nommé 6pad.
6pad est un éditeur de texte pour windows destiné à remplacer l'archaïque bloc-notes. IL a été dès le départ conçu pour conserver sa rapidité d'exécution et son accessibilité, tout en proposant de nouvelles fonctionnalités pas réellement innovantes mais utiles et pratiques.
Ca fait déjà deux ou trois fois que je la propose sur des forums de programmation, ça fait aussi déjà un certain temps que je l'ai dans mes cartons. Accessoirement, ça fait un moment qu'il n'y a pas eu de nouveau sur le site, c'est l'occasion.
Cette fois, c'est donc officiel, je vous présente une petite API pour faire de l'audio facilement en java. Elle n'a rien d'extraordinaire par rapport aux mastodontes déjà établis de la catégorie. L'avantage qu'elle a est d'être écrite en pur java, c'est-à-dire sans aucun code natif. Elle est donc relativement légère.