À 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…

L’État français s’entoure d’un groupement d’entreprises expertes pour rendre ses services en ligne accessibles

[Communiqué] Déjà en 2014, la France était désignée première nation européenne en matière d’administration numérique par l’Organisation des Nations Unies. Ces derniers mois, le Gouvernement a clairement affiché son ambition de simplifier les démarches des particuliers et des entreprises grâce à Internet. Continuer la lecture de L’État français s’entoure d’un groupement d’entreprises expertes pour rendre ses services en ligne accessibles

Comment je priorise les correctifs d’accessibilité

Faire un audit d’accessibilité, c’est bien. C’est même bien souvent indispensable. Proposer des correctifs, c’est encore mieux! Car évidemment, le fait de constater un problème n’a d’intérêt que si cela a pour but de résoudre ce problème. Continuer la lecture de Comment je priorise les correctifs d’accessibilité

L’accessibilité, peut-on s’en foutre parce que ça coûte ?

Tout a commencé par un commentaire désabusé d’un certain QuentinC, lors d’une discussion sur le forum d’Alsacréations, au départ très badine. QuentinC, internaute  « directement concerné » par l’accessibilité, fait l’amer constat que selon lui, l’accessibilité des sites Web n’a pas franchement progressé depuis 5 ou 6 ans (on devine au travers du message qu’il est utilisateur de lecteur d’écran). Prenant comme exemple un échange infructueux avec l’équipe du Site du Zéro, il en conclut même que, pour les professionnels, l’accessibilité c’est bien, mais on s’en fout. Continuer la lecture de L’accessibilité, peut-on s’en foutre parce que ça coûte ?

Pour le Web, il est temps de sortir de l’amateurisme

En lisant un fil de discussion sur la liste Accesstech, à propos de First Step, liste de bonnes pratiques d’accessibilité initiée par Aurélien Levy, j’ai éprouvé le besoin de réagir. Je vous invite d’ailleurs chaudement à lire l’article sur le blog de Temesis qui introduit First Step, et à contribuer au workshop si vous en avez la possibilité. Cette liste vise à recenser le minimum de ce qu’il faut savoir pour coder accessible pour le web. Comme l’a très bien résumé Yves Convert sur ce même fil de discussion: elle propose une liste de critères en deçà desquels la valeur ajoutée d’un expert accessibilité est discutable.

Pour résumer ce qui m’a titillé: certaines réponses, pourtant par des gens qui sont loin d’être des billes, indiquaient une crainte qu’une liste d’apparence aussi massive soit rebutante, et du coup rejetée à l’entrée d’un projet. Pas forcément par eux-mêmes, mais par les décisionnaires sur le projet. Mais rappelons-nous qu’une mauvaise décision n’est généralement que l’enfant d’une mauvaise information (quelqu’un a dû dire ça bien mieux que moi, mais c’est l’idée qui compte). Et ce billet vise à vous encourager à être la source plutôt que le barrage des bonnes pratiques, vous, les néo-prolétaires du Web (attention, contient des traces d’Arlette Laguillier). Continuer la lecture de Pour le Web, il est temps de sortir de l’amateurisme

L’accessibilité est-elle soluble dans la qualité?

Avant-propos: Cet article, rédigé par Jean-Pierre Villain, est la copie conforme de son article original publié sur le site de Qelios. Il est dupliqué ici afin de l’ouvrir aux commentaires, cette fonctionnalité n’étant pas disponible sur ce site (pour le moment, ça va changer très vite…). Continuer la lecture de L’accessibilité est-elle soluble dans la qualité?

Accessibilité et SEO : amies ou ennemies ?

Fréquemment, les notions d’accessibilité et de SEO (Search Engine Optimization, Optimisation pour les moteurs de recherche) sont présentées comme des domaines connexes de la qualité web. Plus précisément, les promoteurs de l’accessibilité du web font valoir le fait qu’un site accessible aura un bon référencement. C’est un argument fort en faveur de l’investissement sur l’accessibilité d’un site, puisque cette action devrait permettre d’économiser des frais d’optimisation de référencement. D’ailleurs, lorsque je forme des spécialistes de SEO à l’accessibilité, ils me confirment que 80% des critères d’accessibilité correspondent à des bonnes pratiques de SEO. Perception empirique bien sûr, mais assez partagée par mes interlocuteurs.

On pourrait se satisfaire de ce plébiscite. Mais qu’en est-il des 20% manquants ? Est-ce qu’ils sont totalement neutres ? Ou cachent-ils au contraire une opposition de pratiques ? Cet article propose d’explorer les limites de cette association a priori vertueuse de l’accessibilité et du référencement. Continuer la lecture de Accessibilité et SEO : amies ou ennemies ?