Accessibilité et contenus riches, un mariage contre-nature ?

Retour d’expérience

Image d'illustration de l'articleDepuis quelques années, tous les sites web édités par les établissements publics sont censés être accessibles. L’accessibilité passe par différents dispositifs à intégrer lors de la conception du site Internet, comme le fait de pouvoir naviguer dans une page avec le clavier plutôt que la souris, ou le respect de certaines règles permettant aux lecteurs d’écrans de pouvoir transcrire le contenu via une synthèse vocale. Tous les critères auxquels se conformer pour rendre un site public accessible figurent désormais dans le Référentiel Général d’Accessibilité des Administrations (RGAA). On y trouve par exemple des préconisations liées au contraste des couleurs, ou encore comment rédiger correctement une alternative textuelle à une image.

J’ai été récemment sollicité par la Cité des Sciences pour concevoir deux trois sites ludo-éducatifs (lien, lien et lien), en HTML5, comportant chacun de nombreux jeux et animations interactives. Cet établissement étant public, la demande incluait donc un volet accessibilité avec nécessité de se conformer au RGAA. Or, les critères de ce référentiel, a priori bien adaptés à un site classique, le sont nettement moins lorsqu’il s’agit de les appliquer à des contenus dynamiques à l’interactivité poussée. J’ai donc été amené à réfléchir à des solutions, en lien avec l’équipe de la Cité des sciences, en partant de zéro car je n’ai jamais réussi à trouver d’exemple similaire de « contenus riches accessibles ». C’est pourquoi, après quelques centaines d’heures d’arrachage de cheveux, je me dis qu’il n’est pas inutile de partager les fruits de ces réflexions.

Un mariage contre-nature ?

c’est contre-nature

Disons-le d’emblée, les critères du RGAA ont été pensés pour s’appliquer aux sites standards, c’est à dire les 99,9 % de pages web statiques qui contiennent des paragraphes, des images, des vidéos, des liens et formulaires basiques. Ils n’ont pas du tout été prévus pour des « contenus riches » : jeux, animations à l’interactivité poussée, pages qui évoluent en direct. Exemple avec la règle suivante :

Critère 7.2 [A] Pour chaque script ayant une alternative, cette alternative est-elle pertinente ?

Comme expliqué ici, ce critère doit permettre aux « internautes qui ont désactivé les scripts dans leur navigateur [d’avoir] accès à la même information que les autres internautes ». Un critère évidemment inapplicable pour un site dynamique dont le contenu repose entièrement sur des scripts. Autre exemple :

Critère 10.4 [AA] Dans chaque page Web, le texte reste-t-il lisible lorsque la taille des caractères est augmentée jusqu’à 200 %, au moins ?

Sur une page classique, agrandir le texte va généralement pousser le reste du contenu vers le bas, ce qui ne pose pas de problème particulier. Mais ça peut devenir plus compliqué sur un site de type serious game, par exemple, comme dans le cas où une zone de texte se trouve cernée par des éléments visuels qui ne doivent pas être décalés. Il y a donc plusieurs approches :

  1. modifier le contenu pour respecter le critère à la lettre (par exemple ici, prévoir une zone plus large pour accueillir un texte agrandi)
  2. trouver une alternative équivalente au critère (affichage d’une pop-in avec le texte en plus gros…)
  3. abandonner ce critère s’il est inapplicable, de par la nature du contenu.

Cela revient souvent à se poser cette question : dois-je me contraindre à respecter les critères à la lettre, au point de nuire à l’esthétique, dois-je sacrifier une fonctionnalité importante uniquement parce qu’elle ne peut pas être rendue accessible, du fait de sa nature ? A vous de savoir où placer le curseur, sachant que la solution idéale est celle qui va fonctionner sur les deux fronts ! Dans tous les cas, cela implique d’avoir parfaitement assimilé les tenants et aboutissants des critères. Ce n’est qu’à cette condition que l’on pourra faire preuve de souplesse, voire s’affranchir de certaines règles au cas par cas.

 

représentation d'un arbre de parenté
L’arbre phylogénétique est impossible à retranscrire textuellement en vue d’une interaction (ici : faire glisser les caractères sur les noeuds).

 

