Comment vérifier le contraste des couleurs pour la conformité WCAG

Pour vérifier le contraste des couleurs selon les WCAG, comparez la luminance relative du texte au premier plan et celle de son arrière-plan, puis confirmez que le ratio obtenu atteint le seuil correspondant au type d’élément : au niveau AA, cela signifie 4,5:1 pour le texte normal, 3:1 pour le texte de grande taille et 3:1 pour les éléments d’interface non textuels.

La plupart d’entre nous l’apprennent à leurs dépens, en livrant une étiquette gris clair qui paraissait convenable sur notre propre écran et qui a échoué à l’audit deux sprints plus tard. Ce calcul ne se fait pas à la main : un outil de vérification le réalise à partir de deux valeurs hexadécimales en quelques secondes. Ce guide vous donne les seuils exacts, les méthodes les plus rapides pour mesurer un ratio, les erreurs qui piègent la plupart des équipes, et les règles qui vont au-delà du corps de texte pour englober les composants d’interface, les indicateurs de focus et la signification véhiculée par la couleur.

Quel ratio de contraste les WCAG exigent-elles ?

Le ratio de contraste mesure l’écart de luminance entre deux couleurs. Le plancher est de 1:1, ce que l’on obtient lorsque le premier plan et l’arrière-plan sont de la même couleur, et le plafond de 21:1, du noir sur du blanc. Les WCAG le calculent selon la formule (L1 + 0,05) / (L2 + 0,05), où L1 et L2 correspondent à la luminance relative de la couleur la plus clair et de la plus foncée. Voici les seuils que tout outil de vérification applique :

Au niveau AA, cela signifie 4,5:1 pour le texte normal et 3:1 pour le texte de grande taille ; le niveau AAA porte ce même couple à 7:1 et 4,5:1. Ce qui compte comme « grande taille » est une affaire de dimension et de graisse : 18 pt (environ 24 px) et plus, ou 14 pt (environ 18,66 px) et plus si le texte est en gras. Le vérificateur de contraste WebAIM évalue précisément par rapport à ces seuils. Un seul critère de décision couvre la plupart des cas : le texte est-il de grande taille ? → 3:1 ; sinon → 4,5:1.

Un mythe qu’il convient d’enterrer : les WCAG 2.2, publiées en octobre 2023, ont ajouté des recommandations sur l’apparence du focus mais n’ont pas touché aux minimums de contraste. Les versions ultérieures ne font qu’ajouter des critères de succès plutôt que de réécrire ceux déjà en place, à la seule exception du critère 4.1.1 Analyse syntaxique. Les valeurs 4,5:1 / 3:1 / 7:1 sont donc restées stables à travers les versions 2.0, 2.1 et 2.2. Le contraste insuffisant demeure le défaut d’accessibilité le plus répandu sur le web. Le rapport WebAIM Million 2026 a relevé du texte à faible contraste sur 83,9 % des pages d’accueil du premier million de sites.

Comment vérifier le contraste des couleurs ?

Le flux de travail le plus rapide est le suivant : récupérez les deux valeurs hexadécimales telles qu’elles sont rendues, collez-les dans un vérificateur, lisez le verdict réussite/échec. Prélevez la couleur rendue, et non la valeur figurant dans votre fichier de conception : les superpositions, les dégradés et la transparence modifient ce que l’utilisateur voit réellement.

• Vérificateur de contraste WebAIM : collez les valeurs hexadécimales du premier plan et de l’arrière-plan. Vous obtenez le ratio ainsi que cinq verdicts, puisque le texte normal et le texte de grande taille sont chacun évalués aux niveaux AA et AAA, et que les éléments non textuels ont leur propre ligne AA. Si la paire est insuffisante, les curseurs de luminosité (Lightness) vous permettent d’ajuster l’une ou l’autre couleur jusqu’à ce qu’elle passe, comme le montre le tutoriel WebAIM consacré à l’outil.
• TPGi Colour Contrast Analyser : une application de bureau pour Windows et macOS. Sélectionnez l’une ou l’autre couleur directement à l’écran grâce à ses pipettes, saisissez les valeurs en hexadécimal, RGB, HSV ou HSL, définissez une valeur alpha sur le premier plan, et faites glisser les curseurs jusqu’à ce qu’une paire non conforme devienne conforme. L’outil propose également un aperçu de vos couleurs selon huit réglages de déficience visuelle.
• Chrome DevTools : inspectez l’élément, ouvrez le Color Picker depuis le nuancier situé à côté de sa déclaration color, puis développez la section Contrast ratio. L’outil indique si la paire satisfait les niveaux AA et AAA, propose un bouton Use suggested color qui applique une valeur conforme, et trace les seuils AA et AAA sous forme de lignes dans l’aperçu des nuances, ce qui vous permet de faire glisser le sélecteur en dessous manuellement.
• Firefox : ouvrez les DevTools → le panneau Accessibilité → sélectionnez un nœud → lisez son contraste et le verdict réussite/échec.

