Tester l'accessibilité dans GitLab CI/CD avec un vrai lecteur d'écran
Par Mohammed Ouinas, publié le .
Je suis non-voyant, et je teste l'accessibilité des sites avec un lecteur d'écran tous les jours. Trop souvent, les défauts sont trouvés après la mise en production, quand les corriger coûte le plus cher. Avec AANC, j'ai donc créé un composant CI/CD pour GitLab : à chaque pipeline, le lecteur d'écran NVDA parcourt votre page et vous dit ce qu'il a réellement annoncé.
C'est le principe du shift-left appliqué à l'accessibilité : repérer les défauts pendant le développement, et non une fois le site en ligne.
Transcription de la vidéo
Bonjour. Je suis la voix de synthèse d'AANC, un cabinet d'accessibilité numérique fondé par Mohammed Ouinas, consultant non-voyant. Trop souvent, les défauts d'accessibilité sont découverts après la mise en production, quand ils coûtent le plus cher à corriger. AANC a donc créé un composant pour GitLab : à chaque pipeline, un vrai lecteur d'écran parcourt votre page.
Vous le trouvez dans le catalogue CI/CD de GitLab, sous le nom aanc-accessibilite, avec le logo d'AANC.
À l'écran, voici le fichier point gitlab-ci point yml d'un projet. Il suffit d'ajouter quelques lignes : le nom du composant, et l'adresse de la page à tester. La clé fournie par AANC est enregistrée dans une variable masquée du projet.
La page testée est une boutique de démonstration, avec des défauts volontaires. Voici le vrai pipeline. Le job envoie la demande à AANC. Sur une machine Windows, le lecteur d'écran NVDA parcourt la page : ses titres, ses régions, ses champs et ses liens. Le moteur axe et nos propres mesures contrôlent aussi le contraste, le focus au clavier, le zoom et la largeur de 320 pixels. Le passage dure quelques minutes. Nous passons directement à la fin.
Le job s'est terminé en échec : il a trouvé des défauts. L'accessibilité devient une vraie barrière de qualité, au même titre que vos tests. Si vous préférez, une option garde seulement le rapport, sans bloquer le pipeline.
Voici le rapport, dans le journal du job. Il est écrit pour se lire aussi au lecteur d'écran. Il commence par les corrections à prévoir, les plus rapides d'abord. Pour chaque critère, il dit ce qui était attendu, ce que NVDA a réellement annoncé, la correction proposée, et l'effort estimé. Quand l'outil ne peut pas trancher, il l'écrit : à vérifier à la main. Le rapport est en français et relié au RGAA, ou en anglais et relié au WCAG.
Ce test ne remplace pas un audit. Il contrôle, en tout ou partie, jusqu'à 31 critères du RGAA sur 106, sur une seule page, et il ne teste pas les parcours complets. Son rôle est de repérer plus tôt des défauts concrets. AANC cherche quelques équipes pilotes sur GitLab, pour un essai gratuit d'un mois. Écrivez à contact, arobase, aanc tiret accessibilite point f r. Cette voix est générée par intelligence artificielle.
Pourquoi un lecteur d'écran, et pas seulement un scanner
Un scanner lit le code de la page et applique des règles. Il est utile, mais il ne dit pas ce qu'une personne aveugle entend. Le composant AANC fait tourner NVDA, le lecteur d'écran, sur la page. Un bouton sans intitulé, par exemple, est simplement annoncé « bouton » : la personne ne sait pas à quoi il sert.
Le rapport cite les phrases exactes prononcées par NVDA. Le développeur a donc une preuve concrète de ce qui se passe, pas seulement une règle à interpréter. Pour voir la différence sur une page de démonstration, regardez notre vidéo d'un parcours au lecteur d'écran.
Ce que le test vérifie
Jusqu'à 31 critères du RGAA 4.1.2, en tout ou partie, sur la page indiquée.
- Avec NVDA : les titres, les régions, les noms des champs, les intitulés des liens, et les menus déroulants indiqués.
- Avec le moteur axe-core et nos propres mesures : les images, les cadres, les tableaux, les listes, la langue, le titre de la page, les boutons, les étiquettes, les composants ARIA, le contraste, le focus au clavier, les pièges au clavier, le zoom, la largeur de 320 pixels et l'espacement du texte.
Chaque contrôle aboutit à un résultat clair : réussi, à corriger avec la correction et l'effort estimé, à vérifier à la main quand l'outil ne peut pas trancher, ou sans objet quand la page n'est pas concernée.
Quelques lignes dans votre pipeline
Après avoir enregistré votre clé AANC dans une variable masquée AANC_CLE, ajoutez ceci à votre fichier .gitlab-ci.yml :
include:
- component: gitlab.com/oujdi93200/aanc-accessibilite/nvda-site@1.3.0
inputs:
site_url: https://recette.mon-site.frLe job attend le passage de NVDA, une dizaine de minutes, puis affiche le rapport dans son journal et le garde en artefact. Par défaut, il fait échouer le pipeline si un critère vérifié n'est pas conforme : l'accessibilité devient une vraie quality gate, au même titre que vos tests. Vous pouvez désactiver ce blocage et garder seulement le rapport.
Toutes les options sont décrites dans le mode d'emploi du composant sur GitLab.
L'avis de l'IA sur les images, en option
Un outil sait dire qu'une image a un texte de remplacement, mais pas si ce texte décrit bien l'image. En option, une IA donne son avis sur la pertinence de ces textes (critère 1.3), pour dix images au maximum.
Cet avis reste à vérifier par un humain : il ne compte ni dans les critères, ni dans le résultat du job.
Vos données
- Seuls l'adresse de la page et les noms de menus éventuels sont envoyés à AANC, jamais votre code.
- Les tests tournent sur des machines AANC hébergées en Europe, en région parisienne.
- Sans l'option IA, aucune image n'est envoyée. Avec elle, les images et leur texte de remplacement partent chez Mistral AI, pour un traitement dans l'Union européenne en zéro rétention : ils ne sont pas conservés au-delà de la réponse, ni utilisés pour l'entraînement.
- Chaque rapport n'est visible qu'avec la clé qui l'a demandé.
Ce que ce test ne fait pas
Il ne remplace pas un audit. Il couvre une partie des 106 critères du RGAA, et le résultat n'est pas un taux de conformité officiel. Il ne teste pas non plus un parcours complet, comme une commande ou une démarche en ligne, et le rapport indique ce qui reste à vérifier à la main.
La page testée doit aussi être joignable publiquement en HTTPS : les adresses internes sont refusées.
Son intérêt est ailleurs : repérer plus tôt des défauts concrets, avant qu'ils n'arrivent en production.
Nous cherchons des équipes pilotes
Je cherche quelques équipes qui travaillent sur GitLab pour essayer le composant gratuitement pendant un mois sur leurs projets, et me dire ce qui leur manque. Si ça vous parle, écrivez-moi à contact@aanc-accessibilite.fr ou par le formulaire de contact.
Mohammed Ouinas est consultant en accessibilité numérique et fondateur d'AANC. Non-voyant, il teste les sites au lecteur d'écran.