Score d'accessibilité Lighthouse

Ce que vérifie ce contrôle

Exécute l’audit d’accessibilité Lighthouse (un sous-ensemble organisé des règles axe-core) sur la page et rapporte le score pondéré. MetricSpot fait échouer le contrôle en dessous de 90.

Pourquoi c’est important

Le score est un signal grossier mais honnête. Lighthouse ne détecte que les problèmes qu’un parseur statique peut vérifier — environ un tiers de WCAG. Tout ce qu’il signale est presque toujours réel, pas un faux positif.

Des utilisateurs réels sont exclus. Environ 1 visiteur sur 5 utilise des technologies d’assistance à un moment ou à un autre : lecteurs d’écran, navigation au clavier uniquement, modes à fort contraste, contrôle vocal. Une page avec un score d’accessibilité de 60 sera inutilisable pour la plupart d’entre eux.
Exposition juridique. Dans l’UE, l’Acte européen sur l’accessibilité s’applique aux sites commerciaux grand public depuis juin 2025. Aux États-Unis, le DOJ a déclaré explicitement que l’ADA Titre III couvre les sites web. Les sites au score insuffisant sont une cible fréquente de procès opportunistes.
SEO et IA. Les signaux d’expérience utilisateur de Google incluent des métriques proches de l’accessibilité. Les robots IA parsent avec le même arbre DOM que les lecteurs d’écran — une sémantique cassée nuit à l’extraction.

Comment le corriger

Ouvrez Lighthouse (Chrome DevTools → onglet Lighthouse → Accessibility) et exécutez-le sur l’URL en échec. Le rapport liste chaque audit en échec groupé par gravité, avec les nœuds DOM fautifs surlignés.

Concentrez-vous d’abord sur les éléments les plus pondérés — Lighthouse pondère les audits par impact, pas par nombre :

Contraste des couleurs (color-contrast) — texte ≥ 4.5:1, grand texte ≥ 3:1. Utilisez un outil comme Stark ou l’indicateur de contraste des DevTools.
Texte alternatif des images (image-alt) — chaque <img> a besoin d’un attribut alt, même vide pour les images décoratives. Voir Texte alternatif des images.
Libellés de formulaire (label) — chaque input a besoin d’un <label for="…"> explicite. Voir Étiquettes de champs de formulaire.
Langue du document (html-has-lang) — <html lang="fr"> sur la racine. Voir Déclarer la langue de la page.
Texte des liens (link-name) — pas de « cliquez ici », pas de <a> vide. Voir Texte de lien descriptif.

Exécutez axe-core en CI pour attraper les régressions :

bun add -d @axe-core/playwright

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("la page d'accueil est accessible", async ({ page }) => {
  await page.goto("/");
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

Contrôles manuels que Lighthouse ne peut pas faire. Parcourez la page au clavier de haut en bas — l’ordre de focus est-il logique ? L’anneau de focus est-il visible ? Activez VoiceOver (Cmd+F5 sur macOS) ou NVDA (Windows) et lisez une page d’un bout à l’autre. Lighthouse 100 est un plancher, pas un plafond.

Questions fréquentes

Pourquoi mon score était-il si différent à la relance ?

Lighthouse s’exécute dans une instance Chrome headless avec un CPU bridé. Le bruit réseau, les scripts publicitaires et le timing de la bannière de consentement peuvent décaler le score de 5 à 10 points. Lancez trois fois et prenez la médiane ; considérez la tendance, pas la valeur ponctuelle, comme la vérité.

Lighthouse est à 100 — c’est terminé ?

Non. Lighthouse audite environ 30 % de WCAG. Les 70 % restants (ordre de lecture logique, flux de récupération d’erreur, gestion du focus, signification véhiculée par la couleur seule) requièrent une revue manuelle. Un score de 100 signifie que la base automatisée est propre ; faites la revue manuelle par-dessus.

D’où vient le score dans l’audit ?

MetricSpot appelle le moteur Lighthouse pendant l’audit et stocke le score. Si l’exécution échoue (la page est derrière un login, bloque les navigateurs headless ou expire) vous verrez à la place un résultat séparé Accessibilité Lighthouse indisponible.