Web : une accessibilité accessible
Normes et outils
Dans la société d’aujourd’hui, les infrastructures ne sont pas toujours adaptées à toutes les personnes. Face à des escaliers, quand certains verront un petit peu d’exercice, d’autre seront face à un équipement inadapté bien plus difficile à surmonter. Face à cela, nous pouvons installer un ascenseur ou une rampe pour que cette personne puisse continuer sa route.
Sur le web, c’est le même combat. Il y a des choses qui semblent naturelles pour les uns et qui ne seront pas adaptées pour d’autres. A nous de mettre en place les outils et les bonnes pratiques pour accompagner l’ensemble de nos utilisateurs et ne laisser personne en bas des escaliers.
L’accessibilité appliquée au web
L’accessibilité est un terme très générique qui, dans son sens premier, définit la capacité d’accès d’une chose, d’un lieu. Dans son sens civil, il désigne plus particulièrement la facilité d’accès à des personnes en situation de handicap. Le but est avant tout de leur permettre de tendre au maximum vers une vie ordinaire. Quand on parle accessibilité, la première image que nous avons est celle du fauteuil roulant et des escaliers, mais il existe un très grand nombre d’autres situations.
Dans le contexte d’un site internet, nous allons avoir également un grand nombre de situations à prendre en compte. Concernant les handicaps nous allons retrouver principalement :
- Le handicap visuel : On pense de suite à la cécité totale, mais il y a également les troubles de la vision plus ou moins sévères ou encore le daltonisme.
- Le handicap auditif : il existe également une graduation de troubles de l’audition.
- Le handicap moteur : il peut avoir un nombre très élevés de formes, et va se traduire par une difficulté, voire une incapacité, à utiliser un périphérique d’entrée tel que la souris ou le clavier.
- Le handicap cognitif : cette catégorie est très vaste mais souvent réduite à trois catégories : les problèmes de concentration, de mémoire et de compréhension (visuelle, linguistique ou mathématique).
L’accessibilité pour tous
Travailler l’accessibilité, c’est avant tout penser aux personnes handicapées. Mais c’est également faciliter l’utilisation de l’outil au plus grand nombre.
Les panneaux de signalisation seraient par exemple moins faciles à lire sans un contraste élevé, un positionnement correct et une police d’écriture simple et grande. On a tous regardé des vidéos avec les sous-titres quand nous ne voulions pas du son, pris la rampe avec une valise ou une poussette, suivi les indications sonores pour savoir quand traverser la rue. Il y a beaucoup d’exemples similaires dans la vie courante.
Il en va de même pour les sites internet. Les nombreuses pratiques à mettre en place vont, en plus de rendre les sites accessibles, simplifier et normaliser nos outils. Un grand nombre des pratiques d’accessibilité font partie des bonnes pratiques générales de bon nombre de sites.
En France : la loi accessibilité numérique
La loi française, à travers le décret du 24 juillet 2019, impose à toutes les entreprises publiques, privées ayant une mission de service public ou privée ayant un chiffre d’affaire de plus de 250 millions d’euros à se mettre en conformité avec les règles d’accessibilité.
Les entreprises concernées doivent se mettre en conformité :
Pour les entreprises faisant plus de 250 millions d’euros de chiffre d’affaires :
🗓 Le 1er octobre 2019 pour les sites internet, intranet et extranet créés à compter de cette même date ;
🗓 Le 1er octobre 2020 pour les sites internet, intranet et extranet créés avant le 1er octobre 2019 ;
🗓 Le 1er juillet 2021 pour les applications mobiles, les progiciels et le mobilier urbain numérique.
Pour les autres entités concernées par la loi accessibilité numérique :
🗓 Le 23 septembre 2019 pour les sites internet, intranet et extranet créés depuis le 23 septembre 2018 ;
🗓 Le 23 septembre 2020 pour les sites internet, intranet et extranet créés avant le 23 septembre 2018 ;
🗓 Le 23 juin 2021 pour les applications mobiles, les progiciels et le mobilier urbain numérique.
Les amendes peuvent aller de 5 000€ à 20 000€.
Les Normes/Standards
Le World Wide Web Consortium (W3C) est depuis plus de 25 ans la fabrique à standards du web. Depuis leur création on compte parmi leurs nombreux projets des noms tels que l’HTML, le CSS, le XML, le SOAP, etc.
Lancée en 1997, le Web Accessibility Initiative (WAI) a pour mission principale de développer des solutions techniques afin d’améliorer l’accessibilité du web. Dans cette démarche ils ont développé tout un ensemble d’outils et de recommandations.
Parmi celles-ci nous allons nous intéresser de plus près à deux d’entres elles :
- les WCAG (Web Content Accessibility Guidelines)
- La solution ARIA (Accessible Rich Internet Applications)
Les Web Content Accessibility Guidelines (WCAG)
Afin de réunir l’ensemble des règles et de recommandations, le W3C maintient un ensemble de guidelines nommées les WCAG. Dans leur première version, les WCAG se concentraient sur le contenu HTML avec 14 directives dont les points de validations se basent surtout sur les technologies HTML et XML.
Dans leurs versions 2.0 et 2.1, qui sont les guidelines d’aujourd’hui, ces directives font abstraction de la technologie et se basent principalement sur l’expérience utilisateur.
Ces versions contiennent 12 règles réparties en 4 principes. Chacune des règles sera découpée ensuite en critères de différents niveaux, de A pour une accessibilité de premier ordre à AAA pour une accessibilité totale.
Les WCAG 2.1 viennent simplement compléter cet ensemble de critères et renforcer la stratégie d’accessibilité Web
1 Perceptible : L’information et les composants de l’interface utilisateur doivent être présentés à l’utilisateur de façon à ce qu’il puisse les percevoir.
- Équivalent textuel : proposer des équivalents textuels à des contenus qui en sont dépourvus (images, vidéo, illustrations)
- Média temporel : proposer des versions de remplacement aux médias temporels (piste vidéo, son, flux) tels que des sous-titres ou une descriptions audio.
- Adaptable : créer un contenu qui puisse être présenté de différentes manières sans perte d’information ni de structure (affichage simplifié, conservation de l’ordre du contenu)
- Distinguable : faciliter la perception visuelle et auditive du contenu par l’utilisateur (Contraste, taille et choix de police, contrôle du son)
2 Utilisable : Les composants de l’interface utilisateur et de navigation doivent être utilisables.
- Accessibilité au clavier : rendre toutes les fonctionnalités accessibles au clavier.
- Délais suffisant : laisser assez de temps à l’utilisateur pour lire et utiliser le contenu (en permettant une pause ou une suppression de limite de temps)
- Crises : ne pas concevoir de contenu susceptible de provoquer des crises. Des flashs répétés peuvent provoquer des crises chez les personnes photosensibles.
- Navigable : fournir à l’utilisateur des éléments d’orientation pour naviguer, trouver le contenu et se situer dans le site.
3 Compréhensible : Les informations et l’utilisation de l’interface utilisateur doivent être compréhensibles.
- Lisible : le contenu textuel doit être lisible et compréhensible. On peut par exemple ajouter des définitions, la signification des abréviations ou encore la prononciations de certains mots afin d’aider à la lecture.
- Prévisible : les pages doivent apparaître et fonctionner de manière prévisible. (Changement de focus, navigation, saisie, etc)
- Assistance à la saisie : aider l’utilisateur à éviter et à corriger les erreurs de saisie (suggestion, prévention, identification des erreurs)
4 Robuste : Le contenu doit être suffisamment robuste pour être interprété de manière fiable par une large variété d’agents utilisateurs, y compris les technologies d’assistance.
- Compatible : optimiser la compatibilité avec les agents utilisateurs actuels et futurs, y compris les technologies d’assistance. (respect de la syntaxe, de la sémantique, utilisation d’API d’accessibilité)
Retrouvez en détail l’ensembles de règles avec leurs critères ici :
Cette dernière règle est une transition parfaite, car c’est a peu près l’unique règle qui concerne le code HTML où nous allons optimiser l’accessibilité.
Dans ce domaine nous pouvons travailler sur deux aspects :
- Respect de la sémantique
- Utilisation de l’API d’accessibilité ARIA.
Respect de la sémantique
Avant d’utiliser quoi que ce soit en terme d’API, la première règle est d’utiliser et respecter scrupuleusement la sémantique HTML. Car la majorité des outils de lecture d’écran, d’aide à la saisie ou encore d’adaptation vont venir s’appuyer sur cette sémantique.
Mais qu’est ce que la sémantique ?
La sémantique HTML est l’organisation et la hiérarchie de la page. Elle va permettre d’en décrire précisément le contenu. Pour l’accessibilité, Il s’agit de respecter des bonnes pratiques d’usage, c’est à dire simplement d’utiliser les bons composants au bon endroit.
Voici quelques bonnes pratiques :
- ✅ Structurer sa page à l’aide des éléments tels que header, nav, main ou footer. On évitera par exemple de structurer sa page avec une grosse table.
- ✅ Hiérarchiser ses titres et respecter l’ordre croissant (exemple : h1, h2, h3, h4, h2, h3, h2, h3, h4…). Depuis HTML5 on peut avoir plusieurs h1 dans la page.
- ✅ Utiliser les éléments appropriés. Une des erreurs les plus courantes est par exemple d’utiliser un lien à la place d’un bouton pour éviter de devoir trop surcharger la CSS.
- ✅ Associer un label à chaque champ d’un formulaire
- ✅ Utiliser des entêtes (th) pour les tableaux
- ✅ Utiliser strong et em à la place de b et i pour mettre en gras ou italique afin d’appuyer le propos.
Et quelques mauvaises pratiques :
- 🚫 Ajouter des comportements uniquement en Javascript. Ces derniers ne seront pas interprétés par les outils. Le javascript doit améliorer l’expérience, pas la créer de 0.
- 🚫 Utiliser les balises div et span pour autre chose que de la structuration de page.
- 🚫 Utiliser la sémantique (section ou article par exemple) pour organiser le style CSS
- 🚫 Utiliser des br (sauf dans des rares cas)
Voilà un peu à quoi nous pouvons nous attendre sur une page simple :
Voici les tutoriels complets du W3C sur la sémantique HTML5 :
ARIA Accessible Rich Internet Applications
Une fois toutes ces règles respectées, et pas avant, nous pouvons pousser un peu plus loin notre accessibilité. Sur les widgets, les composants et lorsque que le HTML natif ne suffit plus nous allons devoir utiliser un outil externe : la suite ARIA.
Je vous propose de faire un tour d’horizon de l’API. Vous pourrez retrouver les spécifications précises à travers les liens.
Les 5 commandements
Avant d’utiliser cette spécification, il convient de connaitre et apprendre les 5 règles à scrupuleusement respecter. Elles ne sont pas que des bonnes pratiques, elles sont notées et développées noir sur blanc dans les spécifications.
- Tu n’utiliseras pas ARIA quand la sémantique HTML pourra être utilisée
- Tu ne changeras la sémantique native que si aucun autre choix n’est possible
- Tu créeras des contrôles interactifs ARIA qui seront accessibles au clavier
- Tu n’utiliseras pas
role="presentation"ouaria-hidden="true"sur un élément focusable visible. - Tu donneras à tous les éléments interactifs un nom accessible
Une fois ces règles apprise nous pouvons passer aux choses sérieuses. Aria propose un ensemble d’outils qu’on peut classer en 3 catégories : les rôles, les états et les attributs.
Pour illustrer la suite nous allons prendre un exemple concret : l’accordéon
L’accordéon est un ensemble de panneaux qui s’ouvrent ou se ferment pour afficher le contenu. Dans notre exemple nous allons prendre un accordéon qui permet d’ouvrir plusieurs panneaux en même temps.
Basiquement le code d’un tel composant pourrait être le suivant :
Pour plus de lisibilité nous allons retirer les classes CSS et n’afficher que les ajouts que nous allons faire.
Les rôles
Un rôle, au sens ARIA, va être posé sur un élément à l’aide de l’attribut role afin d’aider à représenter le fonctionnement des composants. Cette liste assez complète et qui est régie par un ensemble de règles permet de définir un rôle sémantique sur des composants complexes.
Un rôle peut s’appliquer sur une liste bien précise d’éléments, et inversement chaque élément pourra recevoir qu’un certain nombre précis de rôles. Par exemple :
<button role=”heading”>search</button>Ne sera pas permis, un bouton n’as pas les caractéristiques d’un header. Par contre :
<div role="alert">
<p> Le site sera en maintenance dans les prochains jours </p></div>Est bien plus pertinent, il vient ajouter une sémantique sur ce message d’alerte que ne peut fournir HTML5 nativement.
Dans notre exemple, nous avons plusieurs rôles que nous pouvons définir. Le premier est celui de l’ensemble que nous pouvons définir comme tablist qui représente la liste des panneaux. Ensuite chaque panneau aura le rôle de tab . Chaque panneau pourra ensuite mettre en avant son contenu avec le rôle tabpannel .
Nous pouvons appliquer également la bonne pratique qui est de mettre un bouton sur le titre pour qu’il soit accessible par la tabulation et reconnu comme effectuant une action.
Cela donne donc :
Pour plus de détails, voici la liste complète des rôles ainsi que leurs caractéristiques.
Les attributs
Les attributs vont venir compléter les rôles et définir souvent les relations entre les éléments. La plupart du temps ils sont statiques. L’un des plus répandu est l’attribut aria-labelledby qui permet de déclarer que le champs de saisie par exemple possède un libellé qui est dans un autre champs.
Nous allons également pouvoir appliquer l’attribut aria-controls au bouton pour indiquer que celui-ci contrôle le panneau. Il suffira simplement d’indiquer l’identifiant de ce dernier pour lier les deux.
Enfin, sur le tablist, nous pouvons lui indiquer que plusieurs panneaux peuvent s’ouvrir simultanément à l’aide de aria-multiselectable .
Appliquons cela à notre exemple :
Les états
Jusqu’ici nous avons vu les différentes façons d’être accessible de façon statique. Sans vraiment trop d’effort, en respectant simplement la sémantique et en ajoutant des rôles et des attributs à nos composants. Cependant il y a des cas où nous avons besoin d’encore un peu plus d’information, et ce, de manière dynamique.
Prenons notre exemple de l’accordéon. Si on regarde de plus près le code, nous nous apercevons que les 3 panneaux sont affichés sans aucune distinction les uns des autres. Afin de permettre de savoir quel onglet est ouvert, chaque onglet va posséder un état aria-expanded qui permettra de transmettre si le groupe est ouvert ou fermé. Les autres quant à eux devront être cachés aux outils d’assistance. Pour cela nous allons utiliser l’état aria-hidden .
Ces états ne sont par contre plus statiques. En fonction du panneau à afficher nous devrons les modifier en javascript. A l’appel d’un bouton on ouvre le panneau, puis on passe les états ARIA au statut ouvert/fermé et affiché/caché.
Je ne ferai pas l’affront de mettre ce code JS ici. En fonction de la technologie utilisée, il sera facile de faire ça.
Les outils du développeur
Après ce petit tour de piste, je vais quand même vous donner quelques outils pratiques.
La première chose à faire quand on veut vérifier, c’est de scanner l’existant. Pour ça il existe des sites qui scannent votre site (public du coup) et génèrent des rapports.
WAVE (Web Accessibility Evaluation Tool) est un des plus répandus. Il propose un site pour scanner n’importe quel site web, mais également un plugin Chrome.
Ces outils ne permettront de trouver qu’une certaine partie des erreurs.
Vous pouvez aussi installer dans votre éditeur des extensions comme Web Accessibility pour VS Code :
Ce dernier vous donnera des informations sur les problèmes d’accessibilité sur votre code.
Vous pouvez sinon directement ajouter dans eslint les règles d’accessibilité, pour valider les bonnes pratiques.
L’accessibilité à portée de main
Comme vous avez pu le constater, l’accessibilité est au final accessible à tous. Une fois que nous nous sommes intéressés au sujet et que nous avons ouvert les quelques petites portes, le sujet n’est pas si sorcier.
Lors de l’écriture de cet article j’ai énormément lu . Le code deviendra un peu plus verbeux, et un peu de javascript sera nécessaire, cependant ce travail pourra se faire au fil de l’eau sans nécessiter de refonte en profondeur.
⁉️ Si vous avez apprécié, si vous avez des précisions, des compléments, ou si j’ai dit des bêtises, n’hésitez surtout pas à réagir, contribuer, partager et à applaudir l’article.
Merci 🍻 🎉
