Le coût des faux positifs en matière d'accessibilité

Greg Williams

Par Greg Williams

16 janvier 2019

Image de faux positif

Pause: avant de lire cet article de blog, il est important de comprendre ce qu’est un faux positif en matière d’accessibilité. Il peut également être utile de tester le « False Positive Calculator » disponible surDequeafin de se rendre compte de l’impact des faux positifs. Toutefois, si vous souhaitez une définition rapide, un faux positif se définit comme suit :

Ac·ces·si·bi·li·té Faux pos·i·tif (nom) –résultatd’unproblème d’accessibilité qui est erroné ou qui correspond à un problème en double généré par un outil d’accessibilitéautomatisé défectueux.
« Les faux positifs générés par l’outil de test d’accessibilité automatisé de Karen peuvent être attribués à son manque d’expérience dans l’interprétation des violations des WCAG. Karen ferait sans doute mieux de s’en tenir à la création de mèmes hilarants sur Birdbox. »

Continuons: maintenant que vous avez une bonne compréhension des faux positifs en matière d’accessibilité et que vous avez testé le calculateur de faux positifs, abordons le contexte et l’importance de sa création. Je vous parlerai également de mon expérience en tant que responsable et chef de file de l’accessibilité numérique, et j’expliquerai pourquoi le choix d’un outil automatisé adapté a été déterminant pour mettre en place une pratique d’accessibilité numérique durable et évolutive.

La nécessité de l'automatisation dans le domaine de l'accessibilité en entreprise

En tant que responsable d’un programme d’accessibilité numérique vaste et complexe au sein d’une entreprise du classement Fortune 50, j’étais constamment confronté au défi de faire plus avec moins. Ce n’est certes pas un problème rare, mais c’est un défi qui, compte tenu de l’évolution rapide de l’accessibilité numérique ces dernières années, peut s’avérer difficile à relever.

J'ai commencé comme beaucoup d'autres, en mobilisant un maximum de ressources pour résoudre le problème. Mon entreprise a embauché de nombreux experts hautement qualifiés et coûteux pour tester le grand nombre de pages et d'applications dont nous disposions. Cette approche était viable jusqu'à un certain point, jusqu'à ce que – vous l'avez deviné – la « révolution agile » nous frappe, et que tout le monde passe en urgence d'une approche de développement en cascade à une approche agile. La méthode en cascade nous avait toujours laissé beaucoup de temps entre chaque mise en production. Et, même si nous n’étions pas encore pleinement « agiles », nous sommes passés à des mises à jour incrémentielles, à de petites équipes spécialisées et à des mises en production beaucoup plus fréquentes.

Au fur et à mesure que nous passions de 5 ou 10 équipes travaillant en agile à 20, puis 30, et enfin à plus de 100, l’ancienne méthode consistant à recourir à des évaluations d’expertise métier tout au long du cycle de vie du développement logiciel s’est avérée inefficace. Nous avons pris conscience avec force que, même si nous disposions des fonds nécessaires, il n’était pas envisageable de constituer une équipe d’experts en accessibilité de plus de 100 personnes. Même de simples questions logistiques telles que « mais où diable vont-ils tous s’asseoir ? » étaient impossibles à résoudre.

Fort de mon expérience dans d’autres domaines non fonctionnels, notamment la performance et la sécurité, j’ai décidé de tirer les leçons de mon expérience (et de mes erreurs) et d’opter pour la solution qui a fait ses preuves : les logiciels et l’automatisation ! Heureusement, à cette époque, Deque et d’autres entreprises développaient et commercialisaient d’excellents produits d’accessibilité automatisés, et au moins l’un d’entre eux, proposé par Deque , était même disponible en open source : la bibliothèque de moteurs axe-core .

En nous lançant tête baissée dans le développement logiciel et l’automatisation, nous étions déterminés à intervenir le plus en amont possible dans le cycle de vie du développement logiciel : la conception et la conception étaient nos principales priorités. L’automatisation a été intégrée très tôt dans le processus de développement ; nos développeurs avaient accès à Axe et à d’autres outils d’automatisation payants qui permettaient une intégration continue des builds.

Tous les outils automatisés ne se valent pas

Désormais, d’une simple pression sur un bouton ou grâce à l’intégration d’une version, nous disposions d’une mine d’informations sur les défauts d’accessibilité – parfois, jusqu’à 50 % du total des défauts que nous rencontrions habituellement étaient couverts par le moteur de règles d’Axe. Grâce à l’utilisation de l’extension de navigateur et à l’intégration de l’API par les développeurs, l’objectif était de tout corriger. Lorsque nous avons effectué une analyse automatisée de notre site web, nous nous attendions à obtenir zéro défaut détecté.

