Comme vous l’avez très justement souligné dans votre article, il ne suffit pas de mettre à disposition des personnes handicapées les outils et la technologie nécessaires : une synthèse vocale aussi performante soit-elle ne pourra pas franchir les barrages d’accessibilité présents dans le contenu des sites (vous citiez les images mais il y en bien d’autres). Il s’agit donc de faire évoluer ces contenus, ce qui exige de s’adresser à ceux qui les font.

C’est là où on se heurte à une difficulté de taille : rendre accessible un site Web est majoritairement perçu par les responsables et les concepteurs des sites comme l’ajout d’une surcouche technique sur le site, et donc comme un surcoût. Or, tout l’enjeu de la normalisation actuelle est modifier cette approche : l’accessibilité n’est pas une surcouche coûteuse à ajouter. Elle est au contraire intégrée dans chaque étape de développement du site, via les formats normalisés qui ont de multiples bénéfices en dehors de cette question. Elle n’a pas, finalement, autant de coûts spécifiques qu’on le croit, et elle génère des bénéfices qui ne dépendent pas uniquement du nombre de personnes handicapées dans l’audience du site. Cette approche, qui renverse les idées communément admises, nécessite un travail pédagogique de longue haleine. Et, par exemple, un investissement important du côté des formations aux métiers du Web (Université, etc)

Les progrès accomplis via l’approche « normative » de l’accessibilité peuvent sembler lents, mais il s’agit de faire évoluer non seulement les pratiques et les compétences, mais aussi la culture professionnelle des métiers concernés, ce qui n’est pas une tâche aisée ;)

D’autre part, concernant le prix des solutions du type Jaws : les coûts de développement sont en effet très élevés. Car la difficulté n’est pas tant dans la partie « synthèse vocale » que dans la non-normalisation des contenus, justement. Tout comme un navigateur, un lecteur d’écran doit traiter avant tout des contenus non normalisés et imprévisibles, qu’il faut identifier et anticiper (notamment en mettant en place une quantité considérable de traitement d’erreurs). Et avec l’essor des contenus dynamiques, il ne s’agit pas seulement de lire de contenu, mais surtout de permettre à l’utilisateur d’interagir avec celui-ci : c’est là que les besoins en développement sont les plus élevés car les technologies sont encore à inventer. Un excellent exemple : la contribution d’IBM pour améliorer l’accessibilité de ces contenus dynamiques (DHTML) en étendant les capacités du navigateur Firefox 1.5 - http://www-306.ibm.com/able/news/firefox.html . C’est le résultat d’un énorme travail de recherche & développement.

Mais le navigateur peut être malgré cela un produit économiquement viable même s’il est diffusé gratuitement ou pour un prix très réduit : c’est un produit d’appel pour des services ou des applications associées, qui rentabilisent son développement (exemple : Firefox, plate-forme pour les produits et services IBM. De même, IE7 produit d’appel pour Windows Vista). Ce n’est pas le cas aujourd’hui pour le lecteur d’écran. Cette situation peut être amenée à changer, si le développement des navigateurs vocaux initié par Opera et (à nouveau) IBM se poursuit : il n’est pas exclut que cela aboutisse à terme à des navigateurs capables de jouer (en partie au moins) le rôle de lecteurs d’écran. Pour un coût nettement différent.