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 sites ludo-éducatifs (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éalité cette règle ne concerne que les sons supérieurs à 3 secondes. Si vos sons d’aide à la navigation sont inférieurs à cette durée, tout va bien. Mais si vous comptez aussi inclure des sons plus longs, par exemple une musique, un bruitage d’ambiance, vous devrez alors prévoir un bouton ou un raccourci clavier permettant de couper le volume sonore. Comment faire, alors, pour ne pas couper également les sons courts essentiels à la compréhension ? Vous pouvez diviser les sons en deux catégories, et faire en sorte que le volume n’influe que sur les sons non indispensables. C’est faisable en Javascript, en séparant par exemple les instances audio dans deux namespaces, l’un dédié aux sons à couper, l’autre à ceux à conserver.

 

Optimiser la navigation au clavier

Des choix techniques judicieux

Rendre tous les éléments interactifs accessibles au clavier est bien sûr la base. Cela revient dans notre cas à nous interroger sur certains choix techniques. L’utilisation de <canvas>, par exemple, pose quelques problèmes. Car même si c’est une alternative HTML5 relativement correcte au format Flash, ça n’en reste pas moins un objet totalement fermé, interprété comme un gros bloc hermétique par les lecteurs d’écran. Inutile, donc, d’espérer donner le focus d’une manière standard à des éléments dans le Canvas. Il existe des initiatives dans ce sens, mais pas encore supportées par la plupart des navigateurs. Personnellement, je n’utilise <canvas> que pour les animations non interactives, et lorsque je n’ai pas le choix je superpose dans le DOM des images transparentes qui captent les événements souris et clavier, par dessus les zones pseudo-réactives du Canvas.

Mac Gyver approuve

 

Inventer une navigation cohérente

Mais se contenter d’attribuer un « tabindex » à chaque zone réactive est largement insuffisant si l’on veut offrir une expérience agréable et cohérente à ses visiteurs. Sur des contenus riches comportant beaucoup d’éléments, il convient d’inventer une navigation parallèle à la navigation à la souris, obéissant à une logique propre.

Concernant la structure de la page par exemple : alors que, visuellement, les éléments peuvent être disposés dans le désordre, il faut respecter une architecture plus conventionnelle au niveau du DOM, en utilisant les balises <header>, <main>, etc, mais aussi les titres <h1>, <h2>…

Critère 9.2 [A] Dans chaque page Web, la structure du document est-elle cohérente ?

Dans le même esprit, la numérotation des « tabindex » (qui va déterminer l’ordre de défilement des zones réactives avec la touche Tabulation) peut varier par rapport à la disposition visuelle des éléments.

Capture d'écran décrivant l'ordre du flux de navigation au clavier
La numérotation des tabindex, qui détermine l’ordre de tabulation, peut différer de la disposition visuelle des éléments. Ici, il a été jugé plus cohérent de mettre le bouton « passer » après le bouton « suite », malgré sa place dans le header.

 

Mais ce n’est pas une raison pour jouer au ping pong avec le focus ! N’oubliez pas que la navigation au clavier n’est pas destinée qu’aux non-voyants, mais aussi aux handicapés moteur qui s’attendent logiquement à ce que le cheminement se fasse dans l’ordre de ce qu’ils voient à l’écran.

Critère 12.13 [A] Dans chaque page Web, l’ordre de tabulation est-il cohérent ?

A vous, donc, de juger au cas par cas ce qui est « cohérent ». Dans le même ordre d’idée, il faut gérer de manière intelligente l’accumulation d’éléments sur la page. Ainsi, lorsque vous avez 50 boutons actifs simultanément, il n’est pas envisageable d’obliger l’utilisateur à presser 50 fois la touche Tabulation pour traverser la page, là où cela ne prend qu’une fraction de seconde à la souris :

Critère 12.11 [A] Dans chaque page Web, des liens d’évitement ou d’accès rapide aux groupes de liens importants et à la zone de contenu sont-ils présents (hors cas particuliers) ?

Dans ce cas, l’utilisation des listes est une solution qui me semble appropriée. Vous pouvez programmer un script qui n’attribue un tabindex qu’au premier élément de chaque liste, et permettre ensuite à vos visiteurs de parcourir la liste avec les flèches de direction. Ainsi la tabulation permet de sauter rapidement d’une liste à l’autre, mais tous les éléments restent accessibles.

 

Ce genre d’astuce peut s’avérer particulièrement utile pour ne pas pénaliser un utilisateur du clavier sur les jeux de rapidité, avec un timer par exemple. Il reste néanmoins un paramètre que vous ne pourrez jamais maîtriser : selon la nature de son handicap, un joueur agira avec plus ou moins de célérité. Il peut être alors judicieux d’adapter dynamiquement le timer à la vitesse d’action que l’on peut facilement analyser en temps réel.

 

Jeu de rapidité avec timer intelligent
Dans ce jeu, la vitesse à laquelle les brigands s’approchent du chariot est ajustée en temps réel par un algorithme simple qui analyse l’agilité du joueur.

 

Une autre difficulté réside dans le fait que le flux de navigation change en permanence, de par le caractère dynamique du contenu. Par exemple, lorsque vous validez un item celui-ci peut devenir inactif tandis qu’un autre s’active simultanément. Vous n’avez pas le choix : vous devez faire en sorte que chaque élément accessible à la souris le soit aussi au clavier de manière synchronisée, et cela passe nécessairement par un script dédié.

La même question se pose lorsque vous utilisez plusieurs « couches » d’affichage, avec une lightbox ou un splash screen par exemple, qui viennent provisoirement masquer ce qui se trouve en-dessous. Dans ce cas, toutes les zones interactives à l’arrière-plan ne sont plus accessibles à la souris, et ne devraient donc pas l’être au clavier. Cela ne concerne d’ailleurs pas que les liens, mais aussi les images, textes, etc, qui devraient tous obtenir l’attribut aria-hidden=“true“, de manière à ne pas être atteints non plus avec les flèches de direction. Là encore, cela ne peut passer que par un script qui automatise l’opération.

 

Exemple de lightbox, avec boutons inaccessibles à l'arrière-plan
Lorsque cette fiche s’ouvre, elle rend le contenu à l’arrière-plan inaccessible à la souris. Un script rend ce contenu également inaccessible au clavier.

 

Définir des interactions standards

Enfin, il convient de trouver des équivalents appropriés à toutes les interactions à la souris. De même qu’une pression sur Entrée équivaut à un clic, il faut définir des touches et combinaisons de touches pour reproduire d’autres événements. Certaines équivalences sont assez évidentes : mouseover/focusin, mouseout/focusout, etc. Pour d’autres, il convient de se pencher un peu plus avant sur les standards de l’accessibilité.

Par exemple, la touche Echap peut être dédiée à la fermeture d’une pop-in. De même, c’est la barre d’espace qui devrait servir à cocher une case ou un bouton radio. Or, si vous n’utilisez pas le composant HTML standard (<input type=“checkbox“>), parce que vous souhaitez remplacer votre case à cocher par un sprite sheet, vous devrez utiliser les rôles aria (ici role=“checkbox“) et reproduire le comportement par défaut à l’aide de Javascript, comme sur cet exemple.

Pour des interactions encore plus complexes il vous faudra définir votre propre standard. Pour un drag and drop, par exemple, voici le comportement que j’ai mis en place :

 

Drag and Drop au clavier, étape 1
On commence naturellement par donner le focus à l’objet draggable avec le clavier.

 

Drag and Drop au clavier, étape 2
La barre d’espace « verrouille » l’objet, et le focus est automatiquement déplacé sur la première zone de drop. On peut alors naviguer entre les zones de drop (qui sont des items de liste) avec les flèches de direction. Comme si, à la souris, on survolait les zones avec l’objet.

 

Drag and Drop au clavier, étape 3
La touche Entrée équivaut à un drop de l’objet sur la zone qui a le focus.

 

Le fait d’utiliser la barre d’espace permet de séparer la sélection du clic, ce dernier restant réservé à la touche Entrée. C’est utile lorsque l’objet sélectionnable doit aussi réagir à un clic.

Attention : les lecteurs d’écran interceptent les événements clavier et les convertissent en événements souris, ce qui ne fait pas toujours vos affaires. Par exemple, le logiciel aura tendance à interpréter l’appui sur la barre d’espace comme un simple clic, ruinant nos efforts pour la distinguer de la touche Entrée. La solution est d’attribuer au conteneur de vos objets le role=“application“. Ce rôle sert précisément à indiquer aux lecteurs d’écran qu’ils doivent laisser passer les événements clavier originaux. Vous pourrez utiliser cet attribut dans d’autres cas, par exemple sur un jeu qui utilise les flèches de direction (celles-ci étant utilisées en temps normal par les lecteurs d’écran pour parcourir tous les éléments de la page).

Dura lex, sed lex

Ces expériences m’amènent à conclure qu’il est tout à fait possible d’allier accessibilité et contenus riches, mais au prix de beaucoup d’efforts. Des efforts pour rendre compatibles les critères du RGAA avec la nature même d’un site dynamique, mais aussi pour maintenir un semblant d’homogénéité dans l’expérience utilisateur, quel que soit son type de handicap ou sa configuration logicielle. J’ai ainsi pu mesurer les différences de fonctionnement d’un lecteur d’écran à l’autre, et les variations de leur comportement selon qu’ils sont associés à tel navigateur ou OS.

La réflexion mérite d’être menée, et doit être poursuivie, à plus forte raison parce que l’accessibilité des sites publics est encore aujourd’hui trop souvent sacrifiée faute de temps et de budget, malgré l’exigence légale dont elle est l’objet.

Et vous, qu’en pensez-vous ? Si vous êtes concepteur de sites, ces réflexions rejoignent-elles les vôtres, ou avez-vous d’autres pistes à proposer ? Si vous êtes spécialiste de l’accessibilité, ou atteint d’un handicap qui vous amène à utiliser ce genre de fonctionnalités, trouvez-vous ces solutions satisfaisantes ? Insuffisantes ? Quelles seraient vos suggestions pour les améliorer ?

2 réponses à “Accessibilité et contenus riches, un mariage contre-nature ?”

  1. Stéphanie Giacchi

    Merci Benjamin
    Cet article est vraiment très riche d’informations et explique clairement le travail que tu as mené sur ces projets.
    Je comprends mieux maintenant comment tu as réussi à accomplir « certaines exigences » si complexes à réaliser dans ce contexte !!!
    Tu nous as beaucoup apporté sur l’accessibilité de ce type de sites interactifs.

    Encore un grand Bravo
    À bientôt et bon courage pour la suite

    Stéphanie

    Répondre
  2. Georgia

    Super article que celui-ci ! Très précis, très documenté, très concret, qui s’appuie sur une véritable expérience pour développer des sites accessibles, dynamiques et riches en interactivité !
    Sacré pari réussi ! Espérons que les développeurs seront nombreux à lire l’article et à s’inspirer de ce travail remarquable.
    Espérons également que les utilisateurs de ces sites exprimeront leur intérêt et leur satisfaction car l’effort pour les rendre accessibles n’est pas des moindres !
    Georgia

    Répondre

LAISSEZ UNE REPONSE

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *