À propos des widgets de vocalisation

En relisant un rapport d’audit RGAA livré il y a quelques mois, je retombe sur ce passage:

Widget [Peu importe]

Ce widget permet de vocaliser les contenus de la page.

Il ne s’agit pas, cependant, d’une solution de vocalisation de type lecteur d’écran (qui lit les contenus à la demande et permet de naviguer dans ce contenu, et d’interagir avec lui). Les contenus textuels sont en effet injectés dans le code JavaScript sous une forme interprétable par le widget. C’est donc limité aux contenus textuels configurés pour être restitués, ce qui exclut, par exemple, les menus de navigation. Un cas emblématique : sur la page de recherche d’offres d’emplois, seules les 2 phrases d’introduction sont restituées, et non le contenu du formulaire de recherche ; ce qui en limite fortement l’intérêt.

Il n’est par ailleurs pas possible pour l’utilisateur d’interagir avec le contenu, autrement qu’en agissant sur le défilement. Il ne peut pas, par exemple, cliquer sur un lien qui serait vocalisé.

Certains éditeurs de solutions similaires avancent qu’elles permettent de rendre un site accessible. Il n’en est rien ; il s’agit simplement d’un mode de restitution alternatif, avec les limitations décrites ci-dessus.

De ce fait, cette solution ne représente pas une alternative valable à un lecteur d’écran, et ne dispense pas de mettre en conformité les contenus. On peut par ailleurs supposer qu’un utilisateur nécessitant une vocalisation aura utilisé, pour parvenir à la page, une solution capable de vocaliser toutes les applications du système d’exploitation, dont le bureau et le navigateur.

Le widget lui-même n’est pas accessible : il ne comporte pas de nom accessible permettant d’en comprendre la fonction s’il est consulté avec un lecteur d’écran, et la fenêtre « popover » qui permet de le configurer, ne respecte pas les standards de codage ARIA. Par ailleurs, il ne fonctionne pas au clavier.

Compte tenu de ses limitations fonctionnelles, et de son inaccessibilité, il faudrait vérifier l’intérêt réel de ce widget du point de vue utilisateurs. Il serait donc intéressant d’en étudier les statistiques d’usage. Cela permettrait d’estimer la valeur du service rendu, rapporté au coût de la solution.

Avec le recul, je n’en changerais pas une ligne. Et je pense même que je pourrais le copier-coller pour toute « solution » équivalente, hormis bien sûr pour le passage sur l’accessibilité du widget. Si vous voulez vous l’approprier et le réutiliser, vous avez mon accord, et même mes encouragements.

On ne le répètera jamais assez: une solution de vocalisation, dans le meilleur des cas, n’est rien d’autre qu’une version audio du contenu. Cela ne peut pas être équivalent aux services rendus par un véritable lecteur d’écran.

C’est peut-être le nom de « lecteur » qui est trompeur: en réalité, ces outils permettent de consulter des contenus structurés, via un modèle du contenu appelé « arbre d’accessibilité », et surtout d’interagir avec eux. Lorsque le lecteur d’écran expose un élément interactif à l’utilisateur, ce dernier peut effectuer des actions que le lecteur d’écran va répercuter sur l’arbre d’accessibilité, qui va lui-même les transmettre au navigateur (ou à toute appli en cours d’utilisation, en fait). On est donc bien au-delà de ce que permet un flux audio statique.

Personnellement je n’ai aucun problème avec les versions vocales. Il est possible que cela serve à des gens qui ne veulent pas plus que cela. Au long de mon parcours, j’ai rencontré une personne — et une seule, mais peu importe — qui m’a dit utiliser ces widgets pour écouter des sites web pendant qu’elle conduit, comme on le ferait avec des podcasts (là où c’est cocasse, c’est que cette personne est malentendante, ce qui met à mal certains clichés. Mais passons!). Donc il y a un usage et un public potentiels, je le concède.

Là où je m’insurge, en revanche, c’est lorsque ces technologies sont présentées par leurs promoteurs comme des solutions rendant les sites accessibles. Il n’y a rien de plus faux, évidemment (relire le passage du rapport précité). Pourtant, cela détourne des budgets et des ressources d’un véritable travail de fond sur l’accessibilité, portant sur le code et les contenus. Or, comme le rappelait Karl Groves dans son incontournable Can Assistive Technology Make a Website Accessible?, c’est là que l’accessibilité se joue, et pas au niveau des technologies d’assistance. Un outil d’assistance, quel qu’il soit, ne rend pas accessible un site web, pas plus qu’un fauteuil roulant rend accessible un bâtiment.

Il est dommageable pour tout le monde (hormis les éditeurs de ces semi-solutions, bien sûr), de laisser courir ce genre d’idées. D’où mon encouragement à réutiliser mon analyse en début d’article. Encore une fois, je n’ai aucun grief à l’encontre de ces widgets; certains sont accompagnés, d’ailleurs, d’un discours promotionnel tout-à-fait sain et réaliste. Mais c’est loin d’être le cas de tous. Certains vont jusqu’à affirmer que leur plugin va rendre un site conforme aux standards d’accessibilité; voire même que la Directive Européenne d’Accessibilité va les rendre obligatoires! À ce niveau, on n’est plus dans le mensonge: on peut parler d’escroquerie et d’abus de confiance…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *