Pourquoi tester ? Aurait-on peur de ce que nous risquons de trouver ?
Pour tester quoi ? Très bonne question, n’est-ce pas ?
L’impact environnemental, la performance, cela se mesure dans des contextes relativement bien maîtrisés. Comment faire lorsque le contexte dépend essentiellement de l’humain, comme pour l’accessibilité ?
Tester l’accessibilité
Pour connaître le niveau d’accessibilité d’un site web, il est nécessaire de procéder à un audit.
Basé sur un référentiel officiel, le Référentiel Général d’Amélioration de l’Accessibilité (RGAA) ou encore les Web Content Accessibility Guidelines (WCAG), cet audit permet d’obtenir un taux de conformité exprimé en pourcentage.
En France, un site est considéré non conforme si le taux est inférieur à 50 %, partiellement conforme si le taux est d’au moins 50 %, et totalement conforme uniquement à 100 %.
Un audit, c’est long, c’est compliqué, et ça nécessite un minimum d’expérience et d’expertise sur le sujet (note : vous souhaitez en savoir plus sur les audits ? Contactez-nous !).
Nos audits, on en prend soin, on les fait avec passion, notre objectif est qu’ils soient utiles, car il s’agit avant tout d’un outil de travail.
Mais un audit, c’est une capture de l’état du site à un instant donné. Toute modification, évolution, peut rendre caduc un travail coûteux.
Alors, à moins de réaliser un audit tous les mois…
Comment faire pour suivre l’évolution de l’accessibilité de mon site ?
Chez Clever Age, nous utilisons des outils de tests automatisés, présentés sous forme d’un tableau de bord.
Les outils actuellement utilisés pour tester l’accessibilité sont : Pa11y (aXe), IBM aChecker, et W3C DOM Validator. Nous avons souhaité tester au-delà de l’accessibilité en ajoutant Lighthouse et EcoIndex. Les tests sont lancés régulièrement de manière à obtenir une indication sur l’amélioration de l’accessibilité, mais aussi d’identifier d’éventuelles régressions.
Attention, ces tests ne remplacent pas un audit ! Aucune erreur remontée est un bon indicateur, mais cela ne garantit pas, et ne peut pas garantir, que le site est accessible à 100 %.
Par contre, ces outils permettent d’obtenir en quelques secondes suffisamment d’éléments pour savoir si un site n’est pas accessible.
L’inverse est plus compliqué, on y reviendra plus tard, et de manière plus détaillée dans un prochain article.
Aux USA, une loi (American with Disabilities Act – ADA) protège les personnes handicapées contre la discrimination. Dans certains États, il est même possible d’obtenir des dommages et intérêts dans le cas où un handicap serait discriminatoire pour accéder à un service en ligne.
Certains cabinets d’avocats se sont alors spécialisés dans la défense des droits des personnes handicapées, mais ne sont pas devenus des experts en accessibilité pour autant : quoi de mieux alors qu’un outil de tests automatisés pour prouver, ou débusquer une faille ?
C’est pourquoi des cabinets, devenus habitués en défense, conseillent désormais de respecter les recommandations suivantes :
- 5 erreurs maximum relevées par les tests automatisés ;
- un score supérieur à 90 dans Lighthouse ;
Un site qui n’a pas ou peu d’erreurs, nécessitera une analyse plus approfondie — et donc du temps — pour identifier une faille permettant d’intenter un procès.
Attention, cela n’empêchera toutefois pas une personne d’arriver sur un site, souhaitant faire un achat, une réservation, une commande, de constater que le service ne lui est pas accessible !
Interpréter et utiliser les résultats
Corriger les erreurs remontées par les outils de tests automatisés permet d’abaisser les risques, mais ne garantit pas l’accessibilité du site.
Comprendre les tests
Il est actuellement impossible de tester certains critères de manière automatisée : pour tester l’accessibilité, nous avons des critères portant sur la présence de certains éléments (environ 30 % maximum des critères), et des critères relevant de la pertinence de certains éléments.
Exemple : on demande à ce que les images, dans le code, portent un attribut ALT (cet attribut permet de renseigner une alternative textuelle à l’image). Un outil pourra facilement rechercher la présence de cet attribut dans le code source. Ensuite, on devra tester si la valeur de cet attribut (le texte qui servira d’alternative à l’image) est pertinente : est-ce que l’image est utilisée à des fins de décoration ? Est-ce que cette image porte une information qui n’est pas disponible sous forme de texte dans la page ? Est-ce que cette image assure une fonction (un bouton par exemple) ?
Un autre exemple qui illustre parfaitement le fait que les outils automatisés ne peuvent être suffisants pour garantir l’accessibilité. Prenons un cas classique de menu, composé de liens de premier niveau (visibles) contenant des liens de second niveau (non visibles) :
Le problème récurrent sur ces menus réside dans l’affichage des sous-menus, souvent prévus au survol de la souris. Comment tester une règle essentielle qui est la navigation clavier, autrement que manuellement ? Si le code n’indique pas qu’il s’agit d’éléments interactifs, qu’ils peuvent changer d’état (visibles / masqués, ouverts / fermés), aucun test automatisé ne pourra le deviner à votre place.
On peut donc avoir des tests qui ne remontent aucune erreur, mais des images avec un texte alternatif erroné et une navigation rendue impossible pour un certain nombre de personnes.
Astuce : il n’est pas toujours évident de savoir si une image est décorative ou informative. Pour nous aider, il existe un arbre de décision très utile : https://www.w3.org/WAI/tutorials/images/decision-tree/fr.
À qui s’adressent ces résultats ?
On pense rapidement au développement, et un peu au design, pour les contrastes notamment.
Hélas, on oublie bien trop souvent l’impact que peut avoir la contribution éditoriale :
- le choix du texte alternatif dont on parlait précédemment, lorsque des images sont mises à jour, un nouvel article est publié, etc. ;
- l’ajout de sous-titres, d’audiodescription et/ou de transcription textuelle pour des médias vidéo et/ou audio ;
- la boîte de Pandore que peut être un éditeur de texte : de fausses listes à puces, des sauts de lignes pour créer des paragraphes, des sélections de couleurs non optimales, etc.
Ces tests ont un autre avantage, ils permettent de démontrer que tout le monde a une part de responsabilité dans le niveau d’accessibilité du site.
Comprendre les résultats
Nous utilisons ces outils depuis maintenant suffisamment longtemps pour nous rendre compte de leur manque de fiabilité. Cela renforce notre position sur le fait que ces outils sont utiles, mais ne peuvent en aucun cas être suffisants.
Nous avons constaté que les erreurs remontées ne sont pas forcément les mêmes d’un outil à l’autre, mais également relevé la présence de faux négatifs.
Exemple d’un site dont nous assurons l’accompagnement de la mise en accessibilité :
L’outil aXe DevTools ne relève aucune erreur, quand l’outil ARC Toolkit en relève une concernant le contraste entre le texte blanc et son fond.
Note : Quel outil a raison ?
Pour le savoir, observons : ARC nous indique que sur l’élément h1 (le titre), la couleur de fond (background color) est blanche, le ratio de contraste est donc de 1:1. Il a raison, mais il ne tient pas compte du fait qu’une image se situe en arrière-plan.
Le conteneur de l’image n’est pas un conteneur parent du conteneur du texte, l’outil ne fait pas le lien entre les 2. Il ne tient pas compte non plus du fait que le conteneur de l’image applique un masque d’opacité permettant d’assombrir l’image afin de s’assurer que le texte blanc sera toujours suffisamment contrasté quelle que soit l’image de fond.
Il reste tout de même essentiel d’utiliser ces outils, notamment pour les raisons suivantes :
- Ce sont les outils utilisés par les cabinets d’avocats aux USA : “Know your enemy” ;
- L’accessibilité devient visible dans un projet, c’est un bon moyen pour impliquer tout le monde ;
- On se mesure, on se compare, ça réveille parfois certains esprits de compétition. On ne va tout de même pas leur retirer ça !
- Et surtout, on peut suivre ce qu’il se passe sur un site : cela fait partie des moyens que nous mettons en place dans notre démarche d’assurance qualité.
La question principale n’est pas de savoir si les tests automatisés d’accessibilité peuvent suffire à éviter des problèmes. Mais, sachant que ces tests ne suffisent pas à rendre un site accessible, de savoir si vous pouvez assumer le fait que votre site restera inadapté, voire inutilisable, pour 20 % de la population.
Seulement des indicateurs ?
Le nombre d’erreurs relevé sera utile pour assurer un suivi. Mais au-delà du nombre, nous obtenons une liste des erreurs rencontrées. Selon l’outil, il y a suffisamment de détails pour transformer cette liste d’erreurs en tickets à glisser dans un backlog.
C’est un bon moyen d’améliorer petit à petit l’accessibilité de votre site, et ça fera des erreurs potentielles en moins sur un audit !
Exemples, avec différents outils :
Conclusion
Les tests automatisés sont essentiels pour assurer un suivi projet, et favorisent également l’implication de tous. Ces tests peuvent être un bon premier pas pour s’engager dans une mise en conformité, et monter en compétence en apprenant à corriger certaines erreurs.
Même s’ils ne sont pas suffisants pour rendre un site accessible, ils restent néanmoins des indicateurs utiles dont il serait dommage de se passer.
