Échecs d'accessibilité Lighthouse

Ce que vérifie ce contrôle

Compte combien d’audits d’accessibilité Lighthouse ont échoué sur la page. Lighthouse exécute axe-core sous le capot et regroupe les résultats en pass/fail/manual. Cette règle remonte le nombre de fail et les liste — la jauge du score d’accessibilité Lighthouse est le chiffre vedette, cette règle est la liste à faire.

Coupables typiques que MetricSpot remonte :

• color-contrast — texte sous le ratio de contraste AA de 4,5:1.
• image-alt — <img> sans alt (différent de la qualité du texte alternatif des images, qui note le caractère significatif).
• link-name / button-name — éléments interactifs sans nom accessible (les boutons à icône seule sont les coupables habituels).
• label — contrôles de formulaire sans <label> associé.
• html-has-lang / html-lang-valid — couverts par déclarer la langue de la page.
• document-title — <title> vide ou manquant.
• aria-* — rôles invalides, attributs requis manquants, ou aria-hidden sur des éléments focusables.
• list / listitem — <li> en dehors d’un parent <ul>/<ol>.

Pourquoi c’est important

Les échecs Lighthouse sont la moitié corrigeable de l’accessibilité. Chaque audit de cette liste est quelque chose qu’un agent de build peut vérifier mécaniquement — aucun jugement humain requis. Ce sont aussi les audits les plus susceptibles d’apparaître dans une plainte juridique : le contraste et les labels de formulaire manquants sont les deux problèmes les plus cités dans les procès ADA sur l’accessibilité web aux États-Unis, et l’Acte européen sur l’accessibilité (en vigueur depuis juin 2025) lit la même checklist.

Ramener ce compteur à zéro ne rendra pas un site totalement conforme WCAG — environ un tiers des critères WCAG 2.1 AA nécessitent une revue manuelle — mais cela supprime les objections les moins coûteuses à corriger.

Comment corriger

Lisez les échecs dans l’ordre. Chaque échec Lighthouse inclut un extrait « Failing elements » — c’est votre point de départ.

Consulter la liste par audit :

• Lighthouse CLI / DevTools — lancez un audit, descendez jusqu’à « Accessibility », cliquez sur chaque entrée rouge pour la liste des éléments en échec.
• PageSpeed Insights — pagespeed.web.dev/?url=<votre-url> renvoie les mêmes audits avec les sélecteurs d’éléments.
• DevTools → panneau Issues — Chrome 109+ remonte les problèmes axe-core en direct pendant la navigation.

Câblez-le dans la CI. Ne dépendez pas d’humains qui cliquent sur Lighthouse. Ajoutez axe-core à votre suite e2e :

bun add -D @axe-core/playwright axe-playwright

// e2e/a11y.spec.ts
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("home has no detectable a11y violations", async ({ page }) => {
  await page.goto("/");
  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag21aa"])
    .analyze();
  expect(results.violations).toEqual([]);
});

Pour les builds React/Next/Astro, ajoutez aussi eslint-plugin-jsx-a11y pour attraper les évidences au lint.

Le top 5 des correctifs d’une ligne :

Échec	Correctif
color-contrast	Renforcez le premier plan ou l’arrière-plan jusqu’à dépasser 4,5:1 (3:1 pour le texte 18pt+). Utilisez le sélecteur de couleur de DevTools — il affiche le ratio en direct.
image-alt	Ajoutez alt="...". Pour les images purement décoratives, utilisez alt="" (vide, pas absent). Voir texte alternatif des images.
button-name	Les <button> à icône seule ont besoin de aria-label="Fermer le menu". Les SVG à l’intérieur ont besoin de aria-hidden="true".
link-name	Comme les boutons. Enveloppez les liens à icône avec un texte descriptif ou aria-label. Voir texte de lien descriptif.
label	Enveloppez <input> dans <label>, ou utilisez <label for="id"> + id="id". Voir étiquettes de champs de formulaire.

Si le score est n/a au lieu d’un nombre, voir accessibilité Lighthouse indisponible — l’audit ne s’est pas exécuté.

Questions fréquentes

Corriger chaque échec me mènera-t-il à 100 ?

Vous atterrirez généralement dans les 90 hauts. Le score d’accessibilité de Lighthouse est pondéré mais pas linéaire — color-contrast est lourd, d’autres sont légers. Les points restants viennent souvent de vérifications manuelles (ordre du focus, narration par lecteur d’écran) que l’audit automatisé liste comme « Éléments supplémentaires à vérifier manuellement ».

Puis-je supprimer des audits avec lesquels je ne suis pas d’accord ?

Oui, via le tableau skipAudits de la configuration Lighthouse, mais réfléchissez bien avant de supprimer. Le faux positif courant est color-contrast sur les bannières héro texte-sur-image — corrigez le contraste (ajoutez une superposition ou un fond plein) plutôt que d’ignorer l’audit.

En quoi cela diffère-t-il d’axe-core dans DevTools ?

Pas vraiment. Lighthouse embarque axe-core et exécute un sous-ensemble de ses règles. L’extension axe pour DevTools exécute l’ensemble complet, donc vous pouvez voir plus de problèmes là — ces extras sont généralement tagués best-practice et non requis par WCAG.