L'état des technologies d'aide à l'accessibilité

Pour Aaron Leventhal, le coût particulièrement élevé des solutions d'accessibilité s'explique (en particulier pour les lecteurs d'écran) par la taille réduite de leur marché et la complexité des technologies en cause. Ce problème de coût a une conséquence immédiate : les applications ne sont guère compatibles qu'avec les environnements ou les navigateurs les plus répandus (concrètement, Windows et Internet Explorer). Dès lors, même si une partie des utilisateurs ont accès à des solutions efficaces répondant bien à leurs attentes, la situation globale reste insatisfaisante : Beaucoup de gens ne trouvent encore pas des solutions techniques répondant à leurs besoins, et beaucoup de logiciels importants et de sites Web ne sont toujours pas utilisables pour un grand nombre de personnes.

Mais l'obstacle principal ne serait pas là :

Le rêve à long terme de l'accessibilité universelle ne se réalisera pas sans d'énormes changements dans l'industrie. Il ne s'agit pas simplement d'avoir assez d'argent pour concevoir de manière accessible. La maîtrise du design et des techniques de conception accessibles doit être enseignée dans les universités et les établissements spécialisés, ce qui signifie que les formateurs en informatique et en conception doivent commencer par s'y former eux-mêmes ! L'accessibilité doit devenir une composante essentielle de nos outils de développement et de notre culture technique. D'une manière générale, les gens dans notre secteur devraient se préoccuper davantage de la variété des utilisateurs dans le monde réel, tels que les différences entre jeunes et personnes âgées. C'est l'idée clé de la conception pour tous. La meilleure manière de comprendre l'accessibilité est de réaliser qu'il n'y a aucune formule ou définition globale qui résoudra tout. La véritable solution réside dans le temps consacré à observer les pratiques d'un ensemble d'utilisateurs variés.

Le W3C et l'industrie : deux approches différentes de l'accessibilité ?

Le fond du problème, selon Aaron Leventhal, est que les théoriciens qui écrivent les standards et les praticiens qui conçoivent les logiciels d'accessibilité ont deux approches différentes de l'accessibilité. Chacune a ses forces et ses faiblesses :

• D'une part, ceux qui rédigent les standards sont souvent attirés par le défi de trouver des réponses élégantes couvrant tous les cas de figure, telles que les architecture model-view-controller ou la séparation de la structure et de la présentation. Ils veulent que leurs standards soient aussi durables que possible, dans autant de domaines que possible [...] Cependant, le degré d'abstraction qui en résulte peut conduire à ignorer les questions prosaïques que se posent les utilisateurs et les développeurs de terrain, lesquelles sont les plus coûteuses en travail.
• A l'inverse, ceux qui créent les logiciels veulent répondre aux préoccupations prioritaires de leurs clients. Ils ont beaucoup à faire, et n'ont pas de temps à consacrer à quelque-chose qui n'a pas de raison-d'être commerciale. Quand ils lisent les normes, ils peinent à y trouver ce qui pourrait leur être utile, pour diverses raisons : outre le fait d'être difficiles à comprendre, ces documents peuvent très bien être de simples redites de ce que la plupart d'entre-eux savent déjà, tout en laissant de côté pas mal de vrais problèmes tels que l'interopérabilité (...) Le revers de la médaille est que, de cette manière, des problèmes cruciaux à un plus haut niveau de réflexion ne seront parfois pas traités (...) Si un problème est perçu comme marginal, il ne recevra probablement aucune solution, même s'il peut être très important pour une catégorie donnée d'utilisateurs.

Pour combler ce fossé entre les normes du W3C et l'implémentation, Aaron Leventhal met l'accent sur :

• Des documents didactiques concrets, tels que l'excellente liste de contrôle d'accessibilité Web d'IBM (un de mes vieux projets de traduction en français, d'ailleurs, qui n'a jamais pu être mené à bien pour des questions de droits) ;
• La conformité formelle aux normes (HTML, XHTML, CSS, WCAG), à l'image de la Communauté Européenne qui s'apprête à prendre les WCAG 2.0 comme base de ses recommandations uniformisées ;
• Un effort de documentation de la part des entreprises fournissant les logiciels d'accessibilité, voire l'adoption par celles-ci d'outils tels que Bugzilla.

Mozilla et l'accessibilité

En termes clairs, l'enjeu prioritaire pour Mozilla n'est pas la conformité aux Guide d'accessibilité des Agents Utilisateurs du W3C, mais le respect de son équivalent national états-unien, c'est à dire les douze critères de la section 508. Un état des lieux est disponible sur le site de la Fondation Mozilla.

Le bilan de l'accessibilité actuelle de FireFox semble plutôt positif, avec comme réserve la nécessité d'en polir certaines rugosités. A cet égard, les deux axes essentiels sont :

• Le rendu des documents, jugé plutôt bon, avec des avancées prévues côté DHTML et X-forms ;
• L'interface utilisateur, souffrant de problèmes spécifiques faute de prise en compte suffisante de l'accessibilité dès le départ. Il s'agit principalement de l'accès clavier à certaines fonctionnalités, et de contrôles tels que le gestionnaire de téléchargement dont les items ne sont pas reconnus de manière interactive par les lecteurs d'écran.

Accessibilité des applications : XUL ou application Web ?

Avec regret, Aaron Leventhal convient que les solutions Web sont préférables pour le moment, car [les] clients peuvent retomber sur leurs pieds avec Internet Explorer s'ils rencontrent un problème d'accessibilité dans Mozilla. Le problème de fond est que Windows est encore aujourd'hui la seule plate-forme pour laquelle existent des solutions d'accessibilité complète : ceci sera amené à changer profondément dans les années à venir, mais prendra du temps.

IBM et les avancées prévues pour Mozilla

En tant qu'architecte en accessibilité Web IBM, Aaron Leventhal retient trois axes principaux :

• L'accessibilité du DHTML, afin d'en rendre les contrôles accessibles via le clavier et les outils d'aides, ce qui prend une importance croissante avec des applications comme Gmail ;
• Egalement en matière de contenu dynamique, l'utilisation d'attributs HTML permettant de décrire l'état et la fonction d'éléments, de manière, par exemple, à pouvoir décrire une <div> sous forme d'arborescence.
• Enfin, les implémentations de Xforms et de SVG.

Pour compléter ce qui précède, rappelons ce que déclarait Aaron Leventhal dans une précédente interview en octobre dernier :

Pour IBM, je travaille aussi à quelque-chose de complètement nouveau et de très excitant : un moyen de rendre accessible les contenus Web dynamiques. En fait, contrairement à ce qu'ont affirmé beaucoup de gens, ce n'est pas le Javascript en lui-même qui est un problème. Le coeur du problème est le manque de contrôles (widget) de base en HTML, ainsi que d'un modèle d'accessibilité pour des contrôles personnalisés. En l'état actuel des choses, les gens doivent utiliser de multiples <div> et autres <span> pour créer ces contrôles, y compris pour des choses élémentaires comme des menus ou des arborescences. En outre, il y aura toujours besoin de créer des contrôles sur mesure dans les pages Web. Mais malheureusement, ces éléments génériques ne peuvent pas recevoir de focus ; ils ne sont pas navigables via la tabulation, et ils ne sont pas compris par les technologies d'aide.

XHTML, une voie entravée par Microsoft

En réponse à la question pensez-vous qu'XHTML pourrait être la panacée décisive du Webdesign accessible ?, Aaron Leventhal définit précisément les limites actuelles de ce format :

Tant qu'IE ne saura pas restituer du vrai XHTML, et qu'il ne saura pas utiliser les espaces de noms, les développeurs devront servir le XHTML avec un type mime différent pour IE et pour Mozilla (http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html). Or, l'enjeu essentiel d'XHTML est de pouvoir incorporer des contenus d'autres espaces de nom tels que Xforms et SVG. Dans la mesure où ceux-ci ne seront pas utilisables dans IE, c'est le concept tout entier qui perd son intérêt. Je ne pense pas que nous puissions considérer XHTML comme une panacée avant longtemps. Même si Firefox y parvient, je crains qu'il n'y ait peu de chances que Microsoft ne sorte un navigateur suffisamment compatible avec les standards, qui supporterait finalement des technologies rendant moins dépendant de Microsoft lui-même. Je ne pense pas non plus qu'IE devienne un navigateur périmé.