En tant que développeurs, nous apprécions les outils gratuits. Nous les utilisons tout le temps. Et lorsque nous nous lançons dans un nouveau projet, l’une des premières choses que nous faisons souvent est de déterminer si nos outils gratuits existants sont à la hauteur de la tâche. Parfois, c’est le cas. Mais quand ce n’est pas le cas, c’est là qu’il faut se tourner vers des outils payants et haut de gamme.
Dans le domaine de l'accessibilité, c'est un phénomène courant. Vous rencontrez des difficultés et vous vous rendez compte que vous avez besoin d'une couverture de test plus poussée, d'une plus grande stabilité, d'une meilleure fonctionnalité globale et d'un moyen plus efficace de détecter les violations en matière d'accessibilité.
Plus facile à dire qu’à faire, n’est-ce pas ? En réalité, passer d’une version gratuite à une version payante peut s’avérer délicat, et vous vous poserez sans doute la question suivante :
- Quels avantages supplémentaires les outils payants m'apporteraient-ils par rapport aux outils gratuits ?
- L'utilisation d'outils payants contribuera-t-elle réellement à rendre mon produit plus accessible ?
- Comment puis-je justifier le budget nécessaire à cela ?
Ce sont là toutes les questions auxquelles j'ai dû faire face, et je vais les passer en revue avec vous une à une dans cet article.
Nous aborderons à la fois les aspects quantitatifs et qualitatifs de chacun d'entre eux : ce que font concrètement ces outils d'accessibilité, comment ils contribuent à rendre les applications plus accessibles, et comment vous pouvez démontrer à la direction que l'utilisation de tels outils apporte des améliorations tant pour l'équipe que pour l'entreprise.
Si vous êtes déjà prêt à franchir le pas, n'hésitez pas à demandez une démonstration de nos outils dès aujourd'hui.
Qu'y a-t-il réellement là-bas ?
Si vous développez des applications en tenant compte de l'accessibilité, vous avez sans doute déjà entendu parler de axe-core. Développé par Deque publié en open source, c’est le principal moteur de test d’accessibilité pour les sites web et les interfaces utilisateur, capable de détecter environ 57 % des violations courantes des WCAG (sans aucun faux positif !). C’est une base solide, mais lorsque vous développez un logiciel prêt à être mis en production, vous avez besoin de plus que ce niveau de référence. Les outils open source ne peuvent identifier qu’une partie des problèmes d’accessibilité et ne disposent pas de politiques ni de mesures de protection à l’échelle de l’équipe. Ils ne peuvent pas établir de normes communes à toutes les équipes, s’intégrer facilement dans les processus CI/CD, bloquer automatiquement le code inaccessible ni assurer le suivi des problèmes. C’est là qu’interviennent les outils payants, axe-core complètent les fonctionnalités axe-core une couverture plus large axe-core des capacités plus avancées.
Quels sont les différents outils ?
Pour déterminer les outils nécessaires, nous abordons généralement plusieurs points clés : quels outils fonctionnent pendant l’écriture du code et lors des tests en local dans le navigateur, et quels outils s’intègrent à notre système de contrôle de version. Du point de vue de l’accessibilité, tous ces points sont couverts par la suite d’outils axe DevTools for Web. Dès que j’écris du code, je peux obtenir un retour instantané grâce à axe DevTools Linter, qui analyse le code de manière statique au fur et à mesure que je l’écris. Il signale les violations courantes en matière d’accessibilité, telles que l’absence de texte alternatif pour les images ou l’utilisation incorrecte des rôles ARIA.
Comme j'aime garder un autre écran ouvert pendant que je travaille, je peux exécuter mon projet avec LocalHost et repérer les problèmes liés à l'affichage de la page web grâce à l'extension Axe DevTools. Le navigateur affichant le code que j'ai écrit via le Modèle objet de document (DOM), il détectera d'autres problèmes, tels qu'un contraste insuffisant entre les couleurs, une fois la page affichée.
En m’entraînant au développement piloté par les tests, j’ai pu intégrer axe Watcher à certains tests Cypress et consulter les résultats dans l’axe Developer Hub. Cet outil surveille l’exécution de mes tests et analyse mon projet au fur et à mesure de sa compilation, sans que j’aie à lui demander manuellement de vérifier chaque étape. Il me suffit d’ajouter quelques lignes de code à ma suite de tests pour qu’il se lance automatiquement lorsque mes tests habituels s’exécutent.
Quelles autres fonctionnalités ces outils offrent-ils ?
La suite DevTools for Web d'axe vous fournit les API, les intégrations GitHub et les hooks « pre-commit » nécessaires pour détecter les problèmes à un stade précoce et garantir le respect des normes d'accessibilité tout au long de votre cycle de vie du développement logiciel (SDLC).
L'extension Axe DevTools intègre également des tests guidés intelligents (IGT). Il s'agit de séquences de test interactives qui ne nécessitent qu'un effort minimal — généralement quelques questions auxquelles il suffit de répondre par « oui » ou par « non » — et qui vous aident à détecter des problèmes d'accessibilité complexes que l'automatisation ne parvient pas à repérer de manière fiable, tels que les pièges de clavier, les problèmes d'étiquetage des formulaires ou un comportement incorrect des fenêtres modales.
J'ai mentionné qu'axe Developer Hub pouvait s'intégrer à votre suite de tests, mais vous pouvez également intégrer ces tests d'accessibilité à vos systèmes d'intégration continue (CI) existants (tels que GitHub Actions, GitLab ou Bitbucket) à l'aide d'une API REST. Je peux également utiliser le linter axe DevTools pour obtenir une couverture similaire encore plus en amont dans mon pipeline. Il peut s'exécuter directement dans une pull request GitHub ou même dans un hook pre-commit, afin de signaler les violations d'accessibilité directement dans le code, à l'instar d'un linter traditionnel.
Quelles possibilités ces outils offrent-ils ?
Avec les outils adaptés, l’accessibilité cesse d’être une série de vérifications ponctuelles isolées pour devenir un élément que je peux intégrer à l’ensemble de mon processus de développement, et que je peux partager avec les autres développeurs de mon équipe. Nous pouvons ainsi valider l’accessibilité au fur et à mesure que nous codons, continuer à la vérifier dans le navigateur, et savoir que ces mêmes validations seront prises en compte dans nos tests automatisés une fois que tout sera configuré dans nos pipelines d’intégration continue. Cela signifie que je peux non seulement avoir confiance en mon application sur des pages statiques, mais aussi dans ses états dynamiques et ses flux utilisateur. Cela facilite également la collaboration, car les problèmes ne restent pas uniquement sur ma machine. Ils sont entièrement visibles, partageables et peuvent être associés à des commits de code sur lesquels toute l’équipe peut agir. Voici un exemple de rapport tiré de l’extension axe pour DevTools.
Quels résultats positifs puis-je espérer obtenir en utilisant ces outils ?
Je dirais que le principal résultat est que l’accessibilité devient une constante. Au lieu de devoir courir pour corriger des problèmes après la production ou après une mise en production, je peux détecter les problèmes plus tôt, à un moment où les corrections sont moins coûteuses et moins perturbantes. Cela se traduit par une livraison plus rapide, moins d’incidents de production et moins de retouches qui grignotent le temps alloué aux sprints. Cette cohérence se reflétera dans les courbes de tendance : les équipes peuvent mesurer les améliorations, prouver leur conformité et démontrer des progrès mesurables à leur direction. En intégrant l’accessibilité de manière normale et fiable dans le processus de développement des produits, nous pouvons proposer des produits de qualité qui sont fonctionnellement utilisables par un plus grand nombre de personnes.
Ces outils seront-ils vraiment utiles, et comment puis-je obtenir un budget pour les acquérir ?
D’un point de vue quantitatif, la réponse est oui. Les outils payants améliorent la précision en allant au-delà des analyses superficielles et en détectant les problèmes d’accessibilité dans des états dynamiques et au cours des parcours utilisateur. Ce sont là des éléments que les outils gratuits négligent systématiquement. Les outils payants améliorent également la rapidité grâce à la mise en place de vérifications qui s’exécutent automatiquement dans l’éditeur, le navigateur et le pipeline, grâce à l’intelligence artificielle et à l’automatisation, ce qui réduit la charge de travail qui incomberait autrement aux testeurs manuels.
Sur le plan qualitatif, les avantages sont tout aussi significatifs. La collaboration en matière d’accessibilité s’en trouve facilitée : les résultats sont visibles par toutes les équipes, peuvent être associés à des commits de code et peuvent être exportés ou transférés directement vers des outils de suivi des tickets tels que Jira. Cela permet ainsi de gagner en efficacité, puisque les corrections sont apportées au cours du cycle de développement plutôt qu’après la mise en production.
Et c’est précisément là qu’intervient la question du budget. Le retour sur investissement est simple : chaque problème détecté plus tôt permet d’éviter des heures de travail supplémentaire, d’accélérer la mise en production des fonctionnalités et de prévenir les incidents de production. Multipliez cela par l’ensemble du code, et le retour sur investissement est bien supérieur au coût de l’outil. Les outils payants aident les équipes à économiser du temps et de l’argent en transférant la détection des défauts de l’assurance qualité vers le développement, où les corrections sont moins coûteuses. Ils améliorent l’efficacité et la collaboration en centralisant la visibilité et en normalisant les résultats. Plus important encore, ils nous aident à créer de meilleurs produits, accessibles à un plus grand nombre de personnes, tout en réduisant le risque de lacunes en matière d’accessibilité pouvant entraîner des poursuites judiciaires ou la frustration des clients.
Et maintenant ?
Nous avons constaté ce qui se passe lorsque les outils gratuits atteignent leurs limites et ne parviennent plus à répondre aux exigences des projets concrets. Nous avons passé en revue les outils premium disponibles, la manière dont ils s’intègrent dans le flux de travail d’un développeur, ce qu’ils permettent de réaliser et les résultats qu’ils offrent. Nous avons également examiné le retour sur investissement : comment ces outils permettent de gagner du temps, de réduire les retouches, d’améliorer la collaboration et, au final, de nous aider à proposer de meilleurs produits à un plus grand nombre de personnes.
À ce stade, la prochaine étape est simple : choisissez les outils adaptés à votre équipe, présentez vos arguments en leur faveur, puis remettez-vous au travail, c'est-à-dire à la création de logiciels accessibles à tous.
Demandez une démonstration dès aujourd'hui pour découvrir comment ces outils fonctionnent dans vos environnements !
