ToolZen ToolZen
Graphics checker client

Color Contrast Checker

Check foreground/background color contrast ratios and verify WCAG 2.1 AA and AAA accessibility compliance in real time.

Advertisement (Top Banner)

Large text example

Small text example — check readability in different contexts.

contrast ratio
AA Normal text Text < 18pt (min 4.5:1)
AA Large text Text ≥ 18pt or bold (min 3.0:1)
AAA Normal text Optimal standard (min 7.0:1)
AAA Large text Optimal standard (min 4.5:1)
Advertisement (Bottom)

Le rapport de contraste entre deux couleurs est un seul nombre, de 1:1 à 21:1, et les WCAG s'en servent pour décider si un texte est lisible. Noir sur blanc est le maximum, exactement 21:1. Cet outil calcule le rapport et vous dit quels seuils vous franchissez — mais ce nombre mérite plus de scepticisme qu'on ne lui en accorde d'ordinaire.

Quels sont réellement les seuils

Les WCAG 2.x en définissent quatre que vous rencontrerez en pratique. AA exige 4,5:1 pour le texte normal et 3:1 pour le grand texte. AAA relève cela à 7:1 et 4,5:1. AA est le niveau auquel renvoie la plupart des législations, dont l'European Accessibility Act ; AAA est un idéal, et la spécification elle-même ne recommande pas de l'exiger sur un site entier.

« Grand » a une définition précise qui piège beaucoup de monde : 18pt, soit 24px, ou 14pt gras, soit 18,66px. Pas « un titre ». Un titre de 20px est du texte normal pour les WCAG et réclame les 4,5:1 pleins.

Pour ancrer les nombres dans le concret : sur fond blanc, #767676 se situe à 4,54:1 et c'est le gris le plus clair qui franchit AA. #595959 atteint exactement 7:1 pour AAA. Tout ce qui est plus clair que #767676 sur blanc échoue pour le texte courant, ce qui élimine la plupart des gris vers lesquels les designers vont d'instinct.

La formule mesure la luminance, pas la lisibilité

C'est la partie qui vaut d'être comprise, car réussir n'est pas être lisible. Le rapport se calcule à partir de la luminance relative, qui pondère les canaux selon leur contribution à la luminosité perçue : le vert compte pour 0,7152, le rouge pour 0,2126, et le bleu pour seulement 0,0722.

Cette pondération produit un échec précis et démontrable. Le bleu pur #0000FF sur blanc obtient 8,59:1 — confortablement au-delà d'AAA. Quiconque a tenté de lire un paragraphe de texte bleu pur sait que c'est éprouvant : l'œil peine à faire une mise au point nette sur la lumière bleue, et il y a très peu de cônes sensibles au bleu au centre de la rétine. La formule voit une couleur très sombre. Vos yeux en voient une floue. Le test passe et le texte reste mauvais.

La formule est symétrique, la vision humaine non

Voici le défaut qui compte le plus en 2025, maintenant que le mode sombre est partout. Les WCAG 2 traitent la paire de couleurs comme non ordonnée — elles ne savent ni ne se soucient de laquelle est le texte et laquelle le fond. La vision humaine n'est pas aussi neutre.

On peut voir le problème se produire. Le gris #949494 obtient 3,03:1 sur blanc, ce qui échoue à AA pour le texte courant. Le même gris sur noir obtient 6,92:1 et passe haut la main. Même couleur, même formule, verdict radicalement différent — et ce n'est pas parce que le mode sombre serait réellement deux fois plus lisible. Le texte clair sur fond sombre souffre d'halation : les glyphes lumineux débordent dans l'obscurité environnante et les traits fins s'épaississent. La formule n'a aucune notion de cela.

La communauté de l'accessibilité sait depuis des années que le contraste des WCAG 2 est un mauvais modèle de la perception. APCA — Accessible Perceptual Contrast Algorithm — est le remplaçant candidat développé pour les WCAG 3, et il est directionnel : il donne des réponses différentes selon la couleur qui est le texte. Ce n'est pas encore une norme ni ce sur quoi vous serez audité. D'où une position pragmatique : respectez les chiffres des WCAG 2, puisque c'est ce que vise la loi, et ne confondez pas les respecter avec avoir conçu quelque chose de lisible.

