Lighthouse + Pa11y : automatiser l’audit accessibilité dans votre CI/CD — tutoriel 2026

Introduction

Un audit d’accessibilité réalisé une fois par an dans un fichier Excel, ça ne suffit plus. En 2026, les équipes web sérieuses déploient des vérifications automatisées à chaque pull request : si votre PR casse un critère WCAG 2.2 ou fait chuter le score Lighthouse en dessous de 90, le pipeline bloque le merge et envoie un rapport détaillé dans Slack ou Telegram. C’est exactement ce que vous allez mettre en place dans ce tutoriel.

Deux outils forment le cœur de cette approche. Lighthouse, développé par Google et intégré nativement dans Chrome DevTools, analyse une page selon cinq axes (Performance, Accessibilité, Bonnes pratiques, SEO, Progressive Web App) et produit un score de 0 à 100. Son pendant CI, Lighthouse CI (@lhci/cli), adapte cet outil aux pipelines automatisés en gérant des assertions, des seuils de blocage et un serveur d’historique. Pa11y, de son côté, est un auditeur d’accessibilité pur, fondé sur le moteur axe-core et htmlcs, capable de crawler plusieurs pages d’un site, de lire une configuration JSON et de produire des rapports exploitables par des scripts shell ou un tableau de bord dédié.

L’idée directrice de ce tutoriel est la suivante : Lighthouse CI s’occupe de surveiller le score global et de bloquer les régressions de performance et d’accessibilité agrégée, tandis que Pa11y descend dans le détail des violations WCAG page par page et remonte des erreurs précises (élément, ligne de code, critère). Les deux outils sont complémentaires et s’installent en moins de dix minutes.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants sur votre machine de développement ou sur votre runner CI :

