L'accessibilité qui n'est vérifiée qu'une fois par an, lors d'un examen manuel unique, s'érode presque toujours rapidement : toute petite mise à jour de code peut casser quelque chose qui a déjà été corrigé. La solution : intégrer les tests d'accessibilité dans le processus de développement lui-même (CI/CD) en tant qu'étape automatisée, afin que les problèmes soient détectés avant qu'ils n'atteignent la production. Cet article explique comment.
En bref : ce que couvre cet article
Pourquoi un contrôle unique ne suffit pas
Une équipe de développement qui envoie des mises à jour chaque semaine, ou parfois chaque jour, ne peut pas compter sur un audit d'accessibilité annuel pour maintenir une conformité continue. Un nouveau composant ajouté sans tenir compte de l'accessibilité, ou une modification CSS qui réduit accidentellement le contraste, peut rompre l'accessibilité déjà corrigée - et personne ne le remarque jusqu'à ce qu'un utilisateur ou une plainte le révèle. Le même principe s'applique également aux documents — consultez notre guide surerreurs courantes de mappage.
Quels outils automatisés du pipeline CI/CD peuvent détecter
Des outils comme axe-core, Pa11y ou Lighthouse CI peuvent s'exécuter automatiquement à chaque demande d'extraction ou avant chaque déploiement. En quelques secondes, ils vérifient des éléments tels que : le contraste des couleurs, les balises ARIA incorrectes ou en double, le texte alternatif manquant, les étiquettes de formulaire manquantes et l'ordre des titres incorrect. Si la vérification échoue, la demande d'extraction est automatiquement bloquée et ne peut pas fusionner, tout comme une révision de code régulière ou un test unitaire défaillant.
💡 Conseil pratique
Démarrez en "mode d'avertissement" (non bloquant) pendant quelques semaines pour voir combien de problèmes existent déjà dans la base de code, et seulement après un nettoyage initial, transformez la vérification en bloqueur de déploiement - de cette façon, l'équipe ne reste pas "bloquée" face à des centaines d'erreurs le premier jour.
Lorsque des tests manuels sont encore nécessaires
Tout comme pour les tests de documents, les outils automatisés du pipeline CI/CD détectent des problèmes structurels évidents, mais ils ne peuvent pas juger de l'expérience utilisateur réelle : si la navigation au clavier a du sens, si un lecteur d'écran « raconte une histoire cohérente » sur la page, ou si un composant personnalisé (comme un carrousel ou un modal) est véritablement utilisable dans le monde réel. C'est pourquoi il vaut la peine d'associer les contrôles automatisés continus à un audit manuel périodique, trimestriel par exemple.
Comment le mettre en œuvre en pratique
- Choisissez un outil de test adapté à votre pile technologique (axe-core pour la plupart des projets JavaScript, Lighthouse CI pour les projets basés sur un navigateur).
- Exécutez-le en tant qu'étape dans votre pipeline CI, généralement en tant qu'action GitHub, tâche CI GitLab ou étape équivalente dans l'outil CI/CD que vous utilisez.
- Définissez un seuil d'échec clair (par exemple : aucun problème de niveau "critique" par axe-core) avant que la vérification ne devienne un bloqueur.
- Couvrez également vos fichiers PDF : si votre organisation génère automatiquement des documents (factures, rapports), envisagez également d'ajouter une numérisation automatisée pour ceux-ci, dans le cadre du processus de publication.
Vous souhaitez également ajouter des tests PDF automatisés à votre processus ?
Notre outil analyse les fichiers PDF et attribue à chaque document un score d'accessibilité. Vous pouvez l'exécuter comme vérification périodique parallèlement à votre processus CI/CD.
Scannez votre site gratuitement ←Après la numérisation, vous pouvez également rendre accessibles directement et gratuitement les documents trouvés viaAccessiDoc.