Déconstruire une idée reçue
Dans le monde de l’accessibilité numérique, une idée reçue persiste : les tests automatisés ne pourraient détecter que 20 à 30 % des problèmes de conformité. Cette statistique, calculée sur la base du nombre de critères WCAG ou RGAA testables, décourage souvent les équipes qui perçoivent l’automatisation comme un effort à faible rendement. Pourtant, Deque Systems , l’éditeur de la suite d’outils axe, propose une perspective radicalement différente. Leur analyse de données montre que l’automatisation seule peut identifier 57,38 % du volume total des erreurs rencontrées sur des projets digitaux.
Plus encore, combinée à des tests guidés intelligents (semi-automatisés, IGT en anglais), cette approche permet de couvrir jusqu’à 80 % du volume réel des défauts. Mais comment expliquer un tel écart ? Cet article déconstruit ce paradoxe pour révéler pourquoi mesurer l’impact réel des erreurs, plutôt que des critères de conformité, change tout pour les développeurs et les PO (Product Owners).
On estime qu’un seul critère peut générer
Deque
des dizaines d’occurrences d’erreurs
ce sont ces volumes-là que nous devons mesurer,
pas simplement le nombre de critères.
1. Ce que signifient vraiment les chiffres
Pour comprendre cette nouvelle perspective, il faut passer d’une mesure qu’on pourrait qualifier d’“académique” (nombre de critères RGAA ou WCAG non conforme qui permet de calculer un taux de conformité) à une mesure pragmatique.
Le débat n’est plus de savoir combien de critères RGAA ou WCAG un outil peut vérifier, mais bien à quel volume réel d’erreurs concrètes il correspond et qu’il peut éliminer. L’approche est centrée sur l’effort de développement et l’impact utilisateur.
Prenons une analogie simple :
Un seul critère RGAA ou WCAG (par exemple le contraste des couleurs – 3.2 pour le RGAA ou 1.4.3 pour le WCAG) génère en réalité des dizaines, voire des centaines d’erreurs sur un même site. Alors qu’une mesure “académique” ne comptabilise que ce seul critère non conforme.
Par conséquent, la réalité du terrain est que les développeurs devront corriger des centaines d’occurrences. C’est ce volume d’anomalies, qui représente la charge de travail réelle, que l’automatisation intelligente d’axe DevTools permet de traiter massivement.
2. La différence fondamentale : critères de conformité vs. volume d’anomalies
La confusion autour de l’efficacité des tests automatisés vient de deux approches de mesure. L’approche académique, qui a popularisé le chiffre de 20-30 %, est facile à calculer mais trompeuse : elle compte simplement le pourcentage de critères RGAA ou WCAG qu’un outil peut tester. C’est une mesure théorique, mais insuffisante pour illustrer la charge de rémédiation à l’échelle d’un site web.
L’approche des solutions axe de Deque, au contraire, est empirique. Elle mesure le pourcentage du volume total des problèmes identifiés lors d’audits réels qui peuvent être détectés par l’automatisation (lire l’article complet de Deque, en anglais ).
Cette distinction est fondamentale. Mesurer par le volume est un indicateur bien plus pertinent de l’effort et du temps que les équipes devront consacrer aux corrections, car il correspond directement au nombre d’erreurs à traiter dans le code.
3. Le principe de Pareto de l’accessibilité : 7 critères du référentiel WCAG génèrent 80 % du volume d’erreurs à corriger
L’étude menée par Deque révèle un phénomène qui n’est pas sans rappeler le principe de Pareto : une minorité de critères RGAA ou WCAG est responsable de la grande majorité des problèmes d’accessibilité. L’analyse montre que seulement 7 critères sont à l’origine de plus de 80 % du volume total des erreurs observées (lire l’article complet de Deque, en anglais ).
Le plus frappant : le seul critère de contraste des couleurs (1.4.3) représente à lui seul près de 30 % de toutes les anomalies identifiées.
Voici les 7 critères WCAG les plus fréquemment non conformes :
- Langue de la page (3.1.1)
- Analyse syntaxique (Parsing – 4.1.1)
- Contraste (Minimum – 1.4.3)
- Blocs de contournement (2.4.1)
- Contenu non textuel (1.1.1)
- Nom, Rôle, Valeur (4.1.2)
- Informations et relations (1.3.1)
Le fait qu’axe DevTools puisse identifier automatiquement la majorité de ces problèmes récurrents en fait un levier d’efficacité majeur, permettant aux équipes de concentrer leurs efforts là où l’impact est le plus grand.
4. Des données qui parlent : l’étude Deque en chiffres
Ces informations sont étayées par une analyse de données à grande échelle. L’étude a porté sur plus de 13 000 pages auditées pour la première fois, révélant près de 300 000 problèmes d’accessibilité (détails de la méthodologie dans l’article de Deque, en anglais ).
Le résultat principal est sans appel : 57,38 % du volume total de ces erreurs ont été détectés par les seuls tests automatisés, indexés axe-core, le moteur qui alimente axe DevTools. (détails dans l’article de Deque, en anglais ).
« Sur près de 300 000 problèmes d’accessibilité analysés, 57,38 % ont été identifiés par des tests automatisés, avec une politique de zéro faux positif. »
Enfin, combiné à la semi-automatisation (tests guidés intelligents, IGT en anglais), cette couverture peut s’approcher des 80,4 % des défauts d’accessibilité réels.
Schéma expliquant les différents étapes du processus d’automatisation : – étape 1 : automatisation des corrections à hauteur de 57% du volume d’erreurs, – étape 2 : tests semi-automatisés intelligents, +23% soit 80%, – étape 3 : tests manuels pour les 20% restants Ces étapes pour atteindre un niveau supérieur de maturité dans les tests
Schéma illustrant les différentes étapes du codage avec axe DevTools5. La confiance avant tout : la philosophie « zéro faux positif »
Un « faux positif » est une erreur signalée par un outil alors qu’il n’y en a pas. Ces fausses alertes sont particulièrement néfastes : elles érodent la confiance des développeurs, leur font perdre un temps précieux en vérifications inutiles et peuvent les conduire à ignorer toutes les alertes. Conscient de cet enjeu, axe DevTools est conçu sur une philosophie stricte de « zéro faux positif ».
Basé sur le moteur axe-core, l’outil ne remonte que les erreurs avérées à 100 %. Cette fiabilité est essentielle pour que les équipes de développement adoptent l’outil et l’intègrent durablement dans leurs flux de travail. Elles peuvent se fier aux résultats sans réserve et agir immédiatement.
Les faux positifs peuvent augmenter
source IBM
les coûts jusqu’à 386%
6. Un avantage stratégique : accélérer le « Shift Left » et réduire les coûts
La capacité à détecter automatiquement et de manière fiable une si grande partie des erreurs permet d’appliquer la philosophie du « Shift Left » à l’accessibilité — et de générer un avantage économique significatif. Cette approche consiste à intégrer les tests et les contrôles de qualité le plus tôt possible dans le cycle de développement. L’automatisation fiable permet de détecter et corriger dès les premières phases, lorsque le coût est le plus faible.
Maintenir la vélocité est critique.
article de businesswire.com
Tirer parti des tests automatisés et semi-automatisés pendant le développement permet de gagner du temps, réduire les efforts et la remédiation — ce qui réduit directement les coûts.
Corriger un défaut d’accessibilité en production peut multiplier les coûts jusqu’à 30 fois (voire plus selon IBM ) par rapport à une correction effectuée dès la phase de développement. En identifiant les anomalies tôt, les équipes réduisent non seulement le nombre de retours et de corrections complexes, mais aussi l’impact en termes de calendrier, de charge de code, de tests de régression et de perturbation des utilisateurs finaux.
Une véritable culture de « conception accessible » (accessible by design) s’installe ainsi, où la qualité et l’inclusion font partie intégrante du développement, et non un add-on tardif.
Conclusion : au-delà du score, l’impact réel
Le chiffre de 80 % avancé par Deque ne mesure pas la couverture de l’outil, mais révèle une réalité de terrain : la grande majorité des erreurs que rencontrent les utilisateurs provient d’un nombre réduit de critères WCAG ou RGAA sur lequel l’automatisation des tests est très performante et fiable. La véritable performance d’axe DevTools réside dans sa capacité à détecter 57,38 % du volume total des problèmes les plus fréquents.
Pour les équipes, la valeur stratégique est immense : un gain de temps considérable, une fiabilité accrue grâce à l’absence de faux positifs, et la capacité d’intégrer durablement l’accessibilité dans les processus agiles.
Et si la véritable mesure du succès n’était pas un simple score de conformité, mais la vitesse à laquelle vous éliminez les obstacles concrets pour vos utilisateurs pour leur offrir une expérience non bloquante ?
Nota bene
Il est important de rappeler que l’automatisation, aussi puissante soit-elle, ne remplace pas l’expertise humaine. Les tests manuels et l’analyse par des experts en accessibilité restent indispensables pour une couverture complète.
Pour intégrer cette approche « accessible by design » dans vos projets et bénéficier de la puissance d’axe DevTools, découvrez le partenariat entre Ipedis et Deque. Pour en savoir plus sur la méthodologie et les bénéfices pour les équipes, consultez le rapport de Deque sur la couverture des tests automatisés (rapport de Deque , en anglais).
Lexique :
- WCAG (Web Content Accessibility Guidelines) : Il s’agit d’un référentiel international publié par le World Wide Web Consortium (W3C) qui décrit ce qu’il faut faire pour rendre les contenus numériques accessibles aux personnes en situation de handicap.
- RGAA (Référentiel Général d’Amélioration de l’Accessibilité) : C’est le référentiel français qui transpose et complète les normes WCAG. Il fixe les exigences d’accessibilité numérique et les vérifications requises.