Cependant, alors que nous progressions à la vitesse de la lumière, nous avons remarqué que certaines entités – dont nous tairons le nom dans cet article – analysaient notre site web et continuaient de signaler des problèmes. D’où venait cet écart ? Il s’avère que tous les moteurs d’analyse automatisés ne se valent pas. Que vous utilisiez une solution open source ou que vous achetiez un produit auprès d’un fournisseur, la réflexion et le soin apportés au moteur de règles ont leur importance. Une grande importance, même.

Dans l’euphorie des tests automatisés, on peut obtenir une quantité considérable de données sur les défauts, et ces données peuvent devenir accablantes. Ce qu’il faut à ce stade, c’est un moteur de règles de pointe qui vise le zéro faux positif. Nous ne voulons pas que les membres de nos équipes perdent leur temps.  En effet, si les développeurs travaillent sur des problèmes qu’ils doivent ensuite « défaire » à cause de faux positifs, vous perdrez leur confiance. Soyez donc vigilant dans votre choix lorsque vous vous tournez vers l’automatisation pour faire évoluer votre programme d’accessibilité.

Heureusement pour nous, nous disposions déjà de la solution de référence du secteur, axe-core , sur l’ensemble des produits que nous utilisions – zéro faux positifs (bugs mis à part) ! Ces entités dont j’ai parlé plus tôt n’utilisaient manifestement pas axe, et nous avons finalement pu déterminer ce qu’elles utilisaient et reproduire leurs résultats sujets à erreur. Si nous avions utilisé ce moteur ou bien d’autres qui ne se fixent pas pour objectif le « zéro faux positif », nous aurions gaspillé un temps, des ressources et de l’argent précieux.

Création du calculateur de faux positifs

Pour illustrer l’importance que peuvent revêtir les faux positifs pour votre organisation, j’ai mis à votre disposition un calculateur en ligne simple et rapide à utiliser pour réaliser des estimations. En vous basant sur certaines moyennes du secteur pour des tâches telles que l'exécution d'un scan automatisé (30 secondes), la discussion en équipe des défauts détectés (5 minutes), la correction de ces défauts (10 minutes), leur validation (5 minutes), puis éventuellement leur annulation (car il ne s'agissait pas réellement d'un défaut, mais d'un faux positif !), vous pouvez démontrer à votre direction, en termes financiers concrets, l'importance de choisir le meilleur moteur de scan d'accessibilité possible.

Il vous suffit d'entrer les chiffres de votre entreprise dans le calculateur – taux horaire global, nombre de collaborateurs affectés au triage, taux moyen de faux positifs et nombre de pages concernées par cette opération – pour constater la différence, calculée sur mesure pour votre organisation.

Étant donné que certains produits disponibles affichent un taux de faux positifs de 20 % ou plus, c’est un excellent point de départ pour vos calculs. Jouez avec les chiffres et modifiez-les à votre guise ; mais même si vous parvenez à réduire ce taux à 5 %, cela reste un chiffre significatif sur le plan matériel, qui représente de l’argent, du temps et des ressources qui devraient être consacrés à d’autres tâches utiles.

Deque s'engage à améliorer en permanence axe-core et de l’aligner sur les Directives pour l’accessibilité des contenus Web (WCAG), en particulier à mesure que celles-ci évoluent. De grandes entreprises informatiques telles que Microsoft et Google ont choisi axe-core comme le meilleur moteur disponible sur le marché aujourd’hui. Ne laissez pas l’automatisation vous entraîner dans un travail coûteux et inutile : optez pour le moteur de règles qui ne trompe pas – axe-core.

Greg Williams

Greg Williams

Greg Williams est vice-président senior et architecte en chef chez Deque , Inc. Il supervise le développement et les opérations de programmes pour certains des plus grands clients Deque, en les aidant à mettre en place des programmes d’accessibilité aboutis et pérennes.

Avant de rejoindre Deque, Greg a passé plus de 30 ans dans le secteur des technologies de l’information, où il s’est spécialisé dans la gestion de programmes complexes et de grande envergure pour des entreprises du classement Fortune 40. Auparavant, il a servi pendant plusieurs années dans la Marine des États-Unis. Il a connu un grand succès en tant que fondateur et propriétaire du Digital Accessibility Program Office chez State Farm Insurance, où il a développé cette pratique à partir de zéro pour en faire l’un des programmes les plus aboutis au monde entre 2013 et 2018.

Greg a toujours été passionné par la diversité et l’inclusion, et a étendu cette passion à la communauté des personnes en situation de handicap et de l’accessibilité. Il a rejoint Deque en 2018 afin de contribuer au lancement et à la maturation de programmes tout aussi fructueux à travers le monde.

Recevez les articles de blog directement dans votre boîte mail

Pas de bavardages inutiles, mais des informations concrètes sur l'accessibilité, fournies par des experts qualifiés.

Vous acceptez que Deque , utilise et partage des informations conformément à Dequedéclaration de confidentialité. Vous pouvez modifier votre consentement à tout moment en nous contactant.