Vous consultez la page 7 de la rubrique Accessibilité qui contient 17 pages.
Cécitix pour l'accessibilité des déficients
visuels
de Basse-Normandie.
Association régie par la loi
1901.
Accès au sommaire de la page affichée
Accès au contenu de la page affichée
Accès à la navigation dans le site
Où suis je ?
Vous êtes ici :
> Page d'accueil du site > Accessibilité
Toute l'information que l'on souhaite consulter, éditer, remanipuler, ne réside pas uniquement sur notre ordinateur : il y a également l'internet !
Le mode d'accès par excellence au système GNU/Linux étant toujours la console, mode en ligne de commande, donc textuel, pour l'internet il n'y a d'autres solutions que de le visiter en mode textuel, en utilisant des navigateurs tels que Lynx, Links, W3M, et quelques autres nouveautés.
Lynx est probablement le nom le plus connu, car grâce là aussi à sa licence Libre, de nombreux portages ont été fait, e.a. pour DOS et pour Windows.
S'il n'y a rien d'absurde ni de ridicule à vouloir naviguer sur le net par le biais d'un navigateur en mode texte, (au contraire, la visibilité est optimale car le rendu est par essence du texte), les obstacles eux ne manquent pas de nous rappeler que nous fonctionnons en mode textuel, et qu'au niveau de l'interoperabilité le mode graphique a apporté de nettes améliorations ;
pour bien comprendre le problème, il y a 2 éléments d'influence à prendre en compte :
- la conception d'une page web,
- l'implémentation technique de l'outil, du navigateur.
Le W3C - World Wide Web Consortium, instance qui a été à la base du code HTML, qui constitue la moelle de toutes nos pages web, a également en son sein une initiative appelée WAI - Web Accessibility Initiative.
Celle-ci s'efforce de promouvoir des lignes directrices qui, prises en compte par les concepteurs de pages web, rendent la navigation, la consultation et l'affichage même du contenu, accessibles aux utilisateurs non-voyants utilisateurs de solutions vocales ou textuelles.
Malheureusement, trop peu de webmestres ne tiennent compte de ces lignes directrices, se privant ainsi d'une partie du public, tout en le discriminant en même temps.
Un respect inconditionnel de ces "guidelines" amènerait une plus grande accessibilité, dans la mesure où les concepteurs de solutions Libres, eux, tiennent justement compte des standards ouverts pour concevoir des applications en harmonie avec ces règles (ceci est très important).
A long terme, seule une solution politique, telle l'aDA - American Disability Act, décrétant l'inaccessibilité comme une forme de discrimination, permettra d'avancer vers une plus grande accessibilité, en reconnaissant de fait l'accessibilité comme un droit et non pas un problème de luxe.
De façon générale, si le HTML, le PHP, et les feuilles de style CSS proposées par le W3C sont pris en compte, un grand pas en avant serait fait du fait que la cause de l'inaccessibilité ne pourrait déjà plus reposer sur le concepteur d'un site.
Il ne resterait donc plus qu'aux concepteurs / développeurs de navigateurs à mettre leur outil à jour, en suivant toujours les standards du W3C, et l'accessibilité ne serait même plus un sujet de travaux divers et de débats incessants.
Le navigateur Lynx, (cf. http://lynx.browser.org), qui a derrière lui un passé qui date de l'époque de Unix, connaît ces derniers temps une certaine stagnation dans sa mise à jour ; cela ne signifie pour autant pas qu'il ne soit plus maintenu, au contraire, on peut vérifier sur le site que Lynx est toujours en cours de développement ; mais le retard pris dans les mises à jour a pour conséquence qu'il commence à ne plus pouvoir servir de référence vu qu'il ne peut plus être utilisé de façon systématique pour tous les sites du net. Plus particulièrement, ceux qui utilisent le Javascript, posent de sérieux problèmes d'(in)accessibilité.
Ceci étant, on pourrait se poser la question de la pertinence du Javascript: le HTML et le PHP, ne suffisent-ils pas ?
A l'opposé de Lynx, Links, projet Tchèque, (voir http://artax.karlin.mff.cuni.cz/~mikulas/links) connaît un regain d'intérêt, du fait qu'il offre une approche similaire à Lynx, mais avec le support du Javascript et des implémentations autour de l'Autentification en plus. Or, malheureusement pour nous, certaines applications web sont parfois gérées sous Javascript, alors que le PHP pourrait très bien faire l'affaire, avec l'avantage d'être supporté par Lynx et/ou Links.
Quant à W3M, il s'agit là aussi d'un navigateur web en mode texte, mais l'absence de balises et repères n'en fais pas vraiment un navigateur très convivial pour un déficient visuel. Aussi, je ne fais que le citer parce qu'il existe, mais il n'est pas pratique à l'usage.
Pour clore sur les navigateurs en mode texte, qui n'ont pas encore dit leur dernier mot, je citerai deux nouveautés :
Netrik http://netrik.sf.net (le projet est basé sur W3M, mais vise lui aussi à proposer le support Javascript ainsi qu'un autre look), et
Edbrowse http://www.eklhad.net (projet de Karl Dahlke, qui vise à proposer un affichage aussi pur, aussi dénué d'obstacles et de liens graphiques que possible).
Quant à l'avenir, il aura sûrement lieu sous un environnement graphique, déjà le projet Mozilla (un Netscape Libre), a initié un projet qui porte le nom de ce qu'il se propose de faire : Access-Mozilla Project, voir http://access-mozilla.sourceforge.net/
En résumé : "webmestres de tous poils, respectez les standards ouverts, point barre."
Note : qu'en est-il de la navigation et l'utilisation des moteurs de recherche ?
Techniquement, les moteurs de recherche sont conçus pour être utilisés par tous les moyens et par le public le plus large possible ; en principe ils sont donc tous ou presque tous +/- accessibles.
Ce qui augmente la difficulté, relève plutôt de l'encombrement de liens avant de pouvoir arriver aux deux champs nécessaires à la recherche, un autre problème grandissant sont les pubs, cela remodèle en permanence le site du moteur de recherche, faisant apparaître un jour plus de liens, un autre jour moins. Un site tel Google ou Altavista, ressemblent à une maison où les meubles sont régulièrement déplacés sans que l'on ait averti la personne non-voyante à l'avance.
Mais il est possible dans certains cas de créer un script permettant de faciliter cet usage précis, en soumettant les mots clefs depuis son PC, et en recueillant directement la page de résultats dans son navigateur (Lynx ou Links), voir Shell script 2S: http://brlspeak.net/blinux/2s.tar.gz
Pour commencer, il est capital de resituer la problématique et la discussion autour de l'accès au mode graphique, au-delà du système utilisé :
en effet, au départ, il faut tout de même savoir que pour un déficient visuel, vouloir accéder au mode graphique, en s'imaginant avoir découvert le sixième continent, (et ce, qu'il s'agisse de MS-Windows ou de X-Window sous GNU/Linux), relève de la même absurdité que celle que représenterait l'effort inhumain fournit par un tétraplégique voulant escalader l'Hymalaya -ou le Mont Blanc- sur ça façade la plus raide !
- le mode graphique semble pouvoir offrir une meilleure interaction entre les applications, de façon à ce que son utilisation paraît plus intuitive.
Si cela vaut pour l'utilisation avec la souri pour les valides, il n'en est en revanche rien pour les non-voyants, car, Jaws (pour Windows) ou Gnopernicus (quant X-Window sera accessible) devront de toute façon "rendre des comptes"
à une interface qui rend en mode *TEXTUEL*, j'insiste, le contenu affiché sous un environnement graphique.
N'es-ce donc pas en quelque sorte déplacer un problème, où, plutôt que de développer des applications plus conviviales pour un non-voyant, et plus adaptées à son handicap, on préfère lui faire apprendre à escalader une montagne qu'on a construit rien que pour ça, mais pour finir par aboutir au même résultat, pour atteindre un objectif qu'il pourrait atteindre par une autre *méthode*?
La question serait donc : s'agit-il d'être à égalité des valides en les imitant coûte que coûte et malgré les nouvelles difficultés créées chaque jour (ainsi qu'une solution "commerciale" en aval)? Ou, s'agit-il d'imiter les valides en utilisant une autre solution, SA propre solution, adaptée, qui n'utilise PAS les mêmes *méthodes*, mais aboutirait au *même résultat*?
- Le vrai problème réside dans le fait que peu d'applications ne sont à la fois pilotables en mode texte et/ou graphique, tout en offrant les mêmes facilités que les applications exclusivement graphiques, et la même facilité d'utilisation.
C'est donc là un problème de choix de développement : la tendance va irrémédiablement vers le graphique. (Elle sert aussi sans aucun doute un plus large public, demandeur).
Cela signifie qu'il faut finir par l'adopter, malgré les réticences exposées plus haut, envers et contre tout constat absurde.
De telles applications "console et/ou graphique" existent pourtant sous GNU/Linux; prenons-en deux :
pdftotext : utilisable en ligne de commande pour convertir un fichier PDF, et pourtant faisant partie du paquet xpdf-utils, outils graphiques ; ou, mplayer : qui au départ sert à visualiser des films AVI, MPG, des DVD, etc, alors que pourtant il est utilisable en mode console, par exemple pour permettre à un non-voyant d'"écouter" un film, un reportage ou documentaire en MP3, MP4, AVI, WMA.
- Alors pourquoi s'intéresse-t-on au mode graphique, même sous GNU/Linux?
Il s'agit au départ d'une simple question de "compatibilité" dans le cadre d'un poste de travail : l'administration américaine Clinton avait décidé d'investir dans le Logiciel Libre, qui plus est dans Red Hat (vu que produit made in USA), à condition que le mode graphique soit lui aussi accessible pour les non-voyants.
Ainsi, la firme Ximian, en collaboration avec Sun Microsystems et pour le compte de l'administration américaine, s'est mis à étudier le sujet, et a initié un projet appelé GAP, Gnome Accessibility Project (cf. http://developer.gnome.org/projects/gap).
A l'image de BrlTty pour les barrettes braille, la société BAUM développe actuellement le logiciel Gnopernicus (http://www.baum.ro/gnopernicus.html).
Il s'agit d'un lecteur d'écran (comme l'est Jaws pour Windows), qui, couplé au bureau Gnome, permet d'accéder à l'information en braille et/ou en vocal.
Actuellement, Gnopernicus fonctionne, il permet bien de rendre le contenu de base du bureau Gnome.
Néanmoins, le projet est en constant développement et au stade de développement actuel on ne peut pas encore considérer que cette solution soit viable pour une utilisation quotidienne.
Dans un but de test essentiellement, mais aussi pourquoi pas dans le but de participer à l'avancement du projet, on peut déjà utiliser complètement ou partiellement certaines applications telles que OpenOffice/StarOffice, Mozilla, Balsa pour le courriel, Gedit pour éditer du texte, Nautilus pour l'explorateur de fichiers, etc...
Un autre projet d'accessibilité du mode graphique, est le projet KDE Accessibility, http://accessibility.kde.org Mais au contraire de Gnome et leur Gnome Accessibility Project, KDE Accessibility Project s'est plutôt focalisé sur l'agrandissement d'écran (Kmag), le pilotage adapté par le biais de la souri (KMousetool), et la reconnaissance vocale pour piloter KDE (Kmouth).
A côté de ces deux grands projets, il existe un nouveau projet pour les handicapés moteurs, le GOK, Gnome Onscreen Keyboard, projet qui vise à faciliter l'utilisation de Gnome par des personnes handicapées physiques qui n'ont pas un accès aussi aisé au clavier et surtout au touches combinées (voir http://www.gok.ca).
Bref, si nous nous résumons, à ce stade, le mode X commence à être accessible, mais il va falloir dresser une liste "vitale" d'applications pour lesquelles les non-voyants pourraient demander aux auteurs de les rendre compatibles avec la librairie BrlApi, pour le braille, et les spécifications de GTK2 relatives au Gnome Accessibility Project, afin que nous puissions enfin profiter de ces applications au même titre que nos collègues valides.
Dans le cadre de la compatibilité sur le poste de travail, l'utilisation d'applications telles que la suite bureautique libre OpenOffice, le navigateur Mozilla, quelques applications pour le courriel (Sylpheed, Evolution) et quelques autres applications courantes, seront une exigence minimale si l'on veut pouvoir suivre le mouvement et fonctionner sur pied d'égalité avec les voyants.
Comme vu précédemment, sur les thèmes essentiels de l'accessibilité au système et à l'internet, les solutions existent, sont variées et multiples, souvent combinables, et toujours en développement.
Par contre dès que nous nous penchons sur l'impression braille, ou la reconnaissance optique de caractères (lisez l'"OCR"), il est difficile de cacher qu'il y a là un trou à combler au plus vite :
- pour ce qui concerne l'impression, aucun fabricant d'embosseuses braille n'a jusqu'à présent fournit les détails techniques permettant à un développeur d'écrire un pilote pour tel ou tel autre type d'imprimante braille;
l'autre source du problème pourrait être que personne à ce jour n'a réellement creusé ce sujet ou réclamé le moindre code pour pouvoir écrire un pilote, mais ce serait tout de même assez surprenant...
- quant aux scanners et à l'OCR, il existe des solutions qui portent le nom de Sane, GOCR, ou JOCR, ou encore ClaraOCR; elles sont en principe utilisables par un non-voyant à condition qu'elles soient écrites pour la console Gnu/Linux (mode textuel);
mais ici aussi, peu d'expérimentations en la matière ou trop peu de demandes ont été formulées, ce qui en fais un sujet peu traité alors que pourtant suffisamment important pour l'autonomie de la personne déficiente visuelle en situation de travail, d'études, ou habitant seule.
Peut-être qu'il y a là de nouvelles et nobles tâches pour quelques étudiants et développeurs courageux !
ClaraOCR http://www.claraocr.org/
JOCR http://jocr.sf.net/
Osvaldo La Rosa - Landegem, Belgum - 09-05-2004
Ce document est publié aux conditions de la FDL - Free Documentation License.
Retour au sommaire
***