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

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é

Le DOM, le coté lumineux du HTML

À l’issue de 3 jours de formation sur les bases du HTML et de CSS, la stagiaire déclare:

en fait, on ne devrait pas utiliser Photoshop pour faire un site Web, mais partir directement du DOM.

Pardonnez mon immodestie, mais à ce moment précis, je me suis senti comme Obi Wan Kenobi réalisant qu’il vient de sauver le jeune Skywalker du côté obscur de la Force.

Continuer la lecture de Le DOM, le coté lumineux du HTML

Spécifications, ressources et références pour une base solide en HTML et CSS

Pour les besoins d’une formation intitulée « Bases du HTML et CSS », j’ai compilé une liste de liens vers des spécifications, ressources et articles qui m’ont paru pertinents. Continuer la lecture de Spécifications, ressources et références pour une base solide en HTML et CSS

Transcrire une vidéo: pour l’accessibilité, mais pas seulement!

Si vous me connaissez un peu, vous savez que je ne suis pas totalement fan du fait de « vendre » l’accessibilité par le biais des bénéfices induits. Je me suis exprimé là-dessus à différentes reprises, notamment sur ce blog (cf. Le véritable bénéfice de l’accessibilité, Accessibilité et bénéfices induits, petite mise au point, et plus récemment: Vulgariser l’accessibilité, oui. La dévoyer, non.).

Mais comme je ne suis pas à une contradiction près, je vais vous parler des avantages de faire transcrire vos vidéos, en plus du fait de les rendre accessibles. Continuer la lecture de Transcrire une vidéo: pour l’accessibilité, mais pas seulement!

Mise à jour des WCAG: quels impacts pour AccessiWeb et RGAA?

Comme chaque semestre, le W3C vient de publier une mise à jour des WCAG 2.0 (Web Content Accessibility Guidelines, version 2). Plus précisément, il s’agit d’une mise à jour des documents « Understanding WCAG 2.0 » et « Techniques for WCAG 2.0« . Le document central, celui qui décrit les critères de succès dans l’absolu, est en effet stable, car agnostique du point de vue des technologies. Ce sont les documents d’accompagnement qui sont mis à jour, pour rester en phase avec les évolutions technologiques.

Ceci a bien évidemment une incidence sur les référentiels AccessiWeb et RGAA, qui sont des méthodes de vérification de la conformité aux WCAG 2.0. Continuer la lecture de Mise à jour des WCAG: quels impacts pour AccessiWeb et RGAA?

Interview: accessibilité et gestion de projet

En faisant un peu de ménage dans mes documents, je suis retombé sur une interview écrite datant d’avant Accessiblog.fr. Je m’étais sûrement dit à l’époque que je la réutiliserais pour mon futur blog, je l’ai donc rangée bien comme il faut, et la voilà qui s’exhume. L’interview avait été sollicitée par une étudiante réalisant un mémoire sur le thème de la communication vers un public en situation de handicap grâce aux nouvelles technologies. Elle s’intéressait plus particulièrement au rôle du chef de projet dans le montage d’un site Web.

En relisant cette interview, je constate que ça reste cohérent avec ce que je prêche aujourd’hui, et qu’il n’est pas trop tard pour la publier, 3 ans après, avec quelques légères modifications.

Détail cocasse: c’est mon actuelle patronne, Véronique Lefèvre-Toussaint, qui l’avait orientée vers moi. Ô Destin, que tu es facétieux, parfois! Continuer la lecture de Interview: accessibilité et gestion de projet

On a retrouvé Virginie

Il y a quelques années, l’association Handicap International France avait eu la brillante idée d’acquérir une voix de synthèse pour Windows, et de la proposer en téléchargement libre. Cette voix au format Microsoft SAPI 5, baptisée Virginie, est nettement plus compréhensible, et confortable à l’écoute, que l’exaspérante petite voix de robot disponible par défaut dans NVDA (oui, Max, je parle de toi, là). C’est donc intéressant de l’avoir, ne serait-ce que pour faire des tests de lecteur d’écran dans de meilleures conditions.

J’étais très content d’avoir retrouvé l’URL de cette ressource dans des slides de formation que je suis en train de mettre à niveau pour le référentiel AccessiWeb HTML5+ARIA. J’allais pouvoir récupérer cette version-là, et non celle mise à dispo par un particulier que Google m’avait trouvée jusque là.

Visiblement, HI France s’est fait toper son nom de domaine dans l’intervalle, puisque l’URL en question m’amène sur le blog d’un adolescent anglais vivant en France…

Je vous propose donc ce fichier en téléchargement (archive ZIP, 23 Mo). Je ne sais pas ce qu’il en est de la licence, puisque le site de Handicap International France ne semble plus la proposer. Mais je prends le risque. Sachant où j’ai récupéré ceci, je ne peux pas non plus en garantir l’absence de virus et autres cochonneries. Sachez que l’antivirus intégré à Windows 7 n’a pas tiqué, donc, bon…

Alternativement, vous pouvez télécharger les voix françaises gratuites proposées par NVDA, Harmonie (hu hu) et Hortense. Mais il vous faudra également installer le moteur Microsoft Speech Version 11.

Allez, je retourne écouter Virginie me répéter « allons-y »… Pardon, « a onze y »!

A propos des tests utilisateurs en accessibilité

Cela fait un moment que traîne l’idée d’un billet sur les tests utilisateurs, dans ma pile « articles à écrire dans pas longtemps », qui est haute comme ça et dont certains items ont 3 ans.

Un article paru sur le site d’Ochelys et intitulé Les tests utilisateurs pour l’accessibilité m’a  donné l’occasion de rédiger un commentaire, devenu mini-topo, qui jette les bases d’une réflexion écrite sur la question. Continuer la lecture de A propos des tests utilisateurs en accessibilité