Comment nous avons amélioré les tests d'accessibilité
Au début de notre parcours en matière d'accessibilité, nous avons généralement regroupé les tests d'accessibilité en deux catégories : automatisés et manuels. Les premiers permettaient de repérer rapidement les problèmes les plus évidents détectables par algorithme, tandis que les seconds servaient à identifier tout ce qui nécessitait plus de temps et d'attention. Les tests automatisés s’intégraient bien aux processus rapides tels que l’intégration continue (CI), tandis que les tests manuels nécessitaient une coordination minutieuse avec des testeurs qualifiés pour couvrir tout ce que les outils automatisés ne pouvaient pas faire.
Au fil du temps, nous avons découvert qu'il existait en fait un juste milieu entre ces deux approches. En partenariat avec Assistiv Labs, nous avons combiné de meilleurs processus avec des tests de service de bout en bout pour créer un processus de test qui redéfinit l'automatisé et le manuel. Il s’agit d’une approche intermédiaire, hybride, qui augmente considérablement la couverture automatisée et réduit les tâches de coordination manuelle.
Désormais, nous détectons les problèmes évidents et faciles à résoudre en quelques heures au lieu de plusieurs semaines. Nos nouveaux processus déterminent automatiquement ce qui est urgent et envoient les problèmes aux bonnes équipes, qui les résolvent généralement en quelques jours.
Les résultats sont à la fois techniques et culturels. Nous fournissons des commentaires sur l'accessibilité beaucoup plus rapidement, les équipes résolvent les bugs plus vite et les ingénieurs d'Asana ont commencé à envisager les problèmes d'accessibilité différemment.
Créer des processus pour hiérarchiser les bugs d'accessibilité
À l’échelle d’Asana, il est essentiel de disposer d’un cadre de hiérarchisation solide, soutenu par des processus et des principes de gouvernance. Les équipes doivent savoir ce qui doit être planifié dans leurs backlogs, quand, et ce qui requiert leur attention immédiatement.
Mais il est facile de sous-estimer la difficulté de hiérarchiser les bugs d’accessibilité. La priorité est basée sur une matrice vertigineuse de facteurs uniques, notamment les technologies d'assistance, les navigateurs, les groupes d'utilisateurs concernés, le feedback utilisateur, le domaine du produit, la difficulté de correction, les solutions de contournement, la conformité aux WCAG et le contexte historique. Certains bugs peuvent exister depuis longtemps, mais n'ont été détectés que récemment. D'autres apparaissent avec de nouvelles fonctionnalités. Et certains sont des régressions : des fonctionnalités qui étaient accessibles auparavant, mais qui ne le sont plus.
Pour créer un cadre, nous avons défini formellement différents types de bugs d'accessibilité afin de pouvoir concevoir des processus rationalisés pour chacun d'entre eux. Une étape essentielle a été de définir ce qui constituait une régression et ce qui ne l’était pas.
régression (n)
Un problème documenté (existe-t-il un enregistrement de son fonctionnement, comme des bugs précédents, des fils de commentaires, des captures d'écran ou des enregistrements d'écran ?), reproductible (un collègue est-il en mesure de le reproduire en suivant les étapes décrites ?) qui fonctionnait auparavant et qui ne fonctionne plus.
Les régressions peuvent naturellement bénéficier d'une priorité élevée : la dernière chose que l'on souhaite, c'est un retour en arrière en matière d'accessibilité. Cela peut grandement simplifier la hiérarchisation des priorités dans de nombreux cas.
Cependant, il y a un hic. Les régressions sont définies par des instantanés avant et après. Par exemple, un instantané « avant » pourrait être une vidéo de la fonctionnalité en état de marche et un instantané « après » pourrait être une vidéo d'un nouveau résultat problématique. Les bugs ont naturellement des instantanés « après ». Mais trouver l'instantané « avant » nécessite généralement des recherches approfondies.
Sans une source fiable d’instantanés « avant », il n’était souvent pas utile de prendre le temps de déterminer si un bug pouvait être classé comme une régression. C'est là qu'un nouveau type d'automatisation s'est révélé extrêmement utile.
Automatisation de l'accessibilité de bout en bout
Les tests entièrement automatisés ne sont pas nouveaux dans le domaine des tests d'accessibilité ou pour Asana. Historiquement, axe DevTools et jsx-a11y pour React nous ont fourni une couverture large et horizontale. Mais ils sont superficiels. Nous avons estimé que l'estimation de 30 % de jetons pour les tests automatisés dans l'ensemble du secteur était assez proche des critères WCAG que nous atteignions. En raison de la couverture limitée, les tests manuels permettaient toujours de trouver des bugs que les outils automatisés avaient manqués.
Nous avions besoin d'outils capables d'aller plus loin. Des outils plus étroitement alignés sur nos principes de recherche utilisateur et de gouvernance. C'est ce que nous avons trouvé avec Assistiv. Les tests pour le service de bout en bout d’Assistiv sont rédigés de A à Z par les ingénieurs d’Assistiv sur la base des processus utilisateur et des paramètres de test que nous fournissons. Les suites intègrent des raccourcis clavier, de véritables lecteurs d'écran, des navigateurs et la vision par ordinateur, le tout alimenté par le cloud Assistiv Labs. Le résultat est bien plus qu'une simple simulation : les événements sont transmis à une machine de la même manière qu'un utilisateur humain le ferait, ce qui permet de maximiser la couverture des WCAG et de répondre à des préoccupations plus larges en matière d'accessibilité.
L'automatisation de l'accessibilité de bout en bout est radicalement différente de l'automatisation traditionnelle : elle interagit avec Asana pour accomplir les tâches de la même manière qu'un testeur manuel le ferait. Il est possible de couvrir jusqu’à 75 % des critères des WCAG, selon le scénario de test. Et il y a toujours des experts dotés d'un esprit critique qui veillent sur tout cela en direct. Des collaborateurs d'Asana et d'Assistiv participent à la conception d'actions d'utilisateurs représentatives et à l'examen des résultats, ce qui permet d'améliorer considérablement les tests automatisés en termes de portée, de fréquence et de précision.
Unir les forces
Avec un cadre de hiérarchisation solide en place et une nouvelle automatisation qui est passée de la recherche d'une minorité de bugs à la recherche de la majorité, nous avons mis en œuvre un processus de hiérarchisation performant.
Tout d’abord, les tests automatisés sont synchronisés avec le pipeline d’ingénierie existant d’Asana. Les nouveaux incidents sont détectés en temps quasi réel et mis en corrélation avec les modifications de code qui en sont probablement à l'origine.
Ensuite, un ingénieur Assistiv effectue un examen pour éliminer les faux positifs et rédige un ticket dans le backlog d’Asana avec l’impact sur l’utilisateur contextualisé et des conseils de correction. Comme les tests automatisés sont exécutés en continu, un instantané précédent est facilement accessible et les régressions peuvent être facilement classées. Nous maintenons des processus Asana automatisés qui acheminent le problème vers la bonne équipe.
Dans la pratique, cela signifie que les régressions sont généralement signalées dans les 24 heures suivant une mise en œuvre et documentées de manière à être facilement compréhensibles pour les ingénieurs qui n'ont pas de formation en accessibilité. Cela permet à notre équipe d'accessibilité de définir un SLA pour traiter les régressions et de laisser les équipes produit s'en occuper. Personne n'a à justifier quelle régression vient en premier, en deuxième ou en dernier. Ce sont simplement des bugs qui nécessitent une attention particulière.
Cette décentralisation se traduit directement par un programme plus durable et des expériences plus inclusives pour les utilisateurs finaux. Nous avons beaucoup plus de pouvoir d'action et d'impact, et beaucoup de place pour la créativité, car nous ne sommes pas constamment en train de résoudre des problèmes. Et cela signifie que nous sommes plus satisfaits et plus efficaces.
Le ROI des boucles de feedback plus rapides
Un bug qui passe inaperçu pendant des semaines ou des mois est coûteux à corriger. Quelqu’un doit le trier et l’attribuer à l’équipe appropriée, puis s’assurer qu’il est traité en priorité. L’ingénieur auquel il est affecté n’est probablement pas le même que celui qui l’a causé. Même si c’est le cas, il est difficile de retrouver le contexte oublié, de changer de vitesse ou de se coordonner avec d’autres équipes pour démêler la dette technique qui s’est accumulée au cours des semaines et des mois qui ont suivi.
Pour chiffrer le problème, une étude IBM très citée a révélé qu'il coûte 30 fois plus cher de découvrir des bogues en production que ceux trouvés pendant la phase de conception. Cela semble vrai.
Lorsque les ingénieurs déploient une mise à jour le matin, tout signe de régression commence normalement à apparaître avant la fin de la journée de travail. La boucle de feedback est si courte que nos tests de bout en bout ont été les premiers à nous alerter à plusieurs reprises sur des bugs génériques de l'interface utilisateur, qui ne se limitaient pas aux lecteurs d'écran ou à la navigation au clavier.
Au fur et à mesure que les ingénieurs ont commencé à recevoir plus rapidement les retours des tests de bout en bout, nous avons constaté une réduction de la charge cognitive liée à la priorisation. L'ambiguïté a disparu. Les ingénieurs se disaient : « J’en suis responsable parce que je l’ai livré ce matin. Cela fonctionnait hier et c’est cassé aujourd’hui, je dois le réparer maintenant. » Corriger les bugs d'accessibilité devient comme une mémoire musculaire.
Chez Asana, les bugs d'accessibilité ne sont que des bugs. Et ils sont résolus.
Des solutions pour automatiser l'accessibilité plus efficacement
Avant d'adopter les tests d'accessibilité de bout en bout, notre équipe d'accessibilité a réalisé des progrès significatifs. Du côté des opérations, les équipes de conception et d'ingénierie avaient mis en place des processus de révision documentés, des définitions de régression et des SLA. En ce qui concerne les tests, il existait des solutions automatisées pour des rapports rapides mais superficiels et une assurance qualité manuelle pour des audits approfondis mais chronophages.
Avec la solution de bout en bout, nous disposons d'une solution technique qui complète les efforts existants et vient s'y superposer. Les régressions sont documentées plus tôt, plus en détail et avec davantage de preuves. Pratiquement personne ne perd de temps sur des rapports de bugs qui ne sont pas exploitables ou reproductibles.
Nous avons maintenant une idée claire des nouveaux bugs et des anciens, des processus utilisateur qu'ils affectent et de qui est responsable de leur correction. Nous pouvons prendre de l’avance et nous concentrer sur notre vision de l’accessibilité d’Asana à l’avenir.
À propos des auteurs : Cameron Cundiff (responsable technique) et Jiaxin Zheng (responsable de programme technique) sont tous deux membres du groupe Development Lifecycle, qui se consacre à la fourniture d'outils permettant aux développeurs de concrétiser leurs idées rapidement, de manière robuste et agréable.
