Tests d’accessibilité automatisés Drupal

L’accessibilité numérique n’est plus une option pour un site public ou institutionnel. Entre les obligations légales du RGAA, les attentes des utilisateurs et les exigences de plus en plus précises des appels d’offres, votre site Drupal doit être accessible et le rester au fil des déploiements. La difficulté n’est pas tant d’atteindre la conformité une fois, c’est de la maintenir alors que le contenu et le code évoluent chaque semaine. C’est précisément là que les tests automatisés entrent en jeu.

Bien comprise, l’automatisation de l’accessibilité fait gagner un temps considérable et empêche les régressions de passer en production. Mal comprise, elle donne un faux sentiment de sécurité : un site qui affiche zéro erreur dans un outil automatique peut rester largement inaccessible. Cet article explique ce que les tests automatisés détectent réellement, ce qu’ils ne détectent pas, quels outils utiliser sur un site Drupal et comment les intégrer à votre pipeline CI sans tomber dans le piège du tout-automatique.

Ce que les tests automatisés détectent vraiment

Commençons par cadrer les attentes. Les outils d’analyse automatique vérifient des critères que l’on peut formaliser en règles déterministes : la présence ou l’absence d’un attribut, un ratio de contraste calculable, une structure HTML conforme à une norme. Sur ce terrain, ils sont rapides, fiables et infatigables.

Concrètement, un outil automatique détecte bien :

• les images sans attribut alt
• les contrastes de couleur insuffisants entre texte et arrière-plan
• les champs de formulaire sans label associé
• les boutons et liens sans nom accessible
• les attributs ARIA invalides ou mal utilisés
• l’absence d’attribut lang sur la page
• les titres de page manquants
• certains problèmes de structure des titres (saut de niveau)

C’est déjà beaucoup et ce sont souvent les erreurs les plus fréquentes en volume. La règle communément admise dans la communauté accessibilité est qu’un outil automatique couvre environ un tiers des critères de conformité. Il faut prendre ce chiffre pour ce qu’il est : un ordre de grandeur utile, pas une mesure exacte. La proportion réelle dépend du référentiel retenu, du type de site et de la nature du contenu. L’important à retenir : automatiser, c’est traiter efficacement une part significative des problèmes, jamais la totalité.

Si vous voulez un panorama complet du cadre réglementaire et des critères concernés, la page dédiée à l’accessibilité RGAA Drupal détaille les niveaux de conformité et la démarche d’audit attendue.

Ce que les tests automatisés ne détectent pas

C’est la partie que les décideurs sous-estiment le plus souvent et c’est la plus importante. Les deux tiers restants des critères demandent un jugement humain, parce qu’ils portent sur le sens et non sur la forme.

La pertinence des textes alternatifs. Un outil vérifie qu’une image possède un attribut alt. Il est incapable de juger si alt="image" décrit correctement un graphique de résultats financiers. La présence de l’attribut est mesurable, sa qualité ne l’est pas.

La logique de navigation. L’ordre de tabulation au clavier suit-il un parcours cohérent ? Un utilisateur qui navigue sans souris atteint-il les contenus dans un ordre qui a du sens ? Un outil peut signaler un piège au clavier évident, mais il ne valide pas qu’un parcours est confortable et intuitif.

Le sens et le contexte. Le contenu est-il compréhensible avec un lecteur d’écran ? Les liens « cliquez ici » répétés sont-ils distinguables dans leur contexte ? Une vidéo dispose-t-elle de sous-titres réellement synchronisés et fidèles ? Ces questions exigent de regarder, d’écouter et de comprendre.

La cohérence visuelle de l’information. Une information transmise uniquement par la couleur (un statut « rouge » ou « vert ») reste invisible pour certains utilisateurs. Détecter automatiquement ce type de problème est, dans le cas général, hors de portée des outils actuels.

Autrement dit, un score de 100 sur un outil automatique signifie « aucune erreur formelle détectable ». Cela ne signifie pas « accessible ». Cette distinction doit être claire dans la tête de toute personne qui pilote un projet, sous peine de prendre de mauvaises décisions sur la base d’un chiffre rassurant mais incomplet.

Les outils à connaître

Plusieurs outils complémentaires couvrent l’essentiel des besoins, du poste de l’auteur jusqu’au pipeline d’intégration continue.

axe-core. C’est le moteur d’analyse de référence, open source et maintenu par Deque. La plupart des autres outils s’appuient sur lui. Il existe sous forme d’extension navigateur (axe DevTools) pour les vérifications ponctuelles et surtout sous forme de bibliothèque intégrable dans des tests automatisés. C’est lui que vous voudrez brancher dans votre pipeline.

Lighthouse. Intégré aux outils de développement de Chrome, Lighthouse fournit un audit d’accessibilité parmi ses catégories (aux côtés de la performance et du SEO). Pratique pour un premier diagnostic rapide et pour suivre une tendance dans le temps. Son audit accessibilité repose lui aussi sur axe-core.

