Malheureusement, presque toutes les applications modernes présentent l'information dans un format bi-dimensionnel, et la plupart utilisent des icônes graphiques qui n'ont aucune signification pour l'aveugle. Puisqu'il est impossible de récrire toutes ces applications, la communauté aveugle a été forcée, plus ou moins maladroitement, de s'y faire, à l'aide de diverses adaptations. Reconnaissons que ce n'est pas la solution idéale. L'utilisation d'un lecteur d'écran sur Netscape le rend accessible, mais le résultat est à peine efficace.
Pendant la décennie passée, une petite minorité d'utilisateurs aveugles a découvert Linux, un système d'exploitation libre, pour ordinateur personnel, basé sur le texte. Les applications de Linux utilisent rarement des graphiques, et la plupart d'entre eux sont déjà linéaires, comme le mode (la parole ou braille) qui est notre Karma. En pareilles circonstances, Linux est le meilleur système d'exploitation pour un utilisateur aveugle.
Naturellement les choses ne sont pas toujours aussi simples. Si votre travail exige l'utilisation d'un système propriétaire d'enregistrement des commandes qui fonctionne seulement sur Windows, alors vous emploierez Windows, avec un adaptateur qui essaye de rendre cela quelque peu accessible. Mais ce scénario est réellement tout à fait rare. Un employeur peut insister pour un document au format Microsoft Word, mais cela ne vous oblige pas à employer Windows. Vous pouvez écrire en HTML sur Linux et l'expédier à votre patron, qui peut alors l'importer dans Word. Réciproquement, vos collègues peuvent facilement exporter leurs documents Word en HTML. Ou bien vous pouvez employer le programme « catdoc ». Il y a très peu de raisons pour lesquelles vous devez employer Windows. Supposons que vous vous intéressiez à Linux, où les applications sont moins graphiques. C'est une prétention juste, puisque vous visitez déjà ce site Web.
Si vous observez un utilisateur voyant de Linux pendant une heure, vous noterez qu'il passe la majeure partie de son temps dans des applications de console. Il n'a pas besoin du labyrinthe des menus « utiles » et ne se laisse pas distraire par les boites de dialogue rendues célèbres par Windows, et il n'a aucune patience pour « êtes-vous sûr que vous voulez faire cela » et « cliquer si vous voulez vraiment quitter» des zones de dialogue,. Il préférera taper une commande ésotérique que cliquer sur une icône énigmatique, mais en même temps, il n'est pas disposé à abandonner la puissance qui vient de la recherche et du balayage visuel bi-dimensionnels. Ainsi les éditeurs sous Linux, les navigateurs, et les clients de courrier présentent l'information encore écran par écran, et l'utilisateur voyant assimile l'information par la page, ses yeux sautant directement à ce qui l'intéresse. Je l'appelle « envie d'écran », et malheureusement, la plupart des personnes aveugles souffrent de cette maladie, qu'elles le réalisent ou pas. C'est pourquoi elles ne jurent que par leurs lecteurs d'écran, se débrouillant tant bien que mal à travers les applications bi-dimensionnelles.
Quoique la communauté de Blinux ait pris deux mesures courageuses, loin des interfaces graphiques, elle est toujours mariée à l'écran. Nous essayons de compresser nos applications bi-dimensionnelles dans les flots linéaires de braille et de parole, parce qu'il semble plus facile de le faire que réécrire ces applications à partir de zéro. Et en effet c'est vrai à court terme, mais les lecteurs d'écran et les applications d'écran ne seront jamais aussi puissants qu'une commande bien conçue, qui donnera un résultat minimum, mais correspondant précisément à nos besoins.
A ce point, je devrais admettre que l'affirmation ci-dessus est une question d'opinion - mon avis - et qu'il y a beaucoup de personnes intelligentes en désaccord. Chaque adaptateur existant (excepté le mien) prononce (ou envoie en braille) le texte sur l'écran, et seulement le texte sur l'écran (ou des attributs reliés de ce texte). Vous pouvez ne pas vouloir les appeler des lecteurs d'écran, mais c'est ce qu'ils sont. Des douzaines, même des centaines d'utilisateurs aveugles se satisfont de cet arrangement. Cependant, pour les raisons qu'il est difficile d'expliquer, je suis irréparablement dérouté par les programmes d'écran, quelle que soit l'excellence de l'adapatateur et, bien que je puisse faire partie d'une minorité, je ne suis certainement pas le seul. Considérons un simple texte tapé dans Emacs. L'utilisateur aveugle doit simultanément pister le curseur de lecture (le mot qu'il entend ou qu'il sent sur la tablette Braille) et le curseur visuel (où le « travail » s'effectue). Souvent ils sont confondus, mais parfois l'utilisateur doit lire d'autres parties du document, par exemple quand il doit déplacer des portions de texte, et il est alors très facilement perdu.
À mon avis, la «bienveillance» d'une application est mesurée par la quantité de données qu'elle produit : moins il y en a, meilleur c'est. Pour obtenir précisément ce que je veux, je n'ai pas besoin de commandes compliquées, au moins tant que je n'ai pas besoin de résultats détaillés. Prenons un exemple simple.
Unix a une commande « ls » qui liste les dossiers, les fichiers et leurs attributs. Le résultat de cette commande ressemble à ceci :.
-rw-r--r-- 1 eklhad eklhad 5429 Apr 10 18:43 cli.html
C'est très bien pour l'utilisateur voyant. Il doit seulement taper quelques touches, et ses yeux sautent directement au champ qui l'intéresse. En revanche, ma commande « ls », accepte beaucoup plus de paramètres et produit beaucoup moins de résultats. Si je veux savoir les permissions, j'emploie l'option -p, et j'obtiens 644. L'option -l donne la taille, l'option -t donne la date de dernière modification, et ainsi de suite. Voilà comment je peux communiquer avec mon ordinateur, à chaque heure, tous les jours.
Je souscris à la même philosophie en écrivant un document. Pour en venir aux éditeurs de texte, je n'en ai jamais trouvé de sensiblement meilleur que /bin/ed, probablement écrit il y a environ 30 ans, et je n'en trouverai probablement jamais. Quand j'appelle un fichier, il m'indique seulement sa taille. Si je veux lire une ligne de texte, il faut que je le demande. Il n'y a aucun besoin de labourer tout un écran de données pour trouver x et pour le changer en y ; Je tape juste /x pour trouver la ligne qui contient x, puis s/x/y pour transformer x en y. C'est cela la puissance, et il a toujours été ainsi.
Naturellement, Ed est un programme très maladroit dans certaines situations. Les opérations de copier/coller, par exemple, sont extrêmement difficiles, parce que Ed opère sur un seul fichier à la fois. Il marquer le bloc de texte à transférer, le sauvegarder dans un temporaire, enregistrer le fichier en cours, ouvrir le deuxième fichier, et y insérer le fichier temporaire. En outre, les expressions régulières ne sont pas aussi puissantes qu'on voudrait. Pour cette raison, j'ai écrit mon propre éditeur ligne, qui est (presque) compatible Ed, mais incorpore beaucoup de nouveaux fonctionnalités. Ce programme, que j'appelle edbrowse, est un programme écrit en C qui fonctionne sur toutes les saveurs d'Unix, et peut être facilement porté sur d'autres systèmes d'exploitation. Si vous prenez le temps d'apprendre cet éditeur, vous pourrez l'employer sur n'importe quelle machine, pour le reste de votre vie. Edbrowse emploie les expressions régulières qui sont standard en Perl (puisqu'il a commencé comme script Perl), et permet d'éditer un nombre quelconque de fichiers simultanément, le texte étant transférable entre eux à volonté . Il fait tout ceci en ligne de commande, tout comme Ed. Ceci demande un certain apprentissage, particulièrement si vous êtes familier d'Emacs, mais je crois que c'est l'interface la plus efficace pour l'utilisateur aveugle.
Le navigateur Internet est une autre application importante dans ce monde interconnecté d'aujourd'hui, et malheureusement, tous les navigateurs Internet sont orientés écran. Lynx est le plus aveugle-amical, mais nous devons nous rappeler qu'il n'a pas été écrit pour les aveugles.. Les auteurs ont eu à l'esprit les utilisateurs voyants : comme Netscape et Internet Explorer, Lynx s'attend à ce que vous fassiez défiler le document page par page, et déplace le « curseur » de champ en champ dans un formulaire de saisie de données. Ce qui n'est pas adapté à la parole ou au braille. Parcourir des boîtes de dialogue et naviguer entre des pages web est particulièrement frustrant. Pour ces raisons (et d'autres), j'ai ajouté un navigateur à mon éditeur ligne. C'est pourquoi je l'appelle l'Edbrowse, une combinaison d'éditeur et de navigateur. Vous pouvez éditer www.ScrapSayings.com aussi facilement que vous éditeriez un dossier local. Edbrowse identifie l'adresse internet, son format, et rapatrie la page Web de l'Internet. Naturellement vous n'allez pas « éditer » cette page, mais vous pouvez lire en employant la ligne de commande Vous pouvez suivre des hyperliens en utilisant la commande de g (go), ou remplir des formulaires de saisie avec des commandes identiques à celles que vous utilisez pour taper du texte. Vous pouvez vraiment « éditer » vos commentaires avant de les envoyer, un tâche pratiquement impossible dans Lynx.
Notez, les utilisateurs d'Edbrowse peuvent accéder aux archives des mathématiques de MathReference.com. D'autres sites fournissent des informations techniques, comme mathpages.com, sont en grande partie inaccessibles. Quelques sites enregistrent même leurs équations dans le format image de GIF. :-( J'ai écrit MathReference.com et Edbrowse pour travailler ensemble, rendant les mathématiques en ligne disponibles à l'aveugle. En même temps, les pages restent « raisonnablement » accessibles à l'utilisateur voyant, avec indices inférieurs, supérieurs et des lettres grecques. Mais je m'écarte : retournons à l'application adaptée.
Est-il possible d'écrire une application une fois, en utilisant une trousse à outils flexible, de sorte qu'elle fonctionne en mode écran ou en mode ligne à la demande de l'utilisateur ? Supposons que par défaut, des composants donnent des informations à l'écran, mais si vous placez $NOSCREEN dans votre environnement, ces mêmes composants fonctionneront-ils en mode commande ? Ainsi l'application n'aurait pas besoin d'être réécrite depuis le début. C'est une idée intéressante, mais je reste quelque peu pessimiste.. Je suis sûr que cela ne fonctionnera pas pour des éditeurs et des navigateurs. Edbrowse est radicalement différent d'Emacs, et ces deux programmes pourraient ne jamais partager une conception commune. La question à 100 Euros est : est-ce la norme, ou est-ce que l'éditeur et le navigateur sont des applications exceptionnellement compliquées, exigeant un travail considérable pour les adapter aux utilisateurs aveugles ? Je ne suis pas sûr.
Dans beaucoup d'applications, telles qu'un éditeur ou un navigateur, l'utilisateur voyant n'a pas toujours besoin de « faire » quelque chose pour extraire l'information. Il ne déclenche pas l'action d'un composant, ainsi ce composant ne fera rien en mode linéaire. Considérons un autre exemple, le bilan. Il y a une page entière des données, et l'utilisateur ne clique pas sur n'importe quoi pour le lire, il déplace juste ses yeux. Pourtant un bon bilan pour l'aveugle devra me demander la donnée de la colonne y et la ligne x, indiquant la rangée et la colonne par un nombre ou, encore mieux, par un identifiant court tel que « fica » ou « intérêt ». Il y a donc un autre exemple réel d'une application importante qui devrait probablement être remodelée.
J'ai peur que ceci soit vrai pour n'importe quel programme où des mouvements d'oeil (dont le programme n'a pas à s'occuper) doivent être convertis de façon ou d'une d'autre en commandes, voies entièrement nouvelles pour une version linéaire du même programme. Penser à l'application comme conversation entre le programme et l'utilisateur. Quand l'utilisateur ignore 95% de ce que le programme « indique » et choisit le 5% approprié en déplaçant ses yeux, cette conversation doit changer, d'une manière fondamentale, pour être aveugle-amicale. La plupart des écrans implémentent ce type de conversation sous forme de méga-sorties. C'est en fait le paradigme de l'écran. Sur cette base, je crois que la plupart des programmes d'écran doivent être remodelés, à un niveau au-dessous de l'interface visible pour devenir amicaux aux aveugles.
En conclusion, les applications en ligne de commande ne sont pas meilleures que l'adaptateur qui les soutient. Comme tous les adaptateurs, braille ou audio, sous Windows ou Linux, sont des lecteurs d'écran, j'ai décidé d'écrire mon propre adaptateur. Je l'appelle Jupiter Speech System, le premier adaptateur qui est construit avec la ligne de commande utilisateur à l'esprit. Jupiter est capable de lire la mémoire d'écran, et certains l'emploient de cette façon, mais je passe au moins 7 heures et 50 minutes par jour de 8 heures dans le mode ligne de commande. Ceci me permet de passer en revue les commandes entrées, et les réponses reçues, caractère par caractère au besoin, jusqu'au début de la session d'ouverture. (En fait il y a une limite au texte qui est sauvegardé de cette façon, mais il excède certainement un écran. En fait le tampon loge l'équivalent de douzaines d'écrans, selon la quantité d'informations). Si vous préférez la ligne de commande, vous pourriez vouloir ce type d'adaptateur.
Il y a une liste de diffusion pour des utilisateurs de Jupiter speech, d'Edbrowse, et d'utilitaires en ligne de commande. Vous pouvez vous y joindre en envoyant un courrier électronique à commandline-subscribe@yahoogroups.com.
En plus de l'adaptateur et des applications linéaires décrits plus tôt, j'ai développé une petite rustine au noyau de Linux pour faciliter la tâche de quiconque développera, examinera, maintiendra, et distribuera des adaptateurs à l'avenir. Un noyau modifié de cette façon serait « blinux prêt » - préparé à recevoir un adaptateur de type blinux comme module chargeable. Ceci combine la facilité et la flexibilité d'un programme utilisateur avec la puissance du noyau. Il facilite également l'apprentissage si vous êtes un utilisateur nouvellement aveugle qui n'est pas terriblement au courant de Linux. Disons le clairement : la dernière chose que vous voulez faire est de recompiler le noyau et maîtriser sans erreurs les nuances du lilo. Si ma rustine devenait une partie de Linux standard, rien ceci ne serait nécessaire. Vous pourriez télécharger sur le Net une douzaine de modules chargeables et installer chacun alternativement, pour voir si vous aimez. Puis le désinstaller et installer le prochain, et ainsi de suite. Vous pourriez même préférer un adaptateur pour certaines tâches et un autre adaptateur pour d'autres. Je connais déjà les personnes qui commutent entre EmacsSpeak et Speakup, selon le travail qu'elles effectuent. La permutation des adaptateurs dedans et dehors en marche serait beaucoup plus facile s'ils étaient des modules chargeables.
Noter que cette approche modulaire n'est pas limitée à la communauté visuellement handicaapée. Par exemple, j'ai mis en application un clavier alternatif pour les utilisateurs n'ayant qu'une seule main. Je l'ai écrit comme module chargeable dans le noyau blinux-prêt. Ce module fait seulement 100 lignes et pourtant il met en application des techniques impossibles à réaliséer avec le programme « loadkeys ». D'autres adaptateurs pourraient lier des dispositifs d'entrée spécialisés au clavier pour les handicapés moteurs, avec des algorithmes de prévision de mot, des macros définies par l'utilisateur, et ainsi de suite. J'espère que Linux intégrera cette rustine, ou une semblable, au noyau standard standard ; les ordinateurs deviendraient plus accessibles à la communauté handicapée entière.
Envoyer tous les commentaires ou réactions à l'auteur, Karl Dahlke, par mail à eklhad@comcast.net, ou téléphoner à 248-524-1004 aux heures de bureau EST.
Cliquez ici pour aller sur le site de l'auteur.