Accessibilité, par où commencer ?

Écrit par Raphaël C

Course de personnes en fauteuil roulant. Photo par Audi Nissen.

L’accessibilité devient de plus en plus incontournable en France, notamment depuis l’application en 2020 du décret du 24 juillet 2019 imposant à de nombreuses entreprise de respecter le RGAA 4 (sous peine de grosses amendes). Pour autant, l’accessibilité reste un sujet mystérieux pour beaucoup de développeurs.

Ce guide a pour but de vous présenter plusieurs points auxquels il est indispensable de penser pour que votre site soit accessible.

Introduction obligatoire

Ceci est un passage obligatoire dans toute présentation de l’accessibilité qui se respecte : l’accessibilité concerne tout le monde et pas seulement les aveugles. L’accessibilité permet notamment de répondre à des incapacités temporaires tel que le reflet du soleil sur l’écran de votre smartphone ou une blessure qui vous forcerait à naviguer au clavier.

La direction interministérielle du numérique (la DINUM, anciennement DISIC) défini l’accessibilité comme étant l’ensemble des technologies visant à améliorer la perceptibilité, l’utilisabilité, la simplicité de compréhension et la robustesse. Il y a donc plus à faire qu’ajouter des “alt” aux images.

Maintenant que c’est dit, partons ensemble pour le monde merveilleux (ou presque) de l’accessibilité !

Navigation au clavier

Pour qu’un site soit accessible, il doit être utilisable entièrement au clavier. La navigation se fait habituellement à l’aide de la touche de tabulation. La navigation doit être cohérente et tous les éléments interactifs doivent pouvoir être utilisables au clavier.

Affichage du focus

Cela peut sembler bête mais l’un des points les plus importants pour un utilisateur navigant au clavier est de savoir où il se trouve. Assez souvent, les designers aiment bien demander de supprimer ce petit contour disgracieux autour de l’élément en focus. Ne les écoutez pas, ils ont tort. S’ils reviennent à la charge en vous demandant de changer la couleur du focus, riez leur au nez. Il est préférable de laisser le focus natif afin de garder une cohérence avec les autres sites web et de permettre à l’utilisateur de savoir directement ce qui est en focus.

Buzz l’Éclair : “Du focus… du focus partout !”

Liens d’évitement

À chaque changement de page, le navigateur repositionne le focus avant le premier élément de la page. L’utilisateur navigant au clavier devra donc reparcourir tous les en-têtes avant d’arriver au texte qu’il veut lire.

Pour rendre la navigation plus agréable, il faut donc proposer à l’utilisateur des liens en début de page permettant de mettre directement en focus le contenu.

Si votre ami designer ne supporte pas de devoir ajouter un lien “contenu” avant son magnifique logo, rassurez-le : vous pouvez masquer les liens d’évitement et ne les afficher que lorsqu’ils sont en focus.

Affichage et escamotage du lien d’évitement permettant d’aller au contenu.

Chantal Lauby dans Astérix Mission Cléopâtre : “On m’voit, on me voit plus. On me voit plus, on m’voit.”

Utilisation des design pattern d’accessibilité

Comme il existe une multitude de façons d’implémenter un même composant (barre de menu, arbre, tableau de données, pop-in, carrousel, etc.), le W3C a défini des règles pour certains composants usuels. C’est très complet et ça se consulte par ici :

WAI-ARIA Authoring Practices 1.1

La DINUM propose même sa petite bibliothèque de composants respectant les normes du W3C :

Bibliothèque de référence – Composant ARIA

Boutons et liens

Lorsque vous utilisez l’événement javascript “onclick”, faites en sorte que cela soit sur une balise <button type=”button”>. Il est attendu d’une zone cliquable qu’on puisse y accéder avec tabulation, qu’elle soit activable avec entrée ou espace et qu’elle ait le rôle “button”. Ce comportement vous est offert si vous utilisez un bouton.

La validation d’un formulaire doit se faire via une balise <button type=”submit”>. Pour ajouter un comportement javascript à la validation d’un formulaire, utilisez l’événement “onsubmit” de la balise “form”.

Tous les changements de page au clic sur un élément (sauf si provoqué par la validation d’un formulaire) doivent être sur des liens hypertextes (balise “a”). Si le designer vous demande de mettre un bouton, utilisez du CSS pour que le lien s’affiche comme un bouton.

Lecture du site

Votre site doit pouvoir être lu par un lecteur d’écran. Les lecteurs d’écran populaires sont JAWS et NVDA sous Windows et VoiceOver sous macOS et iOS.

Les lecteurs d’écran sont accompagnés de raccourcis permettant de naviguer sur le site via ses points d’intérêt. Le code HTML du site doit donc être propre pour être compris par le lecteur d’écran. Il doit aussi avoir un sens (via les rôles Aria ou via les balises sémantiques HTML5) pour que le lecteur d’écran puisse restituer correctement ce qui est affiché.

Donner du sens au HTML

Pour que votre code HTML ai du sens, vous avez deux options :

• Utiliser les balises de titres (“h1”, “h2”, etc.), les paragraphes (“p”) et les balises sémantiques HTML 5 (“header”, “main”, “nav”, “footer”, etc.).
• Enrichir vos balises avec des attributs Aria.

