UniversalSpeech, ou comment faire parler son lecteur d'écran facilement
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.
Fonctionnalités
UniversalSpeech est donc une bibliotèhque de fonctions, une API, qui :
- Détecte le lecteur d'écran actuellement en fonctionnement
- Se connecte aux API du lecteur d'écran ainsi détecté
- Permet d'envoyer un texte à lire vocalement ou à afficher sur plage braille au lecteur d'écran actif, quel qu'il soit
- Les changements de lecteur d'écran en cours d'exécution sont aussi détectés; par exemple si on quitte jaws et lance NVDA, la lecture bascule automatiquement sur NVDA; aucune information n'est perdue
- Si aucun lecteur d'écran n'est actif, reste la possibilité de faire lire un texte par une voix synthétique intégrée au système, par exemple SAPI5 dans le cas de windows
- Si la voix intégrée au système est utilisée, accès aux paramètres de cette voix (nom, débit, hauteur, etc.)
- En bonus (C/C++ uniquement), possibilité de capturer l'audio généré par SAPI5
Lecteurs d'écran supportés
Les lecteurs d'écran suivants sont actuellement supportés sous windows :
- Jaws 11+ via FSAPI
- Jaws 4-10 via jfwapi.dll et ses pendants COM freedomsci.jawsapi
- NVDA 2011.1+ via nvdaControllerClient.dll
- Windows eye via l'API COM fournie par GWMicro
- Supernova via dolapi.dll
- Cobra via l'API COM fournie par Baume
- SAPI 5 via l'API C/C++ de Microsoft
Accès et utilisation
Il y a plusieurs façons d'accèder et d'utiliser cette API selon votre langage de programmation :
- API directe pour le C/C++, fichier d'en-tête .h et fichier de liaison .a fournis. Pour les utilisateur de Visual C++, vous pouvez renommer le .a en .lib et ça fonctionnera.
- API java sous la forme d'une classe proposant des méthodes natives
- API COM pour tous les langages de script ne supportant pas l'accès direct aux DLL mais se limitant à CreateObject/ActiveXObject, comme JScript, VBScript ou VBA.
- Pour tous les autres langages, vous pouvez accéder aux fonctions C/C++ de la DLL en utilisant une interface FFI, par exemple celle inclus dans luajit pour lua, CTypes pour python, interop pour C#...
Le fichier d'en-tête C/C++ .h fait aussi office de documentation.
License
J'ai beaucoup réfléchi avant de choisir une license, mais j'en suis finalement arrivé à la conclusion que mes efforts seront probablement vains si je ne propose pas cette API gratuitement.
Du coup, cette bibliothèque est sous la license libre LGPL. Cela signifie que vous êtes libres de modifier et de redistribuer tout ce que vous voulez, mais si vous modifiez, alors vous devez redistribuer en gardant cette même license.
Participer au développement
Je rêverais de pouvoir porter cette bibliothèque sous mac, linux, et pourquoi pas les téléphones mobiles et les tablettes, de sorte que les programmes java, python ou autres langages multiplateformes qui l'utiliseraient pourraient fonctionner sur tous les systèmes sans modification. Malheureusement, je n'en ai pas les compétances. Si vous vous sentez motivés et capables, n'hésitez pas à me contacter.
De même, 5 lecteurs d'écran c'est déjà bien, mais si vous en utilisez un qui n'est actuellement pas supporté parce qu'il est ultra-minoritaire, vous êtes aussi les bienvenus pour en ajouter d'autres.
Vous avez réussi à faire fonctionner UniversalSpeech dans votre langage de programmation, mais ça n'a pas été facile ? Le pack contient quelques exemples dans plusieurs langages outre C/C++ et java, mais le vôtre n'y était pas ?
Si vous voulez l'y ajouter, vous pouvez aussi me contacter. D'autres utilisateurs de votre langage vous remercieront.
Rajout: ce projet est maintenant hébergé sur github à https://github.com/QuentinC-Github/UniversalSpeech
Téléchargement
Ce zip contient à la fois la totalité du code source, les binaires compilés pour windows, et les fichiers utiles pour une intégration dans votre application.
Télécharger UniversalSpeech.zip, 317 Ko (6166 téléchargements)
Les binaires ont été compilés avec MinGW sous windows 7 32 bits, avec GCC 4.x.
Commentaires
1. lventurier, 24.01.2014 05:36:07
bravo. voici une innovation frte utile pour les programeurs. Félicitaions. j'espère que tes efforts seront récompensés.
2. Sylvain, 06.02.2014 18:05:43
Excellent travail. A quand un flux RSS pour suivre tes excellents articles.
3. QuentinC, 10.02.2014 21:03:39
Merci ! Mais il y a bien un flux RSS ! Le lien est tout en bas de la page « tous les articles ».
4. Genroa, 10.03.2016 13:23:08
Le site est assez sale/vieillot, c'est pas pratique et j'ai mis trois visites avant de trouver le lien vers le github.
Mais cette technologie...franchement, chapeau bas. C'est vraiment du bon travail.
5. exatropic, 24.08.2016 14:05:53
Je confirme qu'il n'y pas de rss en bas des articles. Sinon bra
6. Brynanum, 09.01.2017 17:22:35
Je ne te cache pas que ton site a besoin d'un <strong>coup de pinceau</strong>... ^^'
Mais pour ce que tu présente, je suis bluffé. :D
7. antondangermany@outlook.com, 16.04.2018 08:42:48
Hey ,
Je vois le site www.quentinc.net et son impressionnant. Je me demande si le contenu ou les bannières des options de publicité disponibles sur votre site?
Quel sera le prix si nous souhaitons mettre un article sur votre site?
Note: L'article ne doit pas être un texte comme sponsorisé ou faire de la publicité ou comme ça
À votre santé
anto desouza
Commenter