• Node.js 20 LTS ou supérieur — vérifier avec node -v. Lighthouse CI et Pa11y sont des paquets npm ; ils requièrent Node 18 minimum, mais la version 20 LTS est recommandée en production pour bénéficier du support à long terme jusqu’en avril 2026.
• Google Chrome ou Chromium installé sur le système — Lighthouse pilote Chrome en mode headless. Sur un runner GitHub Actions Ubuntu, Chrome est déjà présent. Sur un serveur Debian/Ubuntu nu, installez-le via apt install chromium-browser ou le paquet Google Chrome officiel.
• npm 10+ ou yarn 4+ — gestionnaire de paquets pour l’installation des outils.
• Un site web accessible en HTTP(S) depuis le runner — une URL locale (http://localhost:3000) convient pour les tests en développement, une URL de staging pour les tests CI.
• Temps estimé : 25 minutes pour la configuration complète, hors mise en place du dashboard Pa11y qui nécessite MongoDB et est optionnelle.

Étape 1 — Lighthouse vs Pa11y vs Axe-Core : choisir le bon outil pour chaque besoin

Avant d’installer quoi que ce soit, il est important de comprendre pourquoi ces trois outils coexistent plutôt que de se substituer. Cette clarté vous évitera de dupliquer les vérifications ou, pire, de ne couvrir qu’une fraction des critères accessibilité en croyant être exhaustif.

Axe-core est le moteur de détection de violations WCAG développé par Deque Systems. Il fonctionne en analysant le DOM d’une page chargée dans un navigateur et en appliquant un ensemble de règles codifiées (plus de 100 règles couvrant WCAG 2.1 niveau A et AA, plus des règles WCAG 2.2 en version 4.x). Axe-core est une bibliothèque bas niveau : elle ne pilote pas de navigateur elle-même. Elle est utilisée en interne par Pa11y, par le plugin Lighthouse Accessibility, par les extensions de navigateur Axe DevTools, et par de nombreux frameworks de test comme Cypress ou Playwright.

Pa11y est un outil CLI et une API Node.js qui orchestre Chromium via Puppeteer, charge une page, y injecte axe-core et htmlcs (HTML Code Sniffer), et agrège les violations détectées. Son point fort est la capacité à traiter une liste de pages en une seule commande, à lire une configuration JSON décrivant les sélecteurs à ignorer, les standards cibles (WCAG2AA, WCAG2AAA, Section508), et à produire des sorties en JSON, CSV ou HTML. C’est l’outil idéal pour auditer un site complet de manière scriptée.

Lighthouse, développé par Google, va plus loin qu’un simple audit accessibilité : il mesure également les Core Web Vitals, le SEO technique, l’utilisation des bonnes pratiques HTTP et la Progressive Web App. Son module accessibilité utilise lui aussi axe-core, mais y ajoute des vérifications manuelles signalées comme à valider par un humain. Le score agrégé (0-100) facilite le suivi de tendance et la communication avec des non-techniciens. Lighthouse CI ajoute la gestion des seuils de blocage et l’historique des scores.

La stratégie recommandée pour une PME est la suivante : Lighthouse CI sur chaque PR pour le score global (bloquer si accessibility < 90), Pa11y en audit hebdomadaire multi-pages pour les détails des violations, et axe-core directement dans les tests Playwright ou Cypress pour les flux critiques (formulaire de contact, panier, page d'accueil). Les trois niveaux se complètent sans se remplacer.

Étape 2 — Lighthouse CLI : installation et premier audit

Lighthouse CLI s’installe en tant que paquet npm global ou en dépendance de développement. Pour un usage en CI, la dépendance locale est préférable car elle garantit que toute l’équipe utilise la même version et que le runner dispose exactement du même binaire que votre machine.

Commencez par initialiser un fichier package.json si votre projet n’en a pas encore, puis installez Lighthouse en dépendance de développement :

# Installer Lighthouse CLI en dépendance de dev
npm install --save-dev lighthouse

# Vérifier l'installation
npx lighthouse --version
# Doit afficher quelque chose comme : 12.3.0

Une fois installé, lancez votre premier audit sur une URL de staging ou sur votre serveur local. L’option --output=json produit un fichier JSON exploitable par des scripts, tandis que --output=html génère un rapport visuel interactif — utile pour partager les résultats avec un client ou un responsable produit non technique.

# Premier audit avec sortie HTML et JSON
npx lighthouse https://votre-site.example.com \
  --output=json \
  --output=html \
  --output-path=./rapports/audit-2026-04 \
  --chrome-flags="--headless --no-sandbox" \
  --only-categories=accessibility,performance

L’option --chrome-flags="--headless --no-sandbox" est indispensable sur un serveur CI Linux où Chrome tourne sans interface graphique et souvent sans les namespaces de sécurité du noyau qu’exige le mode sandbox. L’option --only-categories accélère l’audit en n’exécutant que les catégories qui vous intéressent. Lighthouse génère alors deux fichiers : audit-2026-04.report.json et audit-2026-04.report.html. Ouvrez le HTML dans un navigateur pour explorer les violations ligne par ligne. Le JSON sera consommé par vos scripts d’assertion.

Pour extraire rapidement le score accessibilité depuis le JSON en ligne de commande, utilisez jq :

# Extraire le score accessibilité (entre 0 et 1, multiplier par 100)
cat rapports/audit-2026-04.report.json \
  | jq '.categories.accessibility.score * 100'
# Output attendu : 94 (ou toute valeur entre 0 et 100)

Un score de 94 signifie que Lighthouse n’a détecté aucune violation automatiquement détectable majeure sur cette page. Il reste toujours une part de vérification manuelle (contraste de couleur dans des contextes dynamiques, navigation clavier, lecteur d’écran), mais le score automatique à 90+ garantit l’absence des violations les plus fréquentes et les plus impactantes.

Étape 3 — Pa11y CLI : audit multi-pages avec configuration JSON

Pa11y excelle dans l’audit de plusieurs pages simultanément, ce qui est exactement le besoin d’une PME dont le site comporte une page d’accueil, une page services, un formulaire de contact et un blog. Installez Pa11y en dépendance de développement :

npm install --save-dev pa11y pa11y-ci

pa11y est le moteur CLI pour auditer une page à la fois, tandis que pa11y-ci est l’orchestrateur conçu pour le CI qui lit une configuration JSON et audite une liste d’URLs. Créez un fichier .pa11yci.json à la racine de votre projet :

{
  "defaults": {
    "standard": "WCAG2AA",
    "timeout": 30000,
    "wait": 500,
    "chromeLaunchConfig": {
      "args": ["--no-sandbox", "--disable-setuid-sandbox"]
    },
    "ignore": [
      "WCAG2AA.Principle1.Guideline1_4.1_4_3.G18.Fail"
    ],
    "reporters": ["cli", "json"]
  },
  "urls": [
    "https://votre-site.example.com/",
    "https://votre-site.example.com/services/",
    "https://votre-site.example.com/contact/",
    "https://votre-site.example.com/blog/"
  ]
}

La clé defaults applique ces paramètres à toutes les URLs listées. Le standard WCAG2AA correspond au niveau de conformité exigé par le RGAA 4.1 (référentiel français qui transpose WCAG 2.1 niveau AA). L’option wait: 500 attend 500 millisecondes après le chargement de la page pour laisser les scripts JavaScript s’initialiser — utile pour les SPAs ou les sites avec du contenu chargé asynchroniquement. Le tableau ignore permet d’exclure des règles spécifiques : dans l’exemple ci-dessus, on ignore un critère de contraste connu pour produire des faux positifs sur certains thèmes WordPress, à condition d’avoir validé manuellement ce contraste par ailleurs.

Lancez l’audit multi-pages avec :

npx pa11y-ci --config .pa11yci.json --json > rapports/pa11y-2026-04.json

Le fichier JSON produit liste chaque URL avec ses violations : type (error, warning, notice), code WCAG, sélecteur CSS de l’élément fautif, et message explicatif. Un script shell ou Node.js peut ensuite parcourir ce fichier pour compter les erreurs et déclencher une notification ou bloquer un pipeline. Pa11y-ci retourne un code de sortie non nul si au moins une erreur est trouvée, ce qui suffit pour faire échouer un job CI sans aucun script supplémentaire.

Étape 4 — Pa11y Dashboard : suivi historique des violations

Pour une PME qui s’engage dans une démarche RGAA progressive sur plusieurs mois, il est précieux de visualiser l’évolution du nombre de violations dans le temps plutôt que de simplement passer ou échouer. Le projet Pa11y Dashboard (github.com/pa11y/pa11y-dashboard) offre une interface web qui stocke les résultats des audits dans MongoDB et trace des graphiques de tendance.

Le dashboard s’installe via npm et nécessite MongoDB 6 ou supérieur comme base de données. Sur un VPS Ubuntu, installez d’abord MongoDB depuis les dépôts officiels de MongoDB Inc. (évitez la version des dépôts Ubuntu qui est souvent obsolète), puis clonez et configurez le dashboard :

# Cloner le dépôt officiel
git clone https://github.com/pa11y/pa11y-dashboard.git
cd pa11y-dashboard
npm install

# Copier et éditer la configuration
cp config/development.json config/production.json
# Éditer config/production.json : renseigner l'URL MongoDB et le port

# Démarrer le dashboard
NODE_ENV=production node index.js

Le fichier de configuration production.json contient la chaîne de connexion MongoDB (mongodb://localhost:27017/pa11y-dashboard), le port d’écoute (par défaut 4000) et le nombre maximum de résultats à conserver par URL. Une fois démarré, le dashboard expose une interface accessible sur http://votre-serveur:4000 où vous pouvez ajouter les URLs à surveiller, déclencher des audits manuels et visualiser l’historique des violations.

Pour les PME qui ne souhaitent pas gérer MongoDB, une alternative plus légère consiste à stocker les rapports JSON dans un dépôt Git dédié et à utiliser un simple script de visualisation en ligne basé sur Chart.js. Le résultat est moins sophistiqué, mais zéro infrastructure supplémentaire.

Étape 5 — Intégration GitHub Actions avec Lighthouse CI

Lighthouse CI est le compagnon officiel de Lighthouse pour les environnements d’intégration continue. Il gère les assertions sur les scores, compare les résultats à une baseline, et peut stocker l’historique sur un serveur Lighthouse CI dédié ou sur lhci.appspot.com. Installez-le en dépendance de développement :

npm install --save-dev @lhci/cli

Créez ensuite un fichier de configuration Lighthouse CI à la racine du projet, nommé lighthouserc.json :

{
  "ci": {
    "collect": {
      "url": ["http://localhost:3000/", "http://localhost:3000/contact/"],
      "numberOfRuns": 3,
      "settings": {
        "chromeFlags": "--no-sandbox"
      }
    },
    "assert": {
      "preset": "lighthouse:recommended",
      "assertions": {
        "categories:accessibility": ["error", {"minScore": 0.9}],
        "categories:performance": ["warn", {"minScore": 0.75}],
        "color-contrast": "error",
        "image-alt": "error",
        "label": "error",
        "link-name": "error"
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

La section collect définit les URLs à auditer et le nombre de passages (3 passages permettent de moyenner les résultats et de réduire la variance). La section assert définit les seuils : le score accessibilité doit dépasser 0.9 (90/100) sous peine d’erreur bloquante, tandis que la performance génère un avertissement sans bloquer. Les assertions sur des règles individuelles (color-contrast, image-alt, label, link-name) bloquent immédiatement si ces règles spécifiques échouent.

Créez maintenant le fichier workflow GitHub Actions dans .github/workflows/accessibility-audit.yml :

name: Audit Accessibilité

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main]

jobs:
  lighthouse-accessibility:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout du code
        uses: actions/checkout@v4

      - name: Configuration Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Installation des dépendances
        run: npm ci

      - name: Démarrage du serveur de preview
        run: npm run preview &
        # Adapter selon votre stack : next start, vite preview, etc.

      - name: Attendre que le serveur soit prêt
        run: npx wait-on http://localhost:3000 --timeout 60000

      - name: Audit Lighthouse CI
        run: npx lhci autorun
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Ce workflow se déclenche sur toute PR vers main ou develop, ainsi qu’à chaque push sur main. Il démarre votre serveur de preview en arrière-plan, attend qu’il soit disponible grâce à wait-on, puis exécute lhci autorun qui lit automatiquement lighthouserc.json pour collecter, asserter et uploader les résultats. La variable LHCI_GITHUB_APP_TOKEN permet à Lighthouse CI d’annoter directement la PR GitHub avec les résultats sous forme de check status.

Étape 6 — Bloquer une PR si le score d’accessibilité descend sous 90

La configuration présentée à l’étape 5 suffit à bloquer une PR via le mécanisme de checks GitHub, mais il faut configurer la protection de branche pour que ce check soit required. Rendez-vous dans les paramètres de votre dépôt, section Branches, puis activez la protection sur main en cochant Require status checks to pass before merging et en ajoutant le check lighthouse-accessibility à la liste des vérifications requises.

Si vous préférez une approche sans token GitHub App et sans upload vers lhci.appspot.com, vous pouvez utiliser une assertion sur le code de sortie du script directement dans le workflow. Ajoutez ce job en complément dans le même fichier YAML :

  pa11y-strict-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run preview &
      - run: npx wait-on http://localhost:3000 --timeout 60000
      - name: Pa11y CI — erreur si violation WCAG2AA
        run: |
          npx pa11y-ci --config .pa11yci.json
          # pa11y-ci retourne exit code 2 si au moins une erreur
          # Le job CI echoue automatiquement si exit code != 0

Avec cette configuration en deux jobs parallèles (Lighthouse pour les scores globaux, Pa11y pour les violations détaillées), toute PR qui introduit une régression d’accessibilité sera bloquée à deux niveaux indépendants. Le développeur reçoit dans l’interface GitHub les détails des violations Pa11y directement dans les logs du job, et le rapport Lighthouse CI avec les scores avant/après sur la PR. Cette visibilité immédiate est ce qui transforme une vérification théorique en comportement d’équipe concret.

Étape 7 — Reporting Slack et Telegram

Les bloqueurs CI sont efficaces pour les développeurs, mais les responsables de projet ou les clients veulent souvent recevoir un récapitulatif hebdomadaire sans aller chercher les logs GitHub Actions. Vous pouvez envoyer un rapport synthétique vers Slack ou Telegram en quelques lignes de shell dans votre workflow.

Pour Slack, créez une Incoming Webhook dans votre workspace Slack (api.slack.com/messaging/webhooks), stockez l’URL dans un secret GitHub (SLACK_WEBHOOK_URL), puis ajoutez cette étape en fin de job :

      - name: Notification Slack si échec
        if: failure()
        run: |
          curl -X POST "$SLACK_WEBHOOK_URL" \
            -H 'Content-type: application/json' \
            --data '{
              "text": ":rotating_light: *Audit accessibilité ÉCHOUÉ* sur `'"$GITHUB_REF_NAME"'`\nPR : '"$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/pull/${{ github.event.pull_request.number }}"'"
            }'
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Pour Telegram, préféré par de nombreuses équipes en Afrique de l’Ouest pour son accessibilité sur connexion mobile, créez un bot via @BotFather, récupérez le token et l’identifiant du chat, puis stockez-les dans les secrets GitHub (TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID). Le rapport s’envoie ainsi :

      - name: Notification Telegram
        if: always()
        run: |
          STATUS="✅ PASS" 
          if [ "${{ job.status }}" = "failure" ]; then STATUS="❌ FAIL"; fi
          MESSAGE="Audit accessibilité ${STATUS}%0ABranche : ${GITHUB_REF_NAME}%0ACommit : ${GITHUB_SHA:0:7}%0ARepo : ${GITHUB_REPOSITORY}"
          curl -s "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
            -d "chat_id=${TELEGRAM_CHAT_ID}" \
            -d "text=${MESSAGE}"
        env:
          TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
          TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}

L’option if: always() garantit que le message est envoyé que le job ait réussi ou échoué. L’encodage %0A remplace les retours à la ligne dans l’URL de l’API Telegram. Pour un reporting hebdomadaire plutôt qu’à chaque PR, ajoutez un déclencheur schedule au workflow : cron: '0 7 * * 1' exécute l’audit chaque lundi matin à 7h UTC.

Erreurs fréquentes

Adaptation au contexte ouest-africain

La majorité des tutoriels sur Lighthouse CI supposent GitHub.com et des runners cloud avec une connexion haut débit permanente. La réalité des équipes techniques en Afrique de l’Ouest est souvent différente : hébergement sur des VPS locaux ou régionaux, utilisation de Forgejo en self-hosted pour la forge Git (alternative open-source à GitHub et GitLab, fork de Gitea activement maintenu depuis 2022), et connexions parfois instables sur les machines de développement.

Forgejo Actions est compatible avec la syntaxe des workflows GitHub Actions, ce qui signifie que les fichiers YAML décrits dans ce tutoriel fonctionnent sans modification sur un runner Forgejo. La seule adaptation nécessaire est le remplacement de actions/checkout@v4 et actions/setup-node@v4 par leurs équivalents miroirs hébergés sur code.forgejo.org (https://code.forgejo.org/actions/checkout et https://code.forgejo.org/actions/setup-node) pour éviter les appels sortants vers GitHub pendant l’exécution CI. Sur un runner self-hosted avec Chrome et Node.js pré-installés, toute la chaîne d’audit tourne en local, sans dépendance externe, ce qui la rend robuste même lors d’intermittences de la connexion internationale.

Pour les PME qui ne peuvent pas encore viser le score 90 immédiatement — parce que leur site WordPress existant cumule des années de thèmes non optimisés et de plugins tiers — la stratégie recommandée est un engagement RGAA progressif en trois phases : phase 1 (mois 1-2), corriger les violations de niveau A les plus critiques (alternatives textuelles aux images, étiquettes de formulaires, contrastes < 3:1) et viser le score 70+ ; phase 2 (mois 3-4), traiter les violations de niveau AA les plus fréquentes et viser 80+ ; phase 3 (mois 5-6), atteindre 90+ et mettre en place le blocage automatique des PR. Cette progression doit être documentée dans un Plan d'Amélioration de l'Accessibilité (PAA) que certains donneurs d'ordre publics en Afrique de l'Ouest commencent à exiger dans les appels d'offres numériques.

Pour les équipes utilisant un audit hebdomadaire plutôt qu’un audit par PR (cas des sites principalement gérés via un CMS sans pipeline de déploiement automatisé), configurez un cron Forgejo Actions ou un cron système sur votre VPS qui exécute Pa11y-ci chaque lundi matin sur les pages critiques du site en production et envoie le rapport en JSON vers un canal Telegram dédié à l’équipe. C’est une approche de surveillance passive qui détecte les régressions introduites par des mises à jour de plugins WordPress ou des modifications de contenu par un éditeur non technique.

Tutoriels frères

• RGAA 4.1 : checklist d’audit manuel pour les sites ouest-africains — la complémentarité indispensable à l’audit automatique : les 50 critères qui ne peuvent pas être testés par un script.
• Axe-core + Playwright : tests d’accessibilité dans vos tests end-to-end — intégrer axe-core directement dans vos tests Playwright pour auditer les flux utilisateur critiques (connexion, formulaires, panier).

Pour aller plus loin

• Retour au pilier : Site web accessible RGAA et green IT 2026 : conformité Afrique de l’Ouest
• Documentation officielle Lighthouse : developer.chrome.com/docs/lighthouse — référence complète des métriques, des catégories et des options CLI.
• Documentation officielle Pa11y : pa11y.org — documentation de Pa11y CLI, Pa11y-ci et Pa11y Dashboard avec exemples de configuration.
• Lighthouse CI sur GitHub : github.com/GoogleChrome/lighthouse-ci — dépôt officiel avec la documentation de toutes les options d’assertion et les configurations avancées.
• WCAG 2.2 : w3.org/TR/WCAG22 — le standard international de référence, dont RGAA 4.1 est une transposition.
• Formation accessibilité web ITSkillsCenter : notre parcours pratique de 12 heures couvre l’audit manuel RGAA, la correction des violations WCAG les plus fréquentes en HTML/CSS/JavaScript, et l’intégration CI/CD complète décrite dans ce tutoriel.

FAQ

Q : Lighthouse et Pa11y détectent-ils les mêmes violations d’accessibilité ?

Pas entièrement. Les deux utilisent axe-core comme moteur de base, donc les règles axe sont couvertes par les deux. Cependant, Pa11y ajoute htmlcs (HTML Code Sniffer) qui détecte des violations supplémentaires non couvertes par axe-core, notamment certains critères WCAG liés à la structure des tableaux et à la hiérarchie des titres. En pratique, faire tourner les deux outils est recommandé pour une couverture maximale.

Q : Pourquoi le score Lighthouse accessibilité varie-t-il entre deux exécutions sur la même page ?

Le score Lighthouse accessibilité est normalement stable car il ne dépend pas des performances réseau ou du CPU — contrairement au score Performance. Si vous observez des variations, vérifiez que votre page ne charge pas de contenu dynamique différent selon le contexte (A/B testing, personnalisation selon l’IP, pop-ups aléatoires). Utilisez numberOfRuns: 3 dans Lighthouse CI pour moyenner les résultats et réduire les variations liées aux ressources partagées du runner CI.

Q : Pa11y-ci peut-il auditer des pages derrière une authentification ?

Oui. Pa11y supporte l’option actions dans sa configuration JSON pour simuler des interactions utilisateur avant l’audit : remplir un formulaire de connexion, cliquer sur un bouton, attendre un sélecteur. Vous pouvez également utiliser des cookies de session en les passant via l’option headers. Voir la documentation officielle Pa11y pour la liste complète des actions disponibles.

Q : Un score Lighthouse accessibilité de 100 garantit-il la conformité RGAA 4.1 ?

Non. Lighthouse ne couvre que les violations automatiquement détectables, soit environ 30 à 40% des critères WCAG 2.x. Les critères nécessitant un jugement humain — comme l’adéquation d’un texte alternatif avec le contexte de l’image, la pertinence des intitulés de liens, ou la logique de navigation au clavier dans une application complexe — ne peuvent être évalués que par un audit manuel. Le score 100 est une condition nécessaire mais non suffisante pour la conformité RGAA.

Q : Comment gérer les éléments tiers (widgets de chat, cartes Google Maps, boutons de partage réseaux sociaux) qui génèrent des violations Pa11y ?

Pa11y propose l’option hideElements qui applique un display: none temporaire sur les sélecteurs CSS spécifiés avant l’audit. Cela exclut ces éléments de la vérification. Cette approche est justifiée pour les contenus réellement hors de votre contrôle, à condition de documenter explicitement ces exclusions dans votre déclaration d’accessibilité et d’indiquer que ces éléments tiers ne sont pas audités automatiquement.

Q : Lighthouse CI est-il compatible avec Forgejo (ex-Gitea) ?

Oui, avec quelques ajustements. Forgejo Actions utilise la même syntaxe YAML que GitHub Actions. Les actions actions/checkout et actions/setup-node ont leurs équivalents miroirs sur code.forgejo.org. La fonctionnalité d’annotation des PR via le token GitHub App n’est pas disponible, mais vous pouvez uploader les résultats vers votre propre serveur Lighthouse CI self-hosted (target: "lhci-server" dans la config) ou simplement utiliser temporary-public-storage si vous avez accès à Internet depuis le runner.

Q : Quel est le coût infrastructure pour mettre en place ce pipeline complet ?

Pour une PME utilisant GitHub Actions avec le plan gratuit (2000 minutes/mois), le coût est nul si les audits ne dépassent pas 5 à 10 minutes par PR. Sur Forgejo self-hosted avec un runner sur un VPS à 5 € par mois (1 vCPU, 2 Go RAM), le coût est essentiellement celui du VPS. Pa11y Dashboard avec MongoDB nécessite un VPS légèrement plus dimensionné (2 vCPU, 4 Go RAM), soit environ 10 à 15 € par mois chez des hébergeurs comme Hetzner ou OVH. L’investissement reste très accessible pour une PME sénégalaise ou ivoirienne engagée dans une démarche d’accessibilité sérieuse.

Site réalisé par [ITS] ITSkillsCenter