Microsoft a récemment publié un nouvel outil permettant d’auditer l’accessibilité : l’Accessibility Insights https://accessibilityinsights.io.
Solve accessibility issues before they reach your customers.
La promesse est alléchante mais il faut toujours se méfier lorsqu’un outil propose magiquement de régler tous les problèmes d’accessibilité. Spoiler alert : c’est rarement magique et ça se fait rarement en un seul clic.
Accessibility Insights contient trois fonctionnalités principales :
- les tests automatiques (FastPass)
- les tests manuels (Assessment)
- les outils permettant de faciliter l’audit manuel (Ad hoc tools)
Les tests automatiques
Rien de nouveau, Accessibility Insights s’appuie sur l’excellent moteur axe-core pour les tests automatiques. Donc si vous utilisez déjà l’extension aXe Chrome, aXe Firefox ou bien si vous avez l’habitude d’utiliser dans l’inspecteur de Chrome l’onglet « Audits » en cochant « Accessibility » : rien de nouveau, c’est le même moteur derrière.
À ce stade, un point de vigilance s’impose sur les tests automatiques : ils ne sont qu’une métrique et ne reflètent absolument pas le taux de conformité ou le niveau d’accessibilité de votre page (tout comme nous vous indiquions il y a quelques années que les notes fournies par les outils d’audit de performance ne suffisent pas). Les tests automatiques permettent uniquement de vérifier des tests de présence (par exemple : est-ce que chaque image possède un attribut alt ?) mais pas les tests de pertinence (par exemple : est-ce que l’attribut alt est correctement renseigné selon la nature de l’image ?).
En résumé c’est un bon début mais il ne faut surtout pas se limiter à ce type de test. Il faut poursuivre par des tests manuels réalisés par des auditeurs en accessibilité, et idéalement compléter avec des tests d’utilisateurs en situation de handicap.
À ce sujet, il y a d’ailleurs un très bon article de Manuel Matuzovic intitulé Building the most inaccessible site possible with a perfect Lighthouse score. Il s’agit d’une démonstration prouvant qu’il est possible d’avoir une page avec aucune erreur sur axe-core et qui contient pourtant des gros problèmes d’accessibilité.
Les tests manuels
Il s’agit d’une grille permettant de réaliser de l’audit manuel. Là aussi rien de nouveau, les auditeurs en accessibilité utilisent quotidiennement ce genre de grille sous la forme de tableur (Excel ou Google Sheets). Ce qui est intéressant dans cette partie c’est l’aspect pédagogique. Chaque test est accompagné de différentes informations :
- la méthodologie expliquant comment auditer ce test ;
- l’impact utilisateur derrière ce test ;
- des exemples de bonne et mauvaise implémentation de ce test.
Notons que pour les connaisseurs du RGAA (Référentiel Général d’Accessibilité pour les Administrations), on trouve déjà ce genre d’information très utiles concernant la méthodologie et l’impact utilisateur dans le guide : ressources RGAA.
Un taux de conformité est disponible et se met à jour selon le statut des tests (succès ou échec). Il est également possible de faire un export de l’audit en HTML.
Je préfère toutefois apporter une petite mise en garde sur cette affirmation :
Assessment allows anyone with HTML skills to verify that a web app or web site is 100 % compliant with Web Content Accessibility Guidelines (WCAG) 2.0 Level AA.
Il est illusoire de penser qu’une connaissance du HTML est suffisante pour auditer et corriger l’ensemble des points d’accessibilité. C’est effectivement un pré-requis d’avoir une bonne connaissance du HTML et du CSS pour appréhender l’accessibilité, mais il faut surtout connaître les WCAG et comprendre les enjeux et les impacts utilisateurs des différents critères. Dit autrement, on peut appliquer bêtement les recommandations sans chercher à comprendre le pourquoi du comment, mais dans ce cas le risque est fort de reproduire l’erreur ailleurs dans un contexte différent.
Les outils permettant de faciliter l’audit manuel
Cette partie permet d’accéder à des outils facilitant l’audit manuel. Là encore rien de nouveau, il s’agit d’outil déjà existant :
- Automated checks : il s’agit du moteur axe-core comme vu précédemment ;
- Color : la page passe en niveau gris afin de détecter les éventuels informations communiquées exclusivement par la couleur. Outil équivalent déjà existant : Colorblinding sur Chrome ;
- Headings : met en évidence les titres
<hn>de la page. Outil équivalent déjà existant : Headings map sur Chrome / Headings map sur Firefox ; - Landmardks : met en évidence les zones importantes de la page (
<header>,<main>,<footer>etc). Outil équivalent déjà existant : Landmarks sur Chrome / Landmarks sur Firefox ; - Tab stops : permet de suivre l’ordre de tabulation lors de la navigation clavier. Outil équivalent déjà existant : ChromeLens sur Chrome.
Conclusion
Dans les faits, il n’y a rien de novateur ou d’avant-gardiste, Accessibility Insights est un assemblage d’outils existants. L’intérêt principal est d’avoir tout ça dans un seul outil au lieu d’avoir plusieurs extensions. Attention, dans certains cas les équivalents sous forme d’extensions sont un peu plus complets (comme Headings map ou Colorblinding) que les outils d’Accessibility Insights.
Quoiqu’il en soit, il est important de garder en tête qu’il n’existe pas d’outil magique concernant l’accessibilité. Il y a juste des outils (et c’est déjà pas mal) qui permettent de faciliter le travail d’un auditeur en accessibilité. Le mot de la fin de la part de Carie Fisher :
So when people ask me about accessibility tools at trainings and conferences, I am not surprised. They want to push a few buttons and *poof !* summon magical creatures that can go in and find and fix all of their issues.
[…]
You can add UX/UI tests, manual keyboard tests, mobile touch tests, screen reader tests (and other ATs), content readability tests, and (I think, most important) user tests to your workflow to cover the gaps automatic testing leaves behind.
– Carie Fisher, Senior Accessibility Instructor and Developer at Deque