Pour les audits de pages entières, exécutez WAVE, axe DevTools ou Lighthouse. WAVE lit les couleurs de texte et d’arrière-plan dans vos styles et détecte la majorité du corps de texte situé sous le seuil AA de 4,5:1, en appliquant le seuil inférieur de 3:1 au texte de grande taille. Ce qu’il ne peut pas évaluer, c’est le texte sur images, la composition avec canal alpha, ou les états de survol et de focus : vérifiez donc manuellement les composants importants.

Échecs de contraste courants et comment les corriger

La plupart des échecs se réduisent à une poignée de récidivistes, avec des correctifs rapides et vérifiables.

Texte gris clair sur blanc. #767676 sur blanc est le gris le plus clair qui satisfait encore le niveau AA avec 4,5:1, alors que #999 n’atteint que 2,85:1 et échoue. Assombrissez le corps de texte jusqu’à #595959, qui atteint exactement 7:1 et satisfait à la fois AA et AAA.

/* FAIL: ~2.85:1 */  color: #999999; background: #fff;
/* PASS: 7:1 */      color: #595959; background: #fff;

Texte des champs d’invite (placeholder). Définir les placeholders à 40–50 % d’opacité est la cause habituelle d’un échec au critère 1.4.3, car l’arrière-plan transparaît et fait chuter le ratio sous 4,5:1. Attribuez-leur plutôt une véritable valeur hexadécimale de #767676 ou plus foncée. Et utilisez un <label> persistant pour tout ce que l’utilisateur doit lire, puisque les placeholders disparaissent dès la saisie.

Liens signalés par la couleur seule. Ajoutez text-decoration: underline afin que le lien ne se distingue pas uniquement par la teinte. Si vous supprimez le soulignement, vous vous exposez à une exigence supplémentaire : le texte du lien doit alors atteindre 3:1 par rapport au corps de texte environnant, en plus du 4,5:1 que les deux couleurs doivent respecter face à l’arrière-plan.

Texte sur images. La luminance varie d’une zone à l’autre d’une photo : le même texte est donc conforme à un endroit et non conforme à un autre. Ajoutez un voile semi-transparent :

