Article | Longueur moyenne
Des bandes annonces accessibles ? Oui, on y travaille
June 2021
Stéphane Deschamps, illustration Marina Jaquet
Spontanément, on penserait que la publicité n’est pas la priorité des sujets à rendre accessibles. Oui mais il ne faut pas la négliger non plus : ce n’est pas parce que j’ai un handicap, vous dira avec raison votre utilisateur, que je ne dois pas être au courant de la mise à disposition sur vos plateformes d’un film que je veux voir ! Nous avons donc lancé un chantier sur le sujet en 2020.
L’héritage de Flash : bien, mais pas top !
À l’origine les bandes-annonces étaient développées en Flash par les animateurs. C’est une technologie d’animation qu’on a tous connue jusqu’à ce qu’elle tombe en désuétude, d’abord par un boycott d’Apple qui ne voulait pas de Flash sur les iPad, puis par l’évolution d’un ensemble de technologies standards qu’on appelle HTML5 (pour faire simple).
Adobe Animate a ensuite remplacé Adobe Flash, en s’appuyant justement sur cette combinaison de technologies :
– Canvas : pour faire simple, c’est un format image, comme un GIF, mais qui est généré dynamiquement par JavaScript, il est donc possible de l’animer à la volée — par exemple pour faire une bande-annonce,
– JavaScript, qui permet d’écouter les événements qui surviennent dans le navigateur : un clic sur un bouton pour couper/remettre le son, un clic pour rejouer la bande-annonce, un clic sur la vidéo pour atteindre la page vers laquelle pointe la publicité.
Les problèmes d’accessibilité qu’on constatait
Ces bandes annonces posaient les problèmes suivants :
– pas de sous-titres (donc soucis pour nos clients malentendants ou sourds),
– pas de possibilité de naviguer au clavier dans les contrôles de la vidéo, ni de suivre le lien promu,
– pas d’explicitation des contenus pour un client utilisant un lecteur d’écran (en bref un client mal ou non voyant).
Première étape : ajouter les sous-titres
C’est la question la plus facile à traiter : nous avons proposé au chef de projet de la régie de les intégrer directement dans le flux vidéo. Ça tombe d’autant mieux que les navigateurs ne veulent plus démarrer automatiquement une vidéo si le son n’est pas coupé !
Ainsi nous avons réglé en même temps notre souci premier d’accessibilité aux personnes en situation de handicap et une contrainte technique forte : les gens qui n’ont pas activé le son ont la même information que les autres.
Deuxième étape : gérer la navigation au clavier
Pour pouvoir naviguer au clavier, il a fallu revenir aux composants de base de la vidéo :
– une vidéo au format MP4,
– des pictogrammes en SVG,
– des gestionnaires d’événements.
En HTML5, on est équipé pour insérer une vidéo (avec la balise du même nom) et lui parler avec JavaScript (il existe une API « média » qui permet de dire des choses comme mavidéo.play() pour la jouer, mavidéo.muted=true pour la rendre muette, etc.).
Il s’est donc agi simplement de mettre les pictogrammes dans des boutons HTML et d’y associer des gestionnaires d’événements en JavaScript : au clic, fais telle action.
Nous avons dû aussi faire en sorte que l’objet vidéo lui-même ne soit pas focusable (autrement dit, au clavier, on ne peut pas l’atteindre en tabulant), pour simplifier la navigation au clavier. De plus il a fallu ajouter un lien transparent par-dessus la vidéo : ce lien est focusable nativement, et pointe vers l’URL fournie par la régie publicitaire.
Troisième étape : concevoir pour les lecteurs d’écran
Il restait quelques subtilités pour les lecteurs d’écran :
– Chaque bouton doit indiquer sa fonction (« Mettre le son de la vidéo » / « Rejouer la vidéo ») ; pour ce faire nous nous appuyons sur quelques attributs qui sont faits pour ça (aria-label pour le bouton, aria-hidden pour le SVG qui le dessine).
– Le lien doit comporter un vrai texte lisible par un lecteur d’écran, que nous masquons visuellement afin de ne pas surcharger l’interface (pour les connaisseurs, on utilise une classe sr-only tirée de Bootstrap).
Des gains attendus et la cerise sur le gâteau !
Il nous reste à faire en sorte que le cadre qui appelle la bande-annonce soit lui-même bien décrit (c’est ce qu’on appelle une iframe , une page de cadre interne à la page web que consulte le client), mais pour le reste le travail est fait et fonctionne :
– Les éléments sont manipulables au clavier.
– Les éléments sont correctement décrits pour un lecteur d’écran.
– Les sous-titres sont systématiquement insérés.
Nous ne soupçonnions pas, en commençant ce projet, que nous allions en plus obtenir un résultat bien plus économe en termes de bande passante : par le passé, quand on insérait une vidéo avec le système qui était en place, les bibliothèques d’Adobe Animate inséraient environ 246ko (kilo-octets) de code, sans compter le HTML enveloppant. Notre nouveau code accessible pèse environ 8ko, tout compris.
Si on part sur une estimation moyenne de 18 millions de vues par mois sur les bandes annonces, le gain de bande passante mensuel est d’environ 4.2To (téra-octets) ! Et qui dit gain de bande passante dit aussi allègement de notre empreinte carbone.
Au final, notre démarche a été bonne autant pour l’accessibilité que (surprise) pour notre bilan carbone, c’est tout bénéfice !