Un lecteur audio accessible : les critères que le lecteur lui-même doit tenir
Ajouter une version audio ne rend pas un site accessible si le lecteur, lui, ne l'est pas : navigation au clavier, lecteur d'écran, focus visible, contraste, mouvement réduit. Voici les critères que notre lecteur tient, lus dans le code, et ceux qui restent le travail du site.
Il y a une ironie fréquente dans les projets d'accessibilité : on ajoute un lecteur audio pour mieux servir les personnes qui lisent mal ou pas du tout, et le lecteur lui-même ne s'utilise qu'à la souris, sans libellé pour un lecteur d'écran, avec un focus invisible et une barre de progression qu'on ne peut pas déplacer au clavier. Le remède devient alors un obstacle de plus. Un composant qui parle d'accessibilité doit commencer par être accessible lui-même, sinon il ne fait que déplacer le problème.
Voici donc, concrètement, ce que notre lecteur tient. Pas une liste de bonnes intentions : des comportements qu'on peut vérifier en ouvrant le code du lecteur, et que nous décrivons ici parce qu'un acheteur public a le droit de les contrôler avant de signer.
Tout se fait au clavier
La première chose qu'un auditeur testera, et la première qu'un auditeur d'accessibilité essaie, c'est la touche Tabulation. La barre de progression de notre lecteur est un curseur atteignable au clavier : une fois le focus dessus, la flèche droite avance de dix secondes, la flèche gauche recule d'autant, la touche Début revient au commencement, la touche Fin saute vers la fin, et la barre d'espace ou Entrée lancent ou mettent en pause. Le bouton de lecture, lui, annonce son état : son libellé bascule entre « Lire » et « Pause » selon ce qui se passe, et ce changement est signalé pour qu'un lecteur d'écran le relaie.
Les chapitres, quand l'article en a, ne sont pas qu'une liste décorative : chaque chapitre reçoit le focus et se joue avec Entrée ou la barre d'espace, et le chapitre en cours est marqué comme tel pour la synthèse vocale de l'appareil. Les panneaux « Chapitres » et « Texte » déclarent s'ils sont ouverts ou fermés, de sorte qu'un lecteur d'écran ne propose jamais d'aller dans un panneau qui n'est pas là.
Le confort de lecture est annoncé, pas seulement affiché
Le panneau de texte, qui affiche l'article pendant qu'il est lu, porte un groupe de réglages de confort : agrandir ou réduire la taille du texte, aérer l'interligne, passer en fort contraste, basculer sur une police plus lisible. Chacun de ces réglages est un bouton qui dit s'il est actif ou non, pour qu'un utilisateur de lecteur d'écran sache dans quel état il se trouve sans avoir à le deviner. Le mode fort contraste n'est pas un simple assombrissement : il pose un fond noir, un texte blanc, et surligne en jaune le mot en train d'être lu, ce qui sert à la fois la basse vision et le suivi de lecture, comme nous l'expliquons à propos du texte synchronisé.
Le focus se voit, et le mouvement se calme
Un focus clavier invisible est aussi inutile qu'un focus absent : on ne sait pas où l'on est. Les éléments interactifs du lecteur gardent un contour de focus visible, avec une marge qui le détache du bord. Et pour les personnes que les animations gênent ou rendent malades, le lecteur respecte la préférence système « mouvement réduit » : l'animation de chargement s'arrête, et le défilement du texte lu devient instantané plutôt que glissé. Ce n'est pas un réglage dans le lecteur, c'est la préférence déjà posée par la personne dans son système d'exploitation, que le lecteur se contente d'honorer.
Ce qui reste le travail du site
Soyons honnêtes sur les limites, parce que c'est là que les malentendus coûtent cher. Deux choses, en particulier.
D'abord, les réglages de confort agissent sur le panneau de texte du lecteur, pas sur la page qui l'entoure. Le lecteur ne peut pas re-styliser votre article, votre menu ou vos encadrés : il n'a autorité que sur lui-même. Ensuite, les couleurs par défaut du lecteur héritent de celles de votre site. Le bouton de fort contraste garantit un rendu lisible quoi qu'il arrive, mais le rendu par défaut ne vaut que ce que vaut votre palette : un lecteur posé sur un fond gris clair avec un texte gris moyen restera peu contrasté tant que personne ne touche aux couleurs.
Surtout, et nous le répétons volontiers, un lecteur accessible ne rend pas votre site conforme. La navigation au clavier de l'ensemble de la page, la structure des titres, le texte alternatif des images, le lien d'évitement : tout cela est le socle du RGAA et relève du site, pas du lecteur. Nous détaillons cette distinction dans notre article sur la version audio et le lecteur d'écran, qui sont deux accessibilités différentes. Si vous vous demandez par où le lecteur s'ajoute sur votre site sans refonte, notre page WordPress décrit les chemins possibles et ce qu'ils touchent (ou pas) à votre thème.
Vérifiez-le vous-même
La meilleure preuve n'est pas un article, c'est la touche Tabulation. Activez notre lecteur audio sur un article, rangez votre souris, et parcourez-le au clavier. Si quelque chose vous résiste, c'est précisément ce que nous voulons savoir.
Sonorisez vos articles avec WeDispatch
Ce blog sera lui-même sonorisé par WeDispatch. Envie de voir ce que ça donne sur vos contenus ?
Demandez une démo