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