.hero {
  background:
    linear-gradient(rgba(0,0,0,.6), rgba(0,0,0,.6)),
    url("hero.jpg");
}
.hero-text { color: #fff; } /* now has guaranteed contrast */

Au-delà du texte : composants d’interface, focus et usage de la couleur

Les règles de contraste s’étendent bien au-delà des paragraphes. Le critère de succès 1.4.11 fixe un plancher de 3:1 pour les contrôles et pour les parties d’un graphique dont le lecteur a besoin pour suivre le contenu, mesuré par rapport à la couleur qui se trouve immédiatement à côté. Les bordures de champs de saisie, les contours de boutons, les icônes porteuses de sens et les séries de graphiques entrent tous dans ce cadre. Les états comptent également, avec une nuance : l’état par défaut doit atteindre 3:1 et aucun état ne doit faire passer le composant en dessous de ce seuil, mais un effet de survol ajouté par-dessus n’est pas lui-même soumis à l’exigence de 3:1, tant qu’il n’annule pas le contraste dont le contrôle bénéficiait déjà.

Les indicateurs de focus sont l’endroit où les numéros de critères se brouillent : cartographiez-les donc avec précision. La visibilité du focus relève de 2.4.7 Visibilité du focus. Le contraste de 3:1 exigé pour l’indicateur provient de 1.4.11 Contraste du contenu non textuel, et non de 2.4.11, qui correspond à Focus non masqué (minimum) et concerne les superpositions qui masquent un élément ayant le focus. Le critère de niveau AAA 2.4.13 Apparence du focus ajoute par-dessus des exigences de taille minimale et de contraste entre états.

Enfin, le critère WCAG 1.4.1 Utilisation de la couleur (niveau A) impose que la couleur seule ne véhicule jamais une signification : associez un statut rouge/vert à une étiquette textuelle ou à une icône, et soulignez les liens. Une exemption à retenir : les composants inactifs (désactivés) sont exclus des minimums de contraste, textuels comme non textuels, mais les maintenir lisibles reste une meilleure expérience utilisateur que de les griser jusqu’à l’invisibilité.

Intégrez le contraste à votre flux de travail

Détectez les problèmes de contraste avant la mise en production. Vérifiez dès la phase de conception avec un plugin comme Stark dans Figma, puis encodez les résultats dans une couche de tokens qui annote le ratio de chaque couleur :

:root {
  --text-primary:   #171717; /* 18.8:1 — headings, body */
  --text-secondary: #595959; /* 7:1  — secondary text */
  --border-input:   #767676; /* 4.5:1 — meets 1.4.11 */
  --border-subtle:  #d4d4d4; /* 1.6:1 — decorative only */
}

Le corps de texte doit se situer nettement au-dessus du minimum (10:1 et plus est confortable), tandis que le texte secondaire et le texte de grande taille peuvent se maintenir à 4,5:1 et les bordures à 3:1. Testez le rendu pour le daltonisme via Chrome DevTools → Rendering → Emulate vision deficiencies afin de confirmer que le sens subsiste sans la couleur. Ensuite, automatisez : exécutez axe ou Lighthouse dans votre CI pour qu’une régression de contraste fasse échouer le build au lieu d’atteindre les utilisateurs. Et accordez au mode sombre son propre passage en revue : inverser la luminance casse des ratios qui étaient conformes en mode clair, il faut donc recalculer chaque token pour chaque thème.

Le contraste est l’un des problèmes d’accessibilité les moins coûteux à corriger et l’un des plus faciles à prévenir. Choisissez un vérificateur, définissez vos seuils sous forme de tokens, branchez une analyse automatisée dans votre CI, et les échecs décrits ci-dessus cesseront de partir en production. Commencez dès aujourd’hui par auditer votre corps de texte et vos styles de focus actuels face aux seuils de 4,5:1 et 3:1.

FAQ

Le contraste WCAG mesure-t-il la teinte et la saturation, ou seulement la luminosité ?

Le ratio de contraste ne mesure que la luminance relative, c'est-à-dire la luminosité perçue de chaque couleur, et non la teinte ou la saturation. C'est la raison pour laquelle deux couleurs qui paraissent différentes, comme du texte rouge sur un arrière-plan vert, peuvent malgré tout échouer si leurs luminances sont proches. Le ratio est calculé selon la formule (L1 + 0,05) / (L2 + 0,05) à partir des valeurs de luminance de la couleur la plus claire et de la plus foncée ; la signification véhiculée par la seule teinte est donc régie séparément par le critère WCAG 1.4.1 Utilisation de la couleur.

Quelle est la différence entre le critère WCAG 1.4.11 Contraste du contenu non textuel et le critère 2.4.11 Focus non masqué ?

Le critère WCAG 1.4.11 Contraste du contenu non textuel (niveau AA) exige un ratio de contraste de 3:1 pour les composants d'interface et les graphiques porteurs de sens, y compris l'indicateur de focus, par rapport aux couleurs adjacentes. Le critère WCAG 2.4.11 Focus non masqué (minimum, niveau AA), nouveauté des WCAG 2.2, n'a aucun rapport avec le contraste : il exige qu'un élément ayant le focus ne soit pas entièrement masqué par du contenu créé par l'auteur, comme des en-têtes collants ou des superpositions. Le contraste relève de 1.4.11 ; la visibilité vis-à-vis des obstructions relève de 2.4.11.

Pourquoi le même texte est-il conforme dans mon fichier de conception mais non conforme dans le navigateur ?

Les plugins des outils de conception vérifient les valeurs de couleur plates que vous attribuez, alors que les navigateurs composent le résultat rendu. L'opacité, les superpositions semi-transparentes, les dégradés, les images d'arrière-plan et les modes de fusion modifient tous la luminance réelle que perçoit l'utilisateur. Un placeholder défini à 50 % d'opacité ou du texte placé sur une photo peuvent être conformes dans la maquette et échouer une fois rendus. Prélevez toujours la valeur hexadécimale rendue depuis les DevTools ou à l'aide d'une pipette à l'écran, plutôt que de faire confiance à la couleur source.

Les boutons désactivés et les contrôles inactifs doivent-ils respecter les minimums de contraste des WCAG ?

Non. Le critère WCAG 1.4.3 Contraste (minimum) exempte explicitement les composants d'interface utilisateur inactifs, et les éléments désactivés sont également exclus de l'exigence de contraste non textuel du critère 1.4.11. Cela signifie qu'un bouton désactivé grisé n'entraînera pas d'échec lors d'un audit de contraste automatisé. Maintenir la lisibilité des contrôles désactivés reste préférable en matière d'ergonomie, car des contrôles totalement invisibles déroutent les utilisateurs, mais il ne s'agit pas d'une exigence de conformité WCAG pour cet état.