Utilisation de Lighthouse pour valider l’accessibilité du web
Publié le 17 août 2023 par Andrew Owen (10 minutes)
Je suis depuis longtemps un défenseur de la localisation, c’est pourquoi il était important pour moi de rendre ce site multilingue. Mais je suis un défenseur de l’accessibilité depuis encore plus longtemps. J’aurais donc dû analyser le site bien avant, et je m’en excuse. Les gens ont tendance à penser que l’accessibilité du web concerne le handicap, si tant est qu’ils y pensent. Ils se livrent alors à un rapide calcul mental du type: “Combien d’utilisateurs handicapés compte mon site? “Combien d’utilisateurs handicapés vais-je avoir et combien de temps et d’argent cela va-t-il coûter de rendre mon site accessible? Puis, à moins d’y être contraints par la loi, ils ont tendance à ne rien faire.
L’accessibilité est une chose qu’il faut adopter parce que c’est la bonne chose à faire. Mais si vous devez convaincre un responsable réticent, il vous faudra présenter une analyse de rentabilité. Vous pouvez adopter l’approche de la “carotte et du bâton” (récompense et punition). Aux États-Unis, l’Americans with Disabilities Act (ADA) s’applique aux administrations locales et d’État ainsi qu’aux entreprises ouvertes au public.
En 2016, Guillermo Robles, qui souffre d’un handicap visuel, a intenté une action en justice contre Domino’s Pizza, LLC, en vertu de l’ADA. Il alléguait que le site web et l’application pour smartphone de l’entreprise n’étaient pas accessibles aux personnes qui utilisent des lecteurs d’écran (logiciels qui convertissent le texte à l’écran en audio ou en braille). Parmi les obstacles spécifiques cités figuraient l’absence de “texte alt” pour les graphiques et les liens hypertextes sans texte pour identifier leur but.
Domino’s a fait valoir que l’ADA ne s’appliquait pas aux sites web parce que le ministère de la justice (DOJ) ne maintient pas de normes techniques spécifiques pour le contenu web, en violation de son droit au quatorzième amendement à une procédure régulière. Un tribunal de district a rejeté l’affaire, mais la cour d’appel du neuvième circuit est parvenue à une conclusion différente. La Cour suprême a rejeté une demande d’annulation de l’avis de la Cour du neuvième circuit, établissant ainsi le précédent selon lequel l’ADA s’applique au contenu numérique. L’affaire a finalement été réglée en juin 2022.
En résumé non juridique, Domino’s a dépensé des sommes considérables en honoraires d’avocats pour nuire à sa marque par une mauvaise presse pendant six ans, alors qu’elle aurait pu rendre son site web accessible pour une fraction du coût. Un autre enseignement de cette affaire est que les Web Content Accessibility Guidelines (WCAG) sont la norme consensuelle en matière d’accessibilité numérique. La dernière version (2.2) est actuellement à l’état de projet au moment de la rédaction du présent document.
C’était le “bâton”, passons maintenant à la “carotte”. L’enquête Click-Away Pound Survey a révélé qu’en 2016, plus de 4 millions de personnes au Royaume-Uni ont abandonné un site web de vente au détail en raison des obstacles auxquels elles étaient confrontées, emportant avec elles des dépenses estimées à 14,9 milliards de dollars. En 2019, ce chiffre était passé à 21,8 milliards de dollars. Rien qu’au Royaume-Uni, on estime à 7,15 millions le nombre de personnes ayant des besoins en matière d’accès en ligne, mais l’enquête indique que seulement 8 % d’entre elles contactent les propriétaires de sites pour leur faire part des obstacles qu’elles rencontrent. Il incombe donc aux entreprises de garantir l’accessibilité dès le départ. Mais comment s’y prendre?
Tout d’abord, si vous confiez la conception de votre site web à un sous-traitant, inscrivez l’accessibilité dans le contrat. Idéalement, les recommandations WCAG devraient être respectées lors de la conception et de la construction d’un site. Mais les recommandations évoluent avec le temps et, comme pour la localisation, il est souvent nécessaire d’adapter l’accessibilité à un site web existant. Comme pour la traduction, il n’est pas nécessaire de tout faire en même temps. Selon l’ampleur de votre site, vous aurez peut-être besoin d’un plan d’affaires. Vous aurez certainement besoin d’un plan de projet. Commencez par vous attaquer aux domaines les plus critiques. Dans le domaine du commerce électronique, il s’agit des domaines suivants
Il existe toute une série d’outils permettant de vérifier la conformité aux WCAG, mais si vous utilisez Google Chrome ou Microsoft Edge, vous disposez déjà d’un outil appelé Lighthouse intégré à votre navigateur. Il est également disponible sous forme de module complémentaire pour Firefox (où vous pouvez y accéder à partir d’une icône située en haut à droite du navigateur). Dans Chrome et Edge, faites un clic droit sur une page et sélectionnez Inspect pour afficher les outils de développement. Sélectionnez ensuite Lighthouse dans le menu. Si vous ne le voyez pas, cliquez sur » pour afficher la liste des autres options du menu.
Historiquement, Lighthouse analysait les chargements de pages à froid. Mais depuis la version 10, il peut analyser l’ensemble du cycle de vie des pages et en rendre compte à l’aide de flux d’utilisateurs. Cela vous permet d’analyser l’ensemble d’une application web. Toutefois, cela nécessite l’utilisation de Puppeteer et de l’API Lighthouse. Des connaissances en Node.js seraient utiles. Mais vous pouvez commencer avec les fonctionnalités standard.
Lorsque vous ouvrez la page Generate a Lighthouse report , vous avez le choix entre Mode, Device, Categories et Plugins. Les différents modes sont utiles pour tester différentes choses:
À moins que vous n’utilisiez des flux, vous voudrez vous concentrer sur les modes de navigation et d’instantané. En ce qui concerne les appareils, vous devriez tester à la fois Mobile et Desktop. Dans la section des catégories, vous pouvez sélectionner les performances, les meilleures pratiques, l’optimisation des moteurs de recherche et les applications web progressives. Mais je vous recommande de n’en sélectionner qu’une à la fois, en commençant par l’accessibilité. À moins que vous n’utilisiez Google Ads, vous pouvez ignorer la case à cocher publisher ads sous plugins. Vous pouvez générer le rapport en cliquant sur le bouton bleu en haut à droite du volet. Il sera étiqueté en fonction du mode que vous avez sélectionné.
Si vous effectuez une analyse page par page, commencez par les cas d’utilisation les plus courants. Pour mon site, il s’agira donc de la page d’atterrissage du blog et d’un article comprenant les éléments les plus courants, tels que des extraits de code. La page du blog obtient un score de 85/100 dans le rapport de navigation. Ce n’est pas terrible, mais cela pourrait être mieux ; tout ce qui est inférieur à 80 est mauvais, mais idéalement vous voulez plus de 90. Elle obtient un score de 12/15 dans le rapport sur l’instantané. Il y a beaucoup de place pour l’amélioration. L’article de blog fait beaucoup moins bien en ce qui concerne la navigation (78/100) mais un peu mieux en ce qui concerne l’instantané (13/16). Avec un peu de chance, certains de ces problèmes seront communs à l’ensemble du site et le fait de les résoudre pour ces pages spécifiques améliorera la note de l’ensemble du site.
Il est préférable de commencer par ce qui est le plus facile à corriger, et le plus facile à corriger est le faible contraste des couleurs. Le site devient assez complexe à ce stade, donc la façon la plus simple de corriger cela était d’ajouter un nouveau fichier lighthouse.css à la configuration pour remplacer tous les paramètres de faible contraste. Cela permet à la page du blog de remonter à 88. Il s’avère que le problème sur l’article de blog est la coloration syntaxique de Monokai. Il n’y a qu’une seule couleur à faible contraste, mais elle est très utilisée. Comme les couleurs sont définies par un script, il n’est pas possible de les remplacer par des CSS, et j’ai donc dû ajouter du JavaScript personnalisé pour corriger le problème. Cela a pris plus de temps qu’il n’aurait fallu car j’avais oublié que style.color ne renvoyait pas de valeur hexadécimale pour la couleur.
function fixColor() {
var spanElements = document.getElementsByTagName("span");
for (var i = 0; i < spanElements.length; i++) {
var element = spanElements[i];
if (element.style.color == "rgb(249, 38, 114)") {
element.style.color = "rgb(249, 72, 148)"
};
};
}
La prochaine correction la plus simple concernait les étiquettes de boutons manquantes. C’était un choix délibéré de ma part, car les images ne nécessitent pas de traduction. Mais elles ne sont pas très utiles si vous ne pouvez pas les distinguer et que votre lecteur d’écran dit simplement “bouton”. Dans ce cas, j’ai utilisé la propriété button.ariaLabel dans le JavaScript qui ajoute un bouton de copie aux extraits de code. Cela a suffi pour qu’un article de blog rempli d’extraits de code obtienne une note de 91/100. Il y a également eu un avertissement indiquant que l’attribut maximum-scale de l’élément viewport était inférieur à 5. Je l’ai donc mis à 5 et rien ne s’est cassé. Cela m’a permis d’obtenir un score de 100/100 en mode navigation et de 18/18 en mode instantané.
Pour revenir à la page d’atterrissage du blog, elle obtient un score de 98/100 en mode navigation et 14/15 en mode snapshot. Elle est notée moins bien parce que les titres ne descendent pas d’un cran à la fois. Cela ne devrait poser un problème à un lecteur d’écran que si un titre apparaissait dans le désordre, par exemple en commençant par un titre 2, suivi d’un titre 1. J’ai réussi à obtenir le même score pour la page d’accueil après avoir ajouté quelques paramètres supplémentaires au fichier TOML pour m’assurer que tous les boutons avaient des étiquettes aria. Après quelques heures de travail, toutes les pages que j’ai testées obtiennent 98/100 ou plus en mode navigation, alors que certaines se situaient auparavant dans les 70 %. Je pense que l’effort en valait la peine.
En tout et pour tout, j’ai passé la majeure partie de la soirée à corriger le site et à le tester. Si vous avez un appareil Apple, vous pouvez dire “Dis Siri, Active VoiceOver” pour activer le lecteur d’écran et “Dis Siri, Désactive VoiceOver” pour le désactiver. Je l’ai essayé sur mon iPhone mini et mon iPad Pro et il s’est avéré très utile pour vérifier la navigation et le texte alt.Il est important de noter que lorsque j’ai terminé, la seule différence visible sur le site était une légère modification de la palette de couleurs.Ce qui est une amélioration.J’ai également consulté une version du site datant d’un an sur archive.org pour comparer.
Vous avez donc rendu votre site web accessible.Et maintenant? J’ai récemment écrit sur la valeur de l’analyse.Vous pouvez utiliser des outils d’analyse pour déterminer le temps que les internautes passent sur les différentes parties de votre site web.En évaluant soigneusement les données, vous pouvez déterminer si les internautes abandonnent certaines zones, ce qui pourrait indiquer qu’il y a matière à amélioration.Et assurez-vous que vous êtes à jour avec les dernières recommandations WCAG.
Mais souvenez-vous, au début, j’ai dit que la plupart des gens pensent que l’accessibilité concerne le handicap. Plus précisément, ils pensent souvent au handicap visuel. Mais qu’en est-il de la neurodiversité? Ou même de la diversité en général. Par exemple, les personnes dont l’anglais est la deuxième langue ou qui ne parlent pas l’anglais (qui consultent le web à l’aide d’une traduction automatique). C’est là qu’il est utile d’avoir un guide de style et pour votre contenu écrit destiné à un public mondial diversifié.