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.
Aujourd'hui, de plus en plus de sites utilisent des caractères unicode pour afficher des caractères spéciaux (des flèches par exemple) ou de petites icônes sous forme de caractères (ce qu'on appelle des icônes textuelles; les icônes pour partager un contenu sur des réseaux sociaux ou pour lancer la lecture d'un clip multimédia intégré par exemple), qui n'étaient autrefois qu'affichables en tant qu'images.
Afficher des caractères unicode à la place d'images a plusieurs avantages dont ceux-ci :
Les caractères inclus dans des polices posent moins de problèmes quand ils sont redimensionnés car ils ont été prévu pour être lissables (pas d'artéfacts, de pixélisation, etc.). Par conséquent cela permet aux malvoyants qui zooment ou qui utilisent des loupes d'écran de les voir mieux et sans effets gênants quelque soit le support
Mème s'il faut télécharger une police spéciale, c'est presque toujours moins lourd qu'une image classique; et puis les polices se multiplient sur le web, donc il y a de bonnes chance que la même soit utilisée sur plusieurs sites.
IL est extrêmement facile d'en changer non seulement la taille sans risques, mais aussi la couleur ou d'autres propriétés, là où il faudrait refaire autant d'images qu'il n'y a de variantes
Ces caractères et icônes tendent à devenir toujours les mêmes d'un site à l'autre. C'est très bien pour l'utilisateur d'avoir moins souvent à retrouver des repères qui changent d'un site à l'autre
IL est probable que l'alignement text-texte soit plus facile que de l'alignement texte-image; les experts en CSS confirmeront.
Malheureusement, tout cela ne va pas sans inconvénients :
Bien entendu, les caractères sont toujours unicolorres.
La probabilité est très grande pour que les caractères unicode ne soient pas accessibles avec les lecteurs d'écran, car pas reconnus par ces derniers et donc pas ou mal restitués.
Vous l'aurez compris, c'est surtout ce dernier point qui fâche.
S'il y a bien une chose qui manquait cruellement sur ce site, qui n'a pas été refaite depuis très très longtemps et qui n'a pas été réssucité à partir de l'ancien site car elle était objectivement obsolète et stylistiquement dépassée, c'est bien ma self-auto-présentation personnelle propre à moi-même.
C'est aujourd'hui chose comblée, ma présentation est de retour sur le site; à jour et dans un style, comment dire . . . moins raté, moins brouillon, moins ado ?
Pour éviter de polluer la page de présentation elle-même, veuillez déposer vos commentaires relatives à celle-ci ci-dessous.
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.
Dans le cadre de mes études, l'autre jour, il fallait que je me procure un livre vendu chez amazon. Ca devrait être une tâche plutôt courante et facile, non ? Eh bien, en fait, pas vraiment...
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é.
Pour ceux qui me connaissent bien ou qui sont déjà allé sur le Salon, cet article ne vous apprendra rien de nouveau hormis peut-être quelques anecdotes. Pour ceux qui au contraire viennent tout juste de tomber sur mon site web personnel ou qui ne connaissent que celui-là, il est grand temps que vous sachiez ce qui occupe le plus clair de mon temps en-dehors de mes études. Je me demande pourquoi je n'ai rien publié plus tôt à ce sujet, car ça fait déjà trois ans que j'aurais dû le faire ! Sans doute une preuve de plus, s'il en fallait une, que l'ancienne version de mon site web était définitivement à l'abandon.
Un site non mis à jour depuis au moins deux ou trois ans, des contenus pour la plupart largement obsolètes, une référence javascript plus vraiment d'actualité, des scripts datant de la dernière guerre, des jeux qui ne fonctionnaient plus, un forum désert, des liens morts, des pages abandonnées... tel est l'état où était l'ancien site que vous êtes probablement très surpris de ne plus voir à la place du présent message. Bref, Internet Explorer 6 a fini par disparaître, entre temps !
Aujourd'hui, devant un contenu qui ne me correspond plus tout à fait tel qu'il était présenté (pour ne pas dire foutoir), et qui est de toute manière en grande partie totalement dépassé (j'avais même gardé des astuces PC datant de Windows 98, c'est dire !), j'en ai conclu qu'une des meilleures choses à faire était de nettoyer tout ça, conscienceusement tout reprendre et filtrer, supprimer la masse d'informations inutiles, pour finalement quasiment recommencer le site à zéro parce qu'il n'y avait, en fait, que très peu de choses qui valaient le coup d'être sauvées.
La toute première version de ce site date de 2002, et les principales rubriques n'ont pas beaucoup évolué depuis la dernière grande refonte en 2004. C'est dingue, tout ce qu'on peut accumuler en dix ans... il était grand temps de faire le ménage et de revenir à l'essentiel. Le temps de la décrépitude a assez duré.
Ce nouveau format sera l'occasion de partager avec vous autant de grands articles que de petites astuces écrites au jour le jour, au fil de mes découvertes et développements, peut-être un peu plus souvent et sur des sujets peut-être un peu plus variés qu'auparavant. Quoi qu'il arrive, je resterai toujours essentiellement dans le domaine de l'informatique, du développement, de l'accessibilité et des nouvelles technologies, mais ne sait-on jamais.
Rares seront les pages de l'ancien site qui reviendront traverser les âges dans cette nouvelle demeure, mais il y en aura quand même quelques-unes. Elles seront très faciles à repérer car antidatées pour refléter leur moment de mise en ligne original. IL y en a déjà une poignée et d'autres vont probablement suivre encore prochaînement. Si un des anciens contenus vous manque et que vous aimeriez bien le faire revenir dans le présent, si vous êtes envahi par un soudin sentiment de nostalegie prononcée, ou si repenser à toutes ces années vous donnent tout à coup le vertige, faites-moi en part dans les commentaires ! Ils sont là pour ça dorénavant.
Si vous tenez absolument à voir tout le contenu périmé qui a existé à un moment ou à un autre entre décembre 2002 et août 2013, même si c'est un gros bordel et si plus grand chose ne marche correctement (vous êtes prévenus, je ne fais plus de support pour ces vieilleries), l'ancien site a été transféré sur old.quentinc.net. Je décline toute responsabilité sur le fonctionnement, la teneur, la véracité et la pertinence des contenus qui y sont conservés comme autant de vestiges historiques datant de mon adolescence et de la préhistoire du web.
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.