Alors qu’aujourd’hui une grande majorité des services passent par le numérique, de nombreux sites restent inaccessibles aux personnes en situation de handicap.
En France, les sites fournissant un service public sont maintenant tenus de respecter les critères du RGAA (Référentiel général d’amélioration de l’accessibilité), référentiel s’appuyant sur les normes internationales de l’accessibilité numérique, aussi appelé WCAG. De ce référentiel, trois niveaux de conformité ont été identifiés : A, AA et AAA. Le AAA (triple A) étant le plus élevé. L’objectif ? Rendre ces « contenus et services numériques utilisables et compréhensible à toutes et à tous » (https://accessibilite.numerique.gouv.fr/).
Les actions pouvant être mises en place sont nombreuses. Que ça soit au niveau du code, comme rendre compréhensible son site internet par un lecteur d’écran pour les personnes atteintes de troubles visuels, permettre la navigation clavier, etc. Mais aussi au niveau du design, comme augmenter les zones cliquables pour les personnes ayant un handicap moteur, choisir des couleurs contrastées, une taille de police suffisamment grande.
Qu’est-ce que les attributs ARIA ?
Accessible Rich Internet Applications est un ensemble d’attributs et de rôles HTML visant à rendre le contenu et les applications web accessibles. Il est important de comprendre que l’ARIA complète le HTML mais n’a pas pour but de le remplacer. Voyez ça plus comme la dernière alternative pour que votre site soit accessible. Si vous avez la possibilité d’utiliser des éléments natifs privilégiez-les car ils disposent de fonctionnalités de base comme la navigation clavier, les différents états (focus, pressed, etc) qui sont déjà accessibles. Dans le cas où vous souhaitez « recréer » un élément natif, par exemple un bouton à partir de div, vous devrez recoder toutes ses fonctionnalités et introduire les attributs ARIA nécessaires.
Voyons maintenant quelques exemples d’attributs.
Les rôles
Plus de 80 rôles existent, ceux-ci vont permettre de signifier la fonction de l’élément au navigateur. Le lecteur d’écran pourra ensuite en informer l’utilisateur.
Prenons un exemple simple, le bouton.
<button type="button" id="saveChanges">Save</button>
Si vous souhaitez réécrire ce dernier sans utiliser la balise <button>, vous pouvez utiliser le rôle défini à cet usage :
<div role="button" tabindex="0" id="saveChanges">Save</div>
Ici le role=«button» donne l’information qu’il s’agit d’un bouton, il remplace une balise <button> ou <input type=«button»>. Reste au développeur d’ajouter toutes les fonctionnalité d’un bouton, c’est-à-dire le rendre sélectionnable au clavier (avec tabindex=«0») mais aussi la gestion des évènements au clic et au clavier.
Si vous souhaitez vous renseigner sur comment coder des composants accessibles, vous pouvez vous référer au site W3C qui explique les bonnes pratiques en ARIA ainsi que des exemples de patterns accessibles.
Les labels
Un autre attribut ARIA couramment utilisé est le « aria-label ». Il permet de configurer du texte qui sera lu uniquement par les lecteurs d’écrans.
Dans l’exemple ci-dessous, le texte affiché aux utilisateurs «L’accessibilité numérique, et si nous agissions», est séparé en deux «span», très probablement pour des raisons de design, et, au clic, permet de rediriger vers la page d’accueil.
Ici, l’usage du aria-label sur l’élément parent, va permettre au lecteur d’écran d’énoncer le texte renseigné avec la précision pour les malvoyants de l’action associée : « aller à la page d’accueil ». Notez que le lecteur d’écran ne lira pas ce qui est à l’intérieur des éléments enfants du aria-label, ainsi il n’y aura pas de répétition avec les deux spans enfants.
Un second exemple serait un bouton contenant uniquement une icône. Par exemple les boutons d’édition représentés uniquement par un crayon.
De même, ici on souhaite énoncer à l’utilisateur l’action permise par le bouton en question. Grâce à l’utilisation du aria-label, un lecteur d’écran lira donc « Edit preferences – button ».
<button type="submit" aria-label="edit preferences"> <svg aria-hidden=true focusable="false"><!-- svg content --></svg> </button>
Alternative textuelle – images
Déjà employé pour le référencement, il est préférable d’utiliser l’attribut alt pour les éléments HTML <img>, plus adapté que le aria-label plutôt utilisé pour des éléments contenant déjà du texte. Comme indiqué dans son nom, l’attribut alt apporte une alternative textuelle.
Cet attribut s’utilise directement sur la balise <img> :
<img src="chat.png" alt="Chat très mignon qui dort sur sa couette"/>
De la même manière que le aria-label, ce alt sera lu par les lecteurs d’écrans. Si l’image est porteuse d’information, il est important de renseigner cet attribut pour que l’utilisateur ait le même niveau de connaissance qu’une personne voyante.
Au contraire, si l’image est purement décorative, l’attribut alt doit être présent mais laissé vide. Cela indiquera au lecteur d’écran qu’il ne doit pas la lire.
Par exemple, sur https://accessibilite.numerique.gouv.fr/, une image avec des formes géométriques est utilisée pour illustrer la page d’accueil.
Cette image n’apportant aucune information pertinente, elle sera ignorée par le lecteur d’écran en lui renseignant l’attribut alt vide.
<img src="rgaa.svg" alt=""/>
Aria-hidden
Si l’on souhaite rendre l’information la plus accessible possible, on peut parfois souhaiter ne pas rendre tout visible. L’attribut aria-hidden permet de cacher du contenu non interactif aux outils d’accessibilité. Cela peut améliorer l’expérience utilisateur en cachant les contenus purement décoratifs, des contenus collapsés comme des menus (on n’a pas envie que les technologies d’assistance lisent des options non affichées) ou éviter la répétition de texte.
Reprenons l’exemple de la page précédente. Ici, une icône d’œil barré est représentée pour illustrée la partie Cécité. Cette icône a un but purement décoratif et n’entraîne aucune action. Elle n’est donc pas porteuse d’information et ne nécessite pas d’être énoncée par les lecteurs d’écrans.
On pourra donc utiliser l’attribut « aria-hidden » :
<svg class="handicap-blindness" aria-hidden="true"></svg>
Aria-current, aria-expanded, …
Une multitude d’attribut aria existent, chacun répondant à un besoin. Je vous laisserai les découvrir ici.
Quel est l’intérêt de la hiérarchie des titres ?
Vous connaissez sûrement les balises <h1>, <h2>, etc. Elles permettent de structurer le contenu d’une page web en instaurant une hiérarchisation. Cette dernière peut être utilisée par les malvoyants pour se déplacer plus facilement dans une page web. En effet, certains lecteurs d’écrans utilisent des raccourcis clavier pour permettre la navigation par les titres. Ainsi les utilisateurs peuvent savoir rapidement où ils se situent et retrouver l’information sans avoir à parcourir tout le document.
Si vous souhaitez auditer votre site et vérifier la bonne hiérarchisation de vos titres, vous pouvez utiliser HeadingsMap, une extension disponible sous Chrome et Firefox (lien vers l’addon mozilla).
Côté code, plusieurs façons de définir un titre existent :
<h1>Je suis un titre de niveau 1.</h1> <h2>Je suis un titre de niveau 2.</h2>
Avec aria – utilisation des attributs role et aria-level :
<span role="heading" aria-level="1">Titre de niveau 1</span> <span role="heading" aria-level="2">Titre de niveau 2</span>
Dans le premier cas, un style est appliqué avec l’utilisation des balises heading <h1>, dans le second cas le style du span sera utilisé mais il sera perçu comme un titre de niveau 1 par les lecteurs d’écrans.
Comment faire si on n’utilise pas d’outils de pointage ?
Comme vu auparavant, certaines personnes ne peuvent utiliser ni souris, ni outils de pointage. D’autres ont simplement pris l’habitude de se déplacer en utilisant la navigation clavier. Dans tous les cas, il est important de rendre les composants interactifs utilisables au clavier si on décide de les redévelopper en utilisant l’ARIA.
Ainsi, tous les composants d’interface nécessitant une interaction au clavier, comme le role button, tabpanel, dialog, menu (Guide du développeur RGAA 3), devront avoir leur gestion au clavier redéveloppée suivant les motifs de conceptions définis. Certains sites comme https://www.w3.org/WAI/ARIA/apg/patterns/ fournissent des listes de « Keyboard Interaction » expliquant quelles sont les interactions claviers attendues, ainsi que les réactions à ces dernières, les activations, le déplacement du focus etc.
Quels designs privilégier ?
On ne parle que de développement pour l’instant, mais une grande importance est à accorder au design pour les voyants ayant d’autres pathologies.
Par exemple, les personnes atteintes de tremblements auront plus de difficultés à cliquer sur des zones réduites. Une taille minimale de 44 par 44px est donc à respecter pour les éléments cliquables si vous souhaitez le niveau le plus élevé d’accessibilité (je vous laisserai voir les cas d’exceptions ici : https://www.w3.org/Translations/WCAG21-fr/#target-size).
D’autres encore peuvent avoir des troubles de l’attention et être facilement déconcentrés ou tout simplement avoir besoin de plus de temps pour lire l’information. Afin de ne pas les perdre dans des effets visuels, les animations ou carrousels sont à éviter. Si vous voulez vraiment les utiliser, donnez-leur la possibilité de mettre en pause ce dernier.
Dans l’ensemble, respectez le fait qu’une transition doit rester au minimum 5 secondes avant d’afficher une nouvelle information (si vous souhaitez en savoir plus sur les règles de construction d’un carrousel accessible, vous pouvez vous référez sur le site du w3c ici).
Le contraste des couleurs est lui aussi réglementé. L’accessibilité d’une couleur se calcule par rapport à son contraste avec son arrière-plan, sont pris notamment en compte la taille du texte et sa graisse. Plusieurs extensions ou sites sont disponibles pour vérifier de l’accessibilité d’une couleur : l’extension WCAG Contrast Checker, le site color.review.
D’autres éléments sont notamment importants comme l’espacement de texte afin d’améliorer la lisibilité. Je vous mets un extrait de la règle ci-dessous, que vous pouvez retrouver dans les recommandations W3C.
- line-height → 1,5 fois la taille de police
- letter-spacing → 0,12 fois la taille de la police
- word-spacing → 0,16 fois la taille de la police
- margin-bottom de paragraphe → 2 fois la taille de police
Conclusion
« Better not to use ARIA than to use it incorrectly », c’est un peu la règle d’or que l’on retrouve dans de nombreux articles sur l’accessibilité. Une étude conduite en 2023 montre que sur 1 million de pages d’accueil, 74.6% utilisaient les attributs ARIA et ces dernières présentaient 34.2% d’erreurs d’accessibilité de plus que celles n’en utilisant pas (source : https://webaim.org/projects/million/#aria). Cela ne signifie pas qu’utiliser ces derniers est une mauvaise chose mais simplement que ces homes pages devaient être assez complexes, entraînant l’utilisation de composants non natifs et les fonctionnalités d’accessibilité n’ont pas toutes été reconstruites. Les bonnes pratiques pour l’accessibilité restent encore assez méconnues, les bons exemples d’implémentation sont rares, ce qui rend plus compliqué leur bonne utilisation. A vous de voir en fonction de votre besoin et de vos connaissances, s’il n’est pas préférable parfois de rester sur des designs plus simples mais accessibles. Dans tous les cas, de nombreux outils sont à votre disposition pour vous permettre de construire vos écrans.
Et n’oubliez pas, l’accessibilité contribue à toutes et à tous, et améliore l’expérience pour l’ensemble des utilisateurs 🙂
Liens
Pour en savoir plus :
- le site du gouvernement : https://accessibilite.numerique.gouv.fr/
- les règles pour l’accessibilité des contenus Web : https://www.w3.org/Translations/WCAG21-fr/#abstract
Pour mieux comprendre les handicaps : https://www.atalan.fr/agissons/fr/index.html
Les extensions abordées dans l’article :
- Assistant RGAA : regroupement de la documentation RGAA, permet de tester chaque critère
- WAVE : analyse la page ouverte et montre les erreurs ou warnings des défauts d’accessibilité
- HeadingsMap : affiche l’arborescence des titres de la page
- Web Developer Toolbar : permet entre autre de disable le css afin de vérifier que les informations pertinentes sont toujours présentes
- Stylus : permet entre autres de voir le focus
- WCAG Contrast Checker : permet de vérifier le ratio des couleurs de texte/background afin de s’assurer d’un bon contraste
Un second article viendra pour présenter plus en détails les différentes extensions.