J’aime bien découvrir tout ce qui gravite autour du développement web, et ne pas me contenter de ne voir que par le prisme du CSS et du Javascript. Il est un sujet que je trouve important de parler, notamment en France (vous allez comprendre pourquoi) : l’accessibilité.
L’inclusivité, une obligation légale
L’accessibilité web est très importante aux US/UK pour plusieurs raisons légales, sociales et commerciales. Contrairement à d’autres pays, où elle est parfois considérée comme un “nice-to-have”. Dans les pays anglo-saxons, c’est une obligation pour des questions de conformité réglementaire et d’inclusivité.
Aux Etats-Unis, cela prend la forme de l’ADA (Americans with Disabilities Act) signée en 1990 à l’origine pour des adaptations aux handicaps physiques dans les lieux publics. Depuis les années 2000, des décisions de justice ont considéré que le web était un lieu public et donc soumis aux règles d’accessibilité.
Mais ce n’est qu’à partir de 2017 que les premiers procès marquants contre Netflix ou Domino’s Pizza voient le jour et accordent beaucoup plus de crédit à cette réglementation. Pour la petite histoire, une fan aveugle porte plainte contre Beyoncé en 2019 car le site de la chanteuse n’était pas utilisable avec des lecteurs d’écran.
Depuis, toute entreprise à visée commerciale dans le numérique ou même un site d’une célébrité est dans l’obligation légale de rendre son site accessible, sous peine de poursuites judiciaires.
Au Royaume-Uni, il existe un équivalent à cette loi : Equality Act.
En France, bien qu’il n’y ait pas d’obligation pour les sites populaires, il est toutefois fortement recommandé de s’intéresser à l’accessibilité dès lors que l’on souhaite exporter son outil dans des pays anglo-saxons.
Je sais pas vous mais moi une question m’intrigue désormais en tant que développeur front-end : finalement comment rendre son site accessible ?
Autant vous prévenir tout de suite, non il ne suffit pas de mettre des descriptions aux images.
À chaque type de handicap, son besoin
Avant de vous partager des bouts de code html à disséminer à droite à gauche, il faut d’abord comprendre les types de handicap et se mettre à leur place. Comment les personnes en situation de handicap voient-elles mon site ? De quoi ont-elles besoin ?
Le handicap visuel
Que ce soit quelqu’un d’aveugle ou malvoyant, le lecteur d’écran devient indispensable car il est impossible de voir le contenu. Et c’est là où en tant que développeur front-end, les différentes balises html prennent tout leur sens. Qui ne s’est pas déjà demandé quelle différence il y a entre les balises nav, section, main ? Je te vois au fond, oui toi en train de mettre des div PARTOUT !
Les balises ont leur sémantique qui est très importante pour les lecteurs d’écran. Donc il est important de structurer son code HTML avec les bonnes balises sémantiques afin qu’une personne en situation de handicap visuel puisse “naviguer” correctement sur votre page.
Je l’ai mentionné mais les descriptions d’image dans l’attribut alt sont importantes. Pas seulement pour le référencement web (oui le robot Google ne perd pas du temps à analyser vos images), mais aussi pour les malvoyants.
Exemple avec Lenna, cette photo très connue du web notamment par ceux qui travaillent dans l’imagerie.
Comment décrire cette image ? Par paresse, on a vite fait d’écrire “Jeune femme”, bien que ce soit déjà un début étant donné que la majeure partie du temps il n’y a soit pas de balise alt, soit une description pré-remplie issue d’un template (type “Profile”). On peut se servir de ChatGPT si l’on manque d’imagination pour les descriptions d’image : “Portrait d’une jeune femme au regard doux, portant un chapeau large avec une plume. Elle est légèrement tournée de profil, regardant vers l’objectif avec un fond flou et chaleureux.”
Ou un peu plus court : “Portrait d’une femme avec un chapeau à plume, regard tourné vers l’objectif.”
Dans les WCAG (Web Content Accessibility Guidelines), les recommandations internationales rassemblant les règles pour l’accessibilité des contenus web (RGAA – Référentiel Général d’Accessibilité pour les Administrations, l’équivalent français), il existe plusieurs niveaux de contraste suggérés et notamment un ratio préféré de 4:5:1. Vous avez compris ? Non ?! Moi non plus au début.
Sans trop partir dans les détails, le contraste entre deux couleurs est calculé à partir des luminances de chaque couleur. Sur un site web, on veut le contraste donc la différence de lumière entre le texte et la couleur de fond, afin bien sûr que le texte soit visible, par tous les yeux possibles.
Voici la formule pour calculer la luminance d’une couleur :
L = 0.2126 × R_s + 0.7152 × G_s + 0.0722 × B_sJe ne vais pas m’étendre sur cette formule qui peut en effrayer certains. Ce qu’il faut retenir, c’est que si l’on reprend le ratio de 4:5:1, cela signifie qu’on accorde plus de poids au vert (G) puis au rouge (R) et enfin au bleu (B) dans une moindre mesure. C’est parce que l’œil humain est plus sensible aux variations de vert, puis de rouge, et moins au bleu.
Je vous invite à tester l’extension Funkify sur Chrome qui permet de simuler les pages web du point de vue d’un daltoniste :
Un dernier point que je souhaite ajouter, c’est la gestion des couleurs. Mettre du rouge pour signifier qu’un élément est une erreur ne suffit pas. Car pour un daltonien, le rouge n’est pas visible donc il faut d’autres éléments significatifs. Ajouter simplement une icône d’erreur comme ❌ ou varier la forme du message du message avec un encadré, des bordures, etc permet de renforcer la compréhension.
Le handicap auditif
Je ne vais pas m’attarder sur celui-ci parce qu’il concerne essentiellement les vidéos. Et les créateurs de vidéos ou les plateformes elles-mêmes proposent des sous-titres synchronisés qui rendent le contenu audio accessible aux malentendants.
Le handicap moteur
Ces personnes vont éprouver des difficultés ou une incapacité à utiliser une souris. Il faut donc leur garantir une navigation au clavier, d’où l’importance encore une fois de se servir des bonnes balises html.
On va aussi éviter de mettre des boutons trop petits. Tout élément sur lequel l’utilisateur va pouvoir interagir doit posséder suffisamment d’espace pour ne pas avoir besoin d’un clic précis.
Le handicap cognitif
Ici cela va concerner tous les handicaps qui causent des soucis de concentration, de compréhension. Ces personnes ne vont pas aimer les interfaces trop chargées qui peuvent provoquer de la confusion, ou des animations qui polluent l’écran.
On va donc garder des interfaces claires et simples.
Récapitulatif des changements à appliquer en tant que développeur front-end
Si vous n’êtes pas développeur front-end (désolé pour vous !), vous pouvez vous arrêter là dans la mesure où cette section va essentiellement reprendre les éléments précédents mais d’un point de vue application au html.
On en a parlé plus tôt, il est nécessaire d’utiliser les bonnes balises et d’éviter de mettre des div à toutes les sauces. header, footer, nav, button, section permettent de faciliter la navigation avec un lecteur d’écran.
Cela permet aussi de naviguer plus facilement à l’aide du clavier en se servant de Tab, Enter, Space. L’attribut tabindex= »0″ sur les boutons permet de mieux gérer l’ordre de tabulation.
Pour vérifier son contraste et optimiser un ratio de 4:5:1 pour les personnes malvoyantes, il existe l’outil Contrast Checker disponible à l’adresse suivante : https://webaim.org/resources/contrastchecker
Même pour des personnes sans difficulté visuelle, un bon contraste reste toujours plus agréable pour la lisibilité de la page.
Pour les images, l’attribut alt est un must-have. Un exemple qui parle de lui-même :
Premier cas, ni le robot Google ne comprend votre graphique, ni une personne aveugle. Deuxième cas, même sans voir le graphique, la description dans la balise alt permet de comprendre ce que l’auteur de la page cherche à montrer.
Il nous reste la gestion des couleurs comme mettre du rouge pour signifier une erreur.
Le deuxième exemple avec l’attribut aria-describedby permet d’expliquer à l’utilisateur qui se servirait d’un lecteur d’écran qu’il s’agit d’une erreur, élément qu’il ne comprendrait pas juste du rouge si l’utilisateur est aveugle.
Vérifier l’accessibilité de son site
Si vous avez utilisé les quelques bonnes pratiques listées ci-dessus, c’est déjà un bon début et mieux que la majorité des sites qui parcourent le web.
Un outil qui permet que l’on a bien fait son job pour nos utilisateurs, c’est LightHouse directement intégré dans la console de développement Chrome qui permet de s’assurer que l’on répond aux critères attendus de l’accessibilité. Ou encore le plugin Axe DevTools qui est une alternative pour les non-adeptes de Chrome.
Questions fréquentes
Pour conclure cet article sur l’accessibilité, je vous propose une section FAQ qui permettra aussi de faire un récapitulatif des informations mentionnées au cours de cette lecture.
● Pourquoi l’accessibilité est-elle importante pour un site web ?
- Cela permet aux personnes en situation de handicap (malvoyants, malentendants, etc) d’utiliser le site. C’est leur rendre service que de rendre un site accessible.
- Dans certains pays, cela réduit les risques légaux en respectant les directives de l’ADA, des WCAG ou de l’Equality Act.
- Indirectement il y a un bonus d’amélioration du SEO (les balises alt par exemple) et de l’UX.
● Comment améliorer le contraste des couleurs sur mon site ?
Il est conseillé de respecter le ratio 4:5:1 suggéré par les WCAG.
Un outil comme Contrast Checker permet de vérifier que le contenu de notre page est lisible.
● Que faut-il mettre comme texte alternatif (dans l’attribut alt) pour une image ?
- Expliquer le contenu, l’information que cherche à transmettre l’image.
● Comment rendre mon site accessible aux lecteurs d’écran ?
- Éviter d’utiliser trop de fois la balise div lorsque ce n’est pas nécessaire.
- Utiliser les bonnes balises sémantiques pour aérer votre contenu, permettre une meilleure lisibilité à vos utilisateurs (button, label, section, nav, …).
● Quels outils utiliser pour tester l’accessibilité d’un site ?
- LightHouse intégré à Chrome qui permet de faire un audit rapidement de l’accessibilité de votre page web.
- Axe DevTools pour faire une analyse plus poussée.
- NVDA sous Windows ou VoiceOver sous Mac sont des lecteurs d’écran dont se serviront vos utilisateurs avec handicap. Autant le tester par soi-même.
