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