WAVE. Développé par WebAIM, WAVE propose une visualisation directement sur la page : les erreurs et alertes sont superposées au rendu, ce qui aide à localiser un problème dans son contexte. Très apprécié pour expliquer un défaut à une équipe non technique.

Editoria11y. C’est l’outil le plus intéressant côté Drupal, car il s’adresse aux contributeurs, pas aux développeurs. Ce module s’intègre à l’interface d’édition et signale en temps réel, à l’auteur lui-même, les problèmes courants au moment de la rédaction : image sans alternative, titre mal hiérarchisé, lien ambigu. Il déplace une partie de la responsabilité vers la source du contenu, ce qui réduit le nombre de problèmes introduits au quotidien. Sur un site Drupal alimenté par plusieurs rédacteurs, c’est un levier remarquablement efficace.

Ces outils ne s’excluent pas : Editoria11y prévient à la saisie, axe-core et Lighthouse vérifient au build et WAVE aide au diagnostic manuel. Ensemble, ils forment un filet à plusieurs mailles.

Intégrer l’accessibilité dans un pipeline CI

L’enjeu n’est pas de lancer un audit une fois par an, c’est de transformer l’accessibilité en garde-fou permanent. Pour cela, on branche axe-core dans la chaîne d’intégration continue, exactement comme on le fait pour les tests automatisés Drupal fonctionnels. Le principe : à chaque commit ou chaque merge request, le pipeline charge les pages clés dans un navigateur headless, exécute axe-core et fait échouer le build si de nouvelles violations apparaissent.

L’intégration se fait généralement avec un outil end-to-end comme Cypress ou Playwright, couplé à axe-core. Voici l’idée côté test, avec Cypress :

// cypress/e2e/accessibilite.cy.js
describe('Accessibilité des pages clés', () => {
  const pages = ['/', '/services', '/contact', '/blogue'];

  pages.forEach((page) => {
    it(`n'a pas de violation axe sur ${page}`, () => {
      cy.visit(page);
      cy.injectAxe();
      cy.checkA11y(null, {
        runOnly: ['wcag2a', 'wcag2aa'],
      });
    });
  });
});

Côté pipeline, l’étape s’ajoute à votre fichier CI au même titre que les tests fonctionnels :

# .gitlab-ci.yml (extrait)
accessibilite:
  stage: test
  script:
    - ddev start
    - ddev import-db --file=tests/fixtures/db.sql.gz
    - npx cypress run --spec "cypress/e2e/accessibilite.cy.js"
  artifacts:
    when: always
    paths:
      - cypress/screenshots/

Deux conseils pratiques pour que cette démarche tienne dans la durée. D’abord, ciblez les gabarits représentatifs plutôt que chaque URL : tester la page d’accueil, un article, une page de listing et un formulaire couvre la plupart des templates. Ensuite, prévoyez une stratégie pour le code existant. Faire échouer le build sur des centaines de violations préexistantes bloquerait toute l’équipe. L’approche réaliste consiste à figer une ligne de base (les violations connues sont tolérées et tracées) puis à interdire toute nouvelle violation. Vous résorbez le passif au rythme du projet, sans paralyser les livraisons.

La complémentarité avec l’audit humain

Le pipeline automatique est un filet de sécurité contre les régressions formelles. Il ne remplace pas l’audit mené par une personne et c’est une bonne nouvelle, pas une limite : les deux approches répondent à des besoins différents et se renforcent.

L’automatisation traite en continu, à coût quasi nul une fois en place, la part mesurable des critères. Elle libère ainsi le temps de l’audit humain pour ce qui compte vraiment : la qualité des alternatives textuelles, la fluidité de la navigation au clavier, le test au lecteur d’écran et la compréhension globale par un utilisateur en situation de handicap. Un auditeur qui n’a plus à pointer cent contrastes insuffisants peut se concentrer sur le sens.

La bonne séquence est donc la suivante : Editoria11y prévient les erreurs à la source, le pipeline CI bloque les régressions à chaque déploiement et un audit humain périodique (idéalement par une personne formée au RGAA, voire un audit certifié pour les obligations légales) valide ce que la machine ne peut pas voir. Chaque maille rattrape ce qui échappe à la précédente.

Cette articulation est aussi ce qui rend la conformité durable. Obtenir un bon niveau d’accessibilité au lancement d’un site est un projet ; le conserver pendant trois ans de mises à jour de contenu et de fonctionnalités est une discipline. Les tests automatisés sont ce qui transforme un effort ponctuel en propriété stable du site.

Vous voulez automatiser l’accessibilité de votre site Drupal et sécuriser votre conformité dans la durée ? Parlons de votre projet : j’évalue votre situation et je définis avec vous la combinaison d’outils et d’audit adaptée à vos enjeux.