L'exigence oubliée : 3:1 pour ce qui n'est pas du texte

Les WCAG 2.1 ont ajouté le critère de succès 1.4.11, et il est constamment manqué. Les éléments non textuels porteurs de sens réclament 3:1 par rapport à leur environnement — la bordure d'un champ de saisie, le contour d'un bouton, un indicateur de focus, les barres d'un graphique, une icône qui est la seule étiquette d'un contrôle.

C'est là qu'un grand nombre de designs par ailleurs soignés échouent à un audit. Cette élégante bordure #E5E7EB autour d'un champ de formulaire donne 1,4:1 contre le blanc. Elle échoue, et elle échoue sur l'élément que l'utilisateur a le plus besoin de trouver. Cet outil vérifie les quatre seuils de texte ; la règle des 3:1 pour le non-texte, c'est à vous de l'appliquer, en mettant la couleur de la bordure et celle du fond dans ces deux champs et en cherchant le 3:1.

Le contraste est nécessaire, pas suffisant

Franchir tous les rapports laisse intact le défaut d'accessibilité le plus courant : véhiculer une information par la seule couleur. Une bordure rouge signifiant « invalide » ne dit rien à quelqu'un qui ne la distingue pas des grises, si bien contrastée soit-elle. Environ un homme sur douze présente une forme de déficience de la vision des couleurs.

La règle : la couleur peut renforcer un message mais ne doit jamais en être le seul porteur. Une erreur a besoin d'une icône ou d'une étiquette textuelle à côté du rouge. Un champ obligatoire a besoin d'un astérisque. Un graphique en courbes a besoin de motifs de traits différents, pas seulement de teintes différentes. C'est un critère distinct — 1.4.1, « Utilisation de la couleur » — et aucun vérificateur de contraste ne vous dira jamais que vous y avez échoué.

Questions fréquentes

Quelque chose est-il envoyé à un serveur ?

Non. Cet outil porte la mention « client » : le rapport est une formule évaluée dans votre onglet. Rien n'est transmis.

Pourquoi mon gris passe-t-il sur fond sombre et échoue-t-il sur fond clair ?

Parce que la relation n'est pas linéaire, et que la formule est symétrique alors que la perception ne l'est pas. #949494 donne 3,03:1 sur blanc et 6,92:1 sur noir — même couleur, plus du double du score. À lire honnêtement, ce nombre vous en dit moins qu'il n'en a l'air. Si vous construisez un thème sombre, testez-le avec de vrais yeux sur un vrai écran à une vraie luminosité, car le rapport vous flattera.

Le texte des espaces réservés doit-il passer ?

Oui. Le texte d'un placeholder est du texte, et il n'existe pas d'exemption. Cela surprend car presque tous les systèmes de design livrent un gris de placeholder qui échoue. À noter séparément : les placeholders ne devraient pas servir d'étiquettes du tout — ils disparaissent dès que l'on tape, emportant le sens du champ avec eux.

Et les boutons désactivés ?

Les contrôles désactivés sont explicitement exemptés des exigences de contraste : un bouton grisé a donc le droit d'échouer. C'est une licence à utiliser avec précaution : « autorisé à être illisible » n'est pas « doit être illisible », et un utilisateur doit tout de même pouvoir voir que le contrôle existe et comprendre pourquoi il est indisponible.

Me faut-il AA ou AAA ?

AA, en pratique. C'est ce à quoi renvoie la législation sur l'accessibilité, ce que vérifient les audits, et ce que la spécification elle-même traite comme objectif général. AAA vaut la peine sur les textes longs de lecture, là où il ne coûte rien, mais la spécification dit explicitement qu'il n'est pas requis pour des sites entiers — en partie parce qu'à 7:1 la palette qu'il vous reste pour concevoir est très réduite.