Comparatif accessibilité : Reveal versus AccesSlide (1/2)

Tout d’abord AccesSlide, il ne semble pas accessible, nous pensons qu’il l’est. Il a été construit pour. C’est même la première contrainte de développement de cet outil, comme tous les outils développés par Access42.

Ensuite, non AccesSlide n’a pas de zone aria-live. D’ailleurs, pourquoi imposerions-nous un tel choix à l’utilisateur ?

Nous ne proposons pas d’aria-live dans AccesSlide, mais qu’offrons-nous que Reveal n’offre pas ?

Voici un petit comparatif en termes d’accessibilité sur ces deux frameworks de diaporama.

role="application" … mais pourquoi est-il aussi méchant ?

Débutons par un témoignage de Sylvie, utilisatrice aguerrie de lecteur d’écran et de sites web inutilisables 🙂

Cet outil de diaporama en HTML peut être déroutant pour un utilisateur qui arrive pour la première fois sur la page de départ. Lorsqu’on utilise cet outil avec un lecteur d’écran, comme NVDA par exemple, on ne se rend pas compte qu’il y a un diaporama et que des boutons sont présents pour interagir avec les diapos.

Un utilisateur lambda ne sait pas toujours ce que veut dire « application » lorsque NVDA le prononce. C’est pourquoi, en arrivant sur la page, il ne verra que deux liens.

Lorsque l’internaute entend le terme « application », il lui faut passer en mode « application » pour voir apparaître les boutons en appuyant sur entrée ou insert + espace. Chose peu intuitive, pour accéder à ces boutons, il faut appuyer sur majuscule + tabulation.

Une fois les boutons apparus, il n’est plus nécessaire d’activer le mode application pour naviguer. Il faut trouver le bouton pour aller à la diapo suivante ou retourner à la diapo précédente.

La présentation de l’outil indique que certains raccourcis clavier peuvent être utilisés, mais ils ne semblent pas être compatibles avec l’utilisation d’un lecteur d’écran.

Il pourrait être utile dans l’aide de pouvoir trouver la liste de ces raccourcis.

Bien. Pour utiliser et comprendre Reveal, un utilisateur aveugle va devoir donc faire preuve de perspicacité.

En effet, comme Sylvie le relève, Reveal met sur le container principal du code, le role="application".

L’utilisation du role="application" implique que le lecteur d’écran n’intercepte plus le clavier. Ceci a pour effet de désactiver l’ensemble des fonctionnalités de navigation habituelles.

C’est alors au développeur de fournir, via JavaScript, tous les raccourcis clavier permettant d’utiliser son application. De fait, dans Reveal, il est impossible d’aller au titre précédent ou suivant en utilisant la touche H (par exemple, avec NVDA), d’atteindre une liste, etc.

La sémantique native est donc perdue, les utilisateurs de lecteurs d’écran n’y ont plus accès, les raccourcis clavier habituels sont inopérants… il faut juste découvrir comment les récupérer. La meilleure façon de pouvoir retrouver ces raccourcis claviers est tout simplement … de désactiver le role="application".

De plus, reprogrammer les touches du clavier pose certains soucis. Par exemple, la touche flèche bas permet de parcourir le contenu de manière linéaire. Or, dans Reveal, la touche bas va permettre de… faire défiler la slide « vers le bas ».

Dans AccesSlide, aucun problème. Un diaporama n’étant pas une application, il n’y avait aucune raison de mettre un role="application". Les utilisateurs peuvent aller de titre en titre, de liste en liste, etc. Les repères et les habitudes de navigation sont conservés.

aria-live="polite"

Continuons avec le témoignage de Sylvie lors de sa découverte de cette fameuse zone vocalisée automatiquement.

La première fois que j’ai activé le bouton « diapo suivante », j’ai entendu du texte que j’ai pris pour le titre de la diapo. J’ai été informée depuis, que c’est le texte de toute la diapo qui était vocalisé. Ceci est un inconvénient si ce texte est long, d’autant que le lecteur d’écran ne prononce pas ce texte dans la bonne langue. Pour que le texte soit prononcé correctement, il faut interrompre la vocalisation du lecteur d’écran, revenir en haut de page avec le raccourci adéquat et lire le contenu, qui est alors prononcé dans la bonne langue.

Au chargement d’une nouvelle slide, Reveal, dans un container caché possédant la propriété aria-live="polite", injecte le contenu texte. Ceci a pour effet de vocaliser tout le texte présent au chargement de la slide.

Encore une fois, le contenu injecté dans ce container, qui permet la vocalisation, ne possède plus de sémantique, ce sont uniquement les nœuds textes qui y sont repris. Donc, si la slide, possède un titre de niveau 2 et une liste à puces, cette sémantique disparaît.

Autre problématique, celle du choix de l’utilisateur. Est-ce qu’un utilisateur aveugle, qui utilise un lecteur d’écran, souhaite inconditionnellement s’entendre lire le contenu de la diapo dès qu’il l’affiche ?

Dans AccesSlide, certes, cette fonctionnalité n’est pas présente. Cependant, l’idée est excellente et nous pensons à l’intégrer, mais nous ne l’offrirons qu’en option. C’est à l’utilisateur de choisir de l’activer ou non.

La suite de ce comparatif à venir dans un article à paraître jeudi 7 avril…