De toute façon, se contenter d’appliquer les critères du RGAA me semble généralement insuffisant pour un site dynamique comme celui-ci. Car si un tel contenu implique naturellement une certaine créativité dans la forme, dans l’ergonomie, au niveau du gameplay, il faut alors faire preuve de la même créativité dans le domaine de l’accessibilité, adopter une certaine logique pour répondre à des questions telles que : comment permettre à un malvoyant d’appréhender une page dont la structure est atypique ? Comment faire en sorte qu’il s’y retrouve dans un contenu essentiellement visuel et fluctuant ? Quelles solutions offrir à un handicapé moteur pour qu’il ne soit pas pénalisé sur des jeux chronométrés, ou encore qu’il n’ait pas à parcourir des dizaines d’éléments avec son clavier dans un sens et dans l’autre, là où une demi-seconde suffit à un « valide » pour traverser l’écran avec son curseur ?

Quelques pistes

Comment retranscrire un contenu visuel riche ?

Soigner la lisibilité

Pour commencer, il y a quelques règles incontournables qui faciliteront la perception des éléments par les malvoyants, comme le choix d’une police de caractère lisible, mais aussi :

Critère 3.3 [AA] Dans chaque page Web, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé (hors cas particuliers) ?

Cette règle, accompagnée de valeurs de contraste précises, est un parfait exemple de la façon dont l’accessibilité peut interférer avec l’esthétique, ce qui peut se révéler frustrant pour un graphiste. Par ailleurs, même si le RGAA ne le mentionne pas, il sera nécessaire de veiller également au contraste des boutons et autres éléments interactifs.

Des textes explicites

Ensuite, il convient de trouver des solutions pour retranscrire au mieux le contenu pour les non-voyants. Pour un jeu, cela passe avant tout par une consigne explicite, qui va déjà donner une idée à l’utilisateur de ce qu’il s’attend à trouver sur la page. Puis au sein du contenu lui-même, il est judicieux de placer des repères pour jalonner la progression. Par exemple en exploitant le critère :

Critère 1.1 [A] Chaque image a-t-elle une alternative textuelle ?

C’est la base, bien sûr, mais nous pouvons aller plus loin en rendant l’attribut Alt dynamique. Celui-ci peut être mis à jour avec Javascript, permettant à l’utilisateur de savoir, par exemple, si l’image associée est un item déjà ou pas encore validé.

Image montrant le code source d'une image dont l'attribut ALT est mis à jour dynamiquement

 

Il faut aussi trouver des solutions pour rendre compte d’un changement d’aspect de la page ou d’une partie de la page, par exemple lorsqu’un jeu est validé et que l’on change d’étape ou de niveau. Un non-voyant ne peut pas deviner qu’une série de vignettes est apparue, ou qu’un personnage s’est déplacé, si on ne le lui indique pas. Une simple consigne qui change doit être lue en priorité par les lecteurs d’écran, par exemple en forçant le focus sur la consigne à chaque mise à jour de son contenu. Un comportement pas toujours approprié, dans la mesure où il peut totalement perturber l’utilisateur qui avait besoin, pour poursuivre le jeu, de garder le focus sur un élément éloigné dans la page. Dans ce cas, une autre solution consiste à donner à la consigne l’attribut aria-live=“polite“ (voire même “assertive“), qui – théoriquement – suggère aux lecteurs d’écran de lire le nouveau texte en priorité. Malheureusement j’ai pu constater à quel point ils réagissent aléatoirement à cet attribut.

Quant aux séquences où l’information est purement visuelle, une animation linéaire sans texte par exemple, il est possible de créer un principe d’audiodescription à l’aide des lecteurs d’écran. Il suffit de créer un champ texte masqué à l’écran, de lui adjoindre l’attribut aria-live=“assertive“, et lui injecter au moment voulu un texte descriptif pour provoquer sa lecture immédiate par la synthèse vocale. Attention, pour masquer le texte n’utilisez pas la règle CSS display:none qui le rendra également invisible aux lecteurs d’écran. Préférez visibility:hidden éventuellement couplée à une taille de 1 x 1 px.

 

Des sons explicites

Enfin, il faut utiliser autant que possible des sons clairement identifiables qui valident ou non une action, ou marquent le début et la fin d’un jeu. Un simple jingle de bonne réponse suffit au non-voyant pour comprendre qu’il a effectué la bonne action, et permet de se passer de texte. Attention, utiliser les sons peut sembler contradictoire avec ceci :

Critère 4.18 [A] Chaque son déclenché automatiquement est-il contrôlable par l’utilisateur ?

En ré