Concernant l’ARIA, le W3C rappelle que “pas d’ARIA est mieux que du mauvais ARIA”. Donc si vous avez un doute sur l’utilisation d’une propriété ARIA, préférez ne rien mettre.

Décrire les tableaux

Chacun de vos tableaux doit être accompagné d’une description. Cela peut passer par la balise “caption” ou par les attributs “aria-label” ou “aria-labelledby”.

Cette description sera lue par le lecteur d’écran et permettra à l’utilisateur de décider s’il veut lire le contenu du tableau ou passer au reste de la page.

Lier les champs de saisie avec leurs libellés

Idéalement, chaque champ de saisie doit avoir un libellé visible. Il peut s’agir d’un texte dans une balise “label” (lié avec l’attribut “for” ou en positionnant le champ dans la balise “label”) ou d’un autre élément lié grâce à la propriété “aria-labelledby”.

En dernier recours, vous pouvez utiliser l’attribut “aria-label” directement sur votre champ de saisie.

Évitez de mettre des informations importantes dans l’attribut “placeholder”. Il n’est pas lu par les lecteurs d’écran et ne s’affiche que lorsque le champ est vide. Préférez l’utilisation d’un paragraphe et liez le au champ de saisie à l’aide de l’attribut “aria-describedby” sur la balise du champ.

Vous devez aussi utiliser “aria-describedby” pour lier un message d’erreur de validation à un champ de saisie.

Alternatives textuelles

Quand vous ajoutez un élément visuel important (image, icône ou vidéo), vous devez l’accompagner d’une alternative textuelle pour permettre aux utilisateurs de lecteur d’écran de comprendre ce qu’il se passe.

Cette règle est plutôt connue mais elle n’est pas vraiment simple. Pour les vidéos ça passe, vous pouvez les accompagner d’un résumé ou d’une transcription des dialogues et le tour est joué. Pour les images, faut-il mettre des “alt” sur toutes les images ? Que faut-il écrire comme alternative ?

Quand une image est purement décorative, il vaut mieux renseigner un alt vide pour l’ignorer. Mais si l’image apporte un sens ou du contexte, il faut essayer de décrire du mieux possible ce qu’elle affiche.

Boromir dans le Seigneur des Anneaux : “On n’écrit pas si facilement de bonnes alternatives textuelles.”

Le site suivant fait un bon boulot pour expliquer comment bien décrire ses images :

Alt Text for Images – Examples & 2021 Best Practices

Pour les icônes, vous devrez ajouter une alternative s’ils sont seuls. Quand ils sont accompagnés d’un texte, utilisez une alternative vide ou l’attribut aria-hidden=”true” pour qu‘ils soient ignorés.

Surprise ! N’oubliez pas que vos PDF doivent aussi être accessible. Microsoft fait un meilleur boulot qu’Adobe en ce qui concerne l’accessibilité et un document Word sera en général plus simple à lire pour un lecteur d’écran qu’un document PDF. Proposez donc plusieurs formats au téléchargement pour permettre aux utilisateurs de comprendre vos pièces-jointes.

Terminer ses phrases

Vous vous en doutez mais mettre un point à la fin d’une phrase va demander au lecteur d’écran de marquer un temps d’arrêt avant de passer au texte suivant. Cela rend plus clair et plus agréable à écouter votre site. Il s’agit d’une règle simple mais qui est souvent oubliée (dans les messages d’alerte par exemple).

L’homme le plus intéressant du monde : “Je ne fini pas souvent mes phrases, mais quand je le fais, je”

Couleurs et contraste

Le même formulaire vu sans problème de vision, vu par un daltonien et vu avec un manque de contraste. Le choix des couleurs est important pour l’accessibilité. Il faut éviter de faire passer des informations seulement par la couleur.

Les utilisateurs peuvent avoir des anomalies de vision des couleurs (daltonisme par exemple) ou simplement ne pas pouvoir distinguer les couleurs lorsque le contraste est trop faible (ensoleillement ou autre).

Là aussi, vous devrez donc peut-être jouer des coudes avec votre ami designer (ou avec votre client) pour lui expliquer que du texte gris foncé sur gris clair n’est pas une bonne idée.

L’onglet accessibilité de l’inspecteur de Firefox indique le niveau de contraste et vous permet d’identifier rapidement quels éléments ne sont pas assez visible .

Permettre à l’utilisateur de prendre son temps

Là c’est simple, n’utilisez pas de timers pour afficher/masquer des éléments. Évitez par exemple les notifications de type “toast” qui s’effacent toutes seules pour indiquer le résultat d’une action. Préférez l’ajout d’un bouton permettant d’effacer le message manuellement. Ainsi l’utilisateur aura tout le temps qu’il souhaite pour lire et/ou pour comprendre votre message.

Pour aller plus loin

C’est déjà fini. Il reste évidemment des montagnes de choses à voir mais j’espère que cet article vous aura permis de découvrir des points importants pour rendre vos sites plus accessibles.

Pour creuser, le site WebAIM est assez proche de la bible en ce qui concerne l’accessibilité :

WebAIM: Web Accessibility In Mind

La DINUM propose un guide de l’intégrateur qui présente en détail comment bien construire la structure de son site, les images, les tableaux, les liens et plein d’autres choses :

DISIC/guide-integrateur