Contraste WCAG : comment rendre les couleurs accessibles ?

Un texte gris clair sur fond blanc peut sembler élégant sur une maquette et devenir pénible à lire sur un téléphone en plein soleil. Un bouton dont seul le changement de couleur indique l’état peut être difficile à comprendre pour une personne qui distingue mal certaines teintes. Une bordure de champ presque invisible peut rendre un formulaire beaucoup plus compliqué à utiliser.

Le contraste n’est donc pas une préférence esthétique. C’est une composante de l’accessibilité visuelle.

Les WCAG — Web Content Accessibility Guidelines — fournissent des critères permettant d’évaluer certaines de ces situations. Elles ne dictent pas une palette universelle et ne demandent pas que tous les sites soient noirs et blancs. Elles cherchent à garantir que le contenu et les éléments nécessaires à l’utilisation d’une interface restent suffisamment perceptibles.

Cet article explique comment interpréter les principaux seuils de contraste, comment éviter les erreurs courantes et surtout comment passer d’un simple résultat « AA / AAA » à une vraie décision de design.

Si vous souhaitez d’abord revoir la manière dont une couleur est représentée, commencez par RGB, HEX ou HSL : quelle notation choisir ?. Si vous partez d’une photographie ou d’une identité visuelle, Créer une palette de couleurs à partir d’une image constitue également une bonne étape préalable.

Le contraste WCAG en une minute

Pour le texte, les seuils que l’on rencontre le plus souvent sont :

Situation	Niveau AA	Niveau AAA
Texte courant	4,5:1	7:1
Texte de grande taille	3:1	4,5:1

Pour certains éléments non textuels nécessaires à l’utilisation ou à la compréhension de l’interface, le critère WCAG 1.4.11 utilise un seuil de 3:1 par rapport aux couleurs adjacentes pertinentes.

Mais ces nombres ne racontent qu’une partie de l’histoire.

Une interface peut afficher un excellent ratio pour son texte principal et rester difficile à utiliser si :

• les états d’erreur reposent uniquement sur le rouge ;
• les liens ne se distinguent du texte que par une couleur insuffisamment différenciée ;
• les bordures de champs sont presque invisibles ;
• un texte est placé sur une photographie très contrastée ;
• un état hover ou focus disparaît ;
• un texte semi-transparent est mesuré comme s’il était opaque.

Le vérificateur de contraste permet de tester rapidement une paire de couleurs. Il faut ensuite replacer ce résultat dans le contexte réel de l’interface.

Qu’est-ce qu’un ratio de contraste ?

Le ratio de contraste compare la luminance relative de deux couleurs.

Le résultat peut aller de :

1:1

lorsque les deux couleurs ont la même luminance, jusqu’à :

21:1

pour le contraste maximal entre noir et blanc.

Ce ratio ne mesure pas directement :

• la différence de teinte ;
• la saturation ;
• la distance HSL ;
• le caractère « joli » d’une combinaison ;
• la qualité globale d’une palette.

Deux couleurs peuvent sembler très différentes parce que l’une est rouge et l’autre verte tout en restant relativement proches en luminance.

C’est précisément pourquoi une évaluation visuelle approximative ne suffit pas.

Pourquoi la lightness HSL ne permet-elle pas de connaître le contraste ?

C’est une confusion fréquente.

Prenons :

hsl(60 100% 50%)

et :

hsl(240 100% 50%)

Les deux couleurs possèdent une lightness HSL de 50%.

Pourtant, un jaune et un bleu ainsi définis n’ont pas du tout la même luminance relative ni la même perception de clarté.

La valeur L de HSL est une composante du modèle HSL ; elle n’est pas la luminance relative utilisée par les WCAG.

Cette différence est détaillée dans RGB, HEX ou HSL : quelle notation choisir ?.

Retenez donc une règle simple :

ne déduisez jamais un ratio WCAG à partir de la seule lightness HSL.

Utilisez un calcul dédié ou le vérificateur de contraste.

Comment le ratio est-il calculé ?

La formule WCAG du ratio de contraste est :

(L1 + 0,05) / (L2 + 0,05)

où :

• L1 est la luminance relative de la couleur la plus claire ;
• L2 est la luminance relative de la couleur la plus sombre.

La luminance relative n’est pas obtenue en additionnant simplement les valeurs RGB.

Les composantes sRGB doivent être interprétées selon la formule définie par les WCAG avant d’être pondérées.

Pour un usage quotidien, effectuer le calcul à la main n’apporte généralement rien. L’intérêt de connaître la formule est surtout de comprendre que le contraste repose sur une mesure précise, pas sur une estimation subjective.

Le convertisseur de couleurs peut vous aider à manipuler les représentations HEX, RGB ou HSL, tandis que le vérificateur de contraste répond directement à la question du ratio.

Que signifie réellement 4,5:1 ?

Le seuil 4,5:1 correspond au critère WCAG 2.2 1.4.3 Contraste (minimum) pour le texte courant au niveau AA.

Cela signifie qu’une combinaison de texte et d’arrière-plan destinée à du texte normal doit atteindre au moins ce ratio, sauf exceptions prévues par le critère.

Par exemple, si votre texte est :

#64748b

sur :

#ffffff

il ne suffit pas de dire que le gris « semble assez foncé ».

Il faut mesurer la combinaison réelle.

Si le résultat est inférieur au seuil applicable, vous pouvez :

• assombrir le texte ;
• modifier le fond ;
• choisir une autre couleur ;
• revoir le rôle de cette couleur dans la palette.

Le but n’est pas de « gagner le test », mais de rendre le contenu plus facilement perceptible.

Qu’est-ce qu’un texte de grande taille ?

Les WCAG accordent un seuil inférieur au texte considéré comme suffisamment grand.

Dans la terminologie du critère, le texte de grande taille correspond à au moins :

• 18 points en graisse normale ;
• ou 14 points en gras.

Dans les équivalences CSS couramment utilisées par le W3C, cela correspond approximativement à :

• 24 px pour du texte normal ;
• environ 18,5 px pour du texte gras.

Pour ce texte, le niveau AA demande 3:1 au lieu de 4,5:1.

Mais cette exception ne doit pas devenir une stratégie de design.

Augmenter artificiellement une police uniquement pour faire passer une couleur médiocre n’est généralement pas une bonne approche. Taille, hiérarchie et contraste doivent répondre ensemble au besoin de lecture.

Niveau AA et niveau AAA : quelle différence ?

Pour le texte, deux critères sont souvent comparés.

Niveau AA — contraste minimum

Le critère 1.4.3 demande :

• 4,5:1 pour le texte courant ;
• 3:1 pour le texte de grande taille.

Niveau AAA — contraste renforcé

Le critère 1.4.6 demande :

• 7:1 pour le texte courant ;
• 4,5:1 pour le texte de grande taille.

AAA représente donc une exigence renforcée.

Mais il serait trompeur de présenter l’accessibilité comme un simple classement :

AAA = parfait
AA = moyen
échec = inaccessible

Les WCAG comportent de nombreux critères qui ne concernent pas le contraste. Une interface peut afficher des ratios très élevés et rester inaccessible pour d’autres raisons.

Inversement, viser systématiquement le contraste maximal peut dégrader inutilement certaines hiérarchies visuelles.

L’objectif est de satisfaire les critères applicables et de construire une expérience réellement utilisable.

Faut-il toujours viser AAA ?

Pas nécessairement pour chaque élément d’un produit.

Un contraste plus élevé peut améliorer la lecture, notamment dans des conditions difficiles, mais AAA n’est pas simplement un « mode premium » que toute combinaison devrait atteindre.

Il faut considérer :

• la fonction du contenu ;
• le public ;
• la taille du texte ;
• le contexte d’utilisation ;
• les autres exigences d’accessibilité ;
• la cohérence de l’interface.

Pour le corps de texte, choisir une combinaison confortable qui dépasse largement 4,5:1 est souvent une excellente décision.

Pour des éléments secondaires, le contexte peut être différent, tout en respectant les exigences applicables.

Le noir sur blanc est-il toujours la meilleure solution ?

Non.

Le noir #000000 sur blanc #ffffff offre un ratio maximal de 21:1.

Cela ne signifie pas que toute interface devrait utiliser uniquement cette combinaison.

Une palette peut conserver :

• une couleur de marque ;
• plusieurs surfaces ;
• des textes secondaires ;
• des états interactifs ;
• des accents.

L’accessibilité ne demande pas de supprimer la couleur.

Elle demande de l’utiliser sans sacrifier la perception de l’information.

L’article Créer une palette de couleurs à partir d’une image explique justement comment passer d’un ensemble de couleurs à des rôles fonctionnels. Le contraste intervient ensuite pour valider les combinaisons réellement utilisées.

Une couleur est-elle accessible en elle-même ?

Non.

Dire :

« ce bleu est accessible »

n’a pas vraiment de sens sans contexte.

Une couleur peut avoir :

• un excellent contraste sur blanc ;
• un mauvais contraste sur gris clair ;
• un bon contraste comme fond avec du texte blanc ;
• un mauvais contraste comme texte sur noir.

L’accessibilité concerne donc une relation entre couleurs et usages.

Il vaut mieux dire :

« ce bleu utilisé comme texte sur ce fond blanc atteint le ratio requis pour cet usage ».

Cette manière de raisonner évite beaucoup d’erreurs dans les design systems.

Comment tester une couleur de texte ?

La procédure la plus simple est :

1. identifier la couleur réelle du texte ;
2. identifier la couleur réelle du fond ;
3. tenir compte de la transparence éventuelle ;
4. calculer le ratio ;
5. déterminer le seuil applicable ;
6. vérifier le rendu dans l’interface.

Avec le vérificateur de contraste, vous pouvez tester rapidement deux valeurs.

Si votre palette utilise une autre notation, passez au besoin par le convertisseur de couleurs.

Pourquoi la transparence complique-t-elle le contraste ?

Supposons :

color: rgb(0 0 0 / 50%);

Ce texte n’est pas simplement « du noir avec un ratio plus faible ».

Sa couleur visible dépend du fond.

Sur blanc, il produira une certaine couleur composée.

Sur bleu clair, le résultat sera différent.

Sur une photographie, le résultat peut varier d’un pixel à l’autre.

Il faut donc mesurer la couleur effectivement rendue contre son arrière-plan réel.

La transparence et le canal alpha sont expliqués plus en détail dans Comment une image numérique est-elle construite ?.

Texte sur une image : pourquoi un seul test ne suffit-il pas ?

Une photographie n’a pas une couleur de fond uniforme.

Un texte blanc placé sur un ciel sombre peut présenter un excellent contraste dans une zone et devenir presque invisible devant un nuage clair.

Il faut évaluer les parties de l’image qui se trouvent réellement derrière le texte.

Plusieurs solutions sont possibles :

• déplacer le texte ;
• ajouter une surface opaque ou suffisamment maîtrisée ;
• utiliser un overlay ;
• modifier le cadrage ;
• choisir une image différente ;
• séparer le texte de l’image.

Le simple fait d’ajouter une ombre au texte ne garantit pas que le critère soit satisfait.

Cette question rejoint les choix de préparation et d’usage des images étudiés dans Quelle résolution choisir pour une image ? et, plus tard dans la collection, dans PNG, JPEG, WebP ou AVIF : quel format choisir ?.

Les images de texte sont-elles concernées ?

Oui, le critère de contraste du texte concerne également les images de texte lorsqu’elles entrent dans son champ.

Mais il existe une question plus fondamentale : faut-il utiliser une image pour afficher du texte ?

Dans la plupart des interfaces Web, du vrai texte HTML est préférable car il peut :

• être sélectionné ;
• être agrandi ;
• s’adapter ;
• être lu par les technologies d’assistance ;
• répondre aux préférences utilisateur ;
• être traduit plus facilement.

Les images de texte ont donc des contraintes qui dépassent le seul contraste.

Les logos doivent-ils respecter 4,5:1 ?

Le critère 1.4.3 prévoit notamment une exception pour le texte faisant partie d’un logo ou d’un nom de marque.

Cela ne signifie pas qu’un logo illisible devient soudainement une bonne idée.

Cela signifie simplement que le seuil minimum du critère ne s’applique pas de la même manière à ce cas.

Il faut distinguer :

• ce qui est strictement requis par un critère ;
• ce qui constitue une bonne pratique de lisibilité.

Cette distinction est importante dans tout audit d’accessibilité.

Qu’en est-il des placeholders ?

Un placeholder n’est pas exempté simplement parce qu’il est temporaire ou affiché dans un champ.

Lorsqu’un texte entre dans le champ du critère 1.4.3, son contraste doit être évalué.

C’est un problème fréquent : les placeholders sont volontairement rendus très pâles pour les différencier d’une valeur saisie.

On peut les distinguer autrement tout en conservant une lisibilité suffisante.

Et surtout, un placeholder ne doit pas remplacer un vrai label lorsque celui-ci est nécessaire.

Les boutons doivent-ils avoir un contraste de 4,5:1 ?

Il faut distinguer plusieurs éléments.

Le texte du bouton

Le texte suit les exigences applicables au texte.

La forme ou la limite nécessaire pour identifier le bouton

Selon la manière dont le composant est conçu, le critère 1.4.11 Non-text Contrast peut entrer en jeu.

Il demande un contraste d’au moins 3:1 pour certaines informations visuelles nécessaires à l’identification des composants d’interface et de leurs états, par rapport aux couleurs adjacentes pertinentes.

Un bouton ne se résume donc pas à tester son texte.

Il faut comprendre quelles informations visuelles permettent à l’utilisateur de reconnaître le composant.

Qu’est-ce que le contraste non textuel ?

WCAG 1.4.11 concerne notamment :

• les informations visuelles nécessaires pour identifier des composants d’interface et leurs états ;
• certaines parties de graphiques nécessaires pour comprendre le contenu.

Le seuil est 3:1 par rapport aux couleurs adjacentes concernées.

Cela peut toucher :

• une bordure de champ ;
• une coche ;
• un indicateur ;
• certaines icônes ;
• des segments d’un graphique ;
• des états visuels.

Mais il faut éviter une règle simpliste du type :

« toutes les bordures doivent être à 3:1 ».

Le critère porte sur l’information visuelle nécessaire à l’identification ou à la compréhension.

L’analyse doit donc se faire composant par composant.

Une icône doit-elle toujours avoir 3:1 ?

Non, pas toutes les icônes dans toutes les situations.

Une icône purement décorative n’a pas la même fonction qu’une icône qui constitue à elle seule un bouton.

Si l’icône transmet une information nécessaire ou permet d’identifier une action, son contraste peut devenir essentiel.

Exemple :

[icône poubelle]

Si cette icône est le seul moyen visuel d’identifier l’action « Supprimer », sa perception est importante.

À l’inverse, une petite étoile décorative ajoutée à côté d’un titre déjà explicite n’a pas nécessairement le même statut.

L’accessibilité commence toujours par la question :

quelle information ou quelle action dépend de cet élément visuel ?

Les graphiques doivent-ils respecter le contraste ?

Les éléments graphiques nécessaires à la compréhension peuvent entrer dans le critère 1.4.11.

Mais un graphique accessible ne se résume pas à choisir des couleurs ayant 3:1 entre elles.

Il faut aussi considérer :

• les labels ;
• les légendes ;
• les motifs ;
• les formes ;
• les annotations ;
• la possibilité de comprendre les données sans dépendre uniquement de la couleur.

Une palette très esthétique issue d’une photographie peut être inadaptée à une visualisation de données si plusieurs séries sont difficiles à distinguer.

C’est une des raisons pour lesquelles une palette de couleurs doit être transformée en système fonctionnel avant utilisation.

La couleur peut-elle être le seul moyen d’indiquer une information ?

Le critère WCAG 1.4.1 Utilisation de la couleur demande que la couleur ne soit pas utilisée comme seul moyen visuel de transmettre certaines informations, d’indiquer une action, de demander une réponse ou de distinguer un élément.

Exemple classique :

Les champs en rouge sont obligatoires.

Si seule la couleur permet de savoir quels champs sont concernés, l’information peut être perdue pour certains utilisateurs.

Une meilleure solution peut associer :

• couleur ;
• texte ;
• icône ;
• symbole ;
• libellé.

Par exemple :

Adresse e-mail *

avec un message explicite en cas d’erreur.

Rouge et vert : faut-il les interdire ensemble ?

Non.

Le problème n’est pas l’existence du rouge et du vert.

Le problème apparaît lorsqu’ils constituent le seul moyen de distinguer deux états.

Un tableau pourrait utiliser :

• vert + coche + « Validé » ;
• rouge + croix + « Erreur ».

Même si la perception des teintes varie, l’utilisateur dispose d’autres indices.

Cette stratégie est généralement plus robuste qu’une interface composée uniquement de pastilles colorées.

Comment rendre une erreur de formulaire accessible ?

Une erreur devrait idéalement être identifiable de plusieurs façons.

Par exemple :

• bordure colorée ;
• icône ;
• texte explicite ;
• association programmatique avec le champ ;
• éventuellement résumé d’erreurs.

Pour le volet visuel, vérifiez :

1. le contraste du message ;
2. le contraste des informations graphiques nécessaires ;
3. que la couleur n’est pas le seul indice ;
4. que l’état de focus reste perceptible.

Le contraste est une pièce du système, pas tout le système.

Le focus clavier est-il seulement une question de contraste ?

Non.

Le focus doit d’abord être visible et utilisable.

Selon sa conception, plusieurs critères WCAG peuvent intervenir, dont le contraste non textuel et, dans WCAG 2.2, des critères spécifiques liés à l’apparence ou à l’obscurcissement du focus.

Un simple changement subtil de couleur peut être insuffisant.

Une solution robuste peut combiner :

• contour ;
• épaisseur ;
• décalage ;
• changement de fond ;
• contraste suffisant.

L’utilisateur doit pouvoir suivre sa position dans l’interface.

Le hover suffit-il pour indiquer qu’un élément est interactif ?

Non.

Le hover n’existe pas de la même manière sur un écran tactile et ne remplace pas les autres indices d’interactivité.

Un lien ou un bouton doit être compréhensible dans son état normal.

Le contraste des états hover, focus, active, disabled doit ensuite être évalué selon leur fonction et les critères applicables.

Une interface ne doit pas devenir accessible uniquement lorsque la souris passe dessus.

Les éléments désactivés sont-ils soumis aux mêmes exigences ?

Les critères WCAG de contraste comportent des exceptions pour certains composants inactifs.

Mais une exception normative ne signifie pas qu’il faut rendre volontairement un bouton désactivé presque invisible.

L’utilisateur peut avoir besoin de comprendre :

• que l’action existe ;
• qu’elle est indisponible ;
• pourquoi elle est indisponible.

Une bonne interface cherche donc un équilibre entre distinction de l’état et lisibilité.

Pourquoi « ce gris est utilisé partout » n’est pas une justification

Les interfaces modernes utilisent souvent plusieurs niveaux de texte :

• principal ;
• secondaire ;
• tertiaire ;
• désactivé ;
• placeholder ;
• métadonnées.

Le risque est d’éclaircir progressivement le gris jusqu’à obtenir un texte très discret mais difficile à lire.

Chaque niveau textuel réel doit être évalué selon son usage.

La hiérarchie visuelle peut être créée par :

• taille ;
• graisse ;
• espacement ;
• position ;
• couleur ;
• typographie.

Le contraste n’a pas besoin de porter seul toute la hiérarchie.

Comment corriger une couleur qui échoue de peu ?

Supposons qu’une couleur de marque utilisée comme texte sur blanc n’atteigne pas le seuil nécessaire.

Plusieurs stratégies sont possibles.

Assombrir la couleur

C’est souvent la solution la plus simple.

Modifier le fond

Une surface légèrement différente peut créer un meilleur couple.

Changer le rôle de la couleur

La couleur peut rester utilisée comme accent, bordure décorative ou fond, tandis qu’une variante plus sombre sert au texte.

Ajouter une variante accessible à la palette

Par exemple :

--brand-500: ...;
--brand-700: ...;

La première peut servir aux éléments décoratifs, la seconde au texte.

Le convertisseur de couleurs aide à explorer les valeurs, mais le résultat final doit toujours être vérifié avec le vérificateur de contraste.

Pourquoi ne faut-il pas modifier uniquement la lightness HSL ?

Parce qu’une variation identique de lightness ne produit pas le même changement de luminance pour toutes les teintes.

Vous pouvez utiliser HSL pour expérimenter, mais ne supposez pas :

-10 % de lightness = contraste suffisant

Mesurez après chaque modification.

Pour des systèmes colorimétriques plus avancés, des espaces perceptuels modernes peuvent faciliter la construction de gammes, mais ils ne remplacent pas la validation des couples réellement utilisés.

Comment intégrer le contraste dans un design system ?

Le meilleur moment pour résoudre les problèmes de contraste n’est pas à la fin du développement.

Il est préférable de les traiter au niveau des tokens.

Par exemple :

:root {
  --color-text: #0f172a;
  --color-text-muted: #475569;
  --color-surface: #ffffff;
  --color-primary: #1d4ed8;
  --color-focus: #2563eb;
}

Chaque token possède un rôle.

On peut alors documenter les combinaisons autorisées :

text / surface
text-muted / surface
primary / surface
surface / primary

et tester ces couples.

Cette méthode évite qu’un développeur choisisse arbitrairement une nuance à chaque composant.

Faut-il tester toutes les couleurs d’une palette entre elles ?

Pas nécessairement.

Une palette de dix couleurs possède de nombreuses combinaisons possibles, mais votre interface n’utilise probablement pas toutes ces paires.

Testez d’abord les couples réels :

• texte principal / fond ;
• texte secondaire / fond ;
• lien / fond ;
• bouton / texte ;
• message d’erreur / fond ;
• badge / texte ;
• focus / couleurs adjacentes ;
• icônes fonctionnelles / fond.

L’objectif n’est pas de construire une matrice parfaite de toutes les couleurs imaginables, mais de valider les usages prévus.

Exemple : texte secondaire sur fond blanc

Vous souhaitez créer un texte secondaire plus discret.

Au lieu de choisir arbitrairement un gris très clair :

1. partez de votre couleur de texte principale ;
2. sélectionnez une variante visuellement secondaire ;
3. testez-la sur le fond réel ;
4. vérifiez qu’elle atteint le seuil applicable ;
5. contrôlez le rendu sur différents écrans.

Si la différence avec le texte principal est trop faible, utilisez aussi d’autres moyens de hiérarchie : taille, graisse, espacement ou position.

Exemple : bouton principal

Un bouton bleu contient du texte blanc.

Il faut vérifier au minimum le couple :

texte blanc / fond bleu

Puis examiner le composant lui-même :

• est-il identifiable ?
• ses états sont-ils perceptibles ?
• le focus est-il visible ?
• l’état désactivé reste-t-il compréhensible ?

Un seul badge « AA » dans un outil de contraste ne valide pas tout le bouton.

Exemple : badge d’état

Vous avez :

• vert pour « réussi » ;
• orange pour « attention » ;
• rouge pour « erreur ».

Si le badge contient également les mots :

Réussi
Attention
Erreur

l’information ne dépend plus uniquement de la teinte.

Il faut ensuite vérifier le contraste du texte et, selon la conception, des éléments visuels nécessaires.

Cette combinaison de couleur + libellé est beaucoup plus robuste.

Exemple : texte sur photographie

Une bannière affiche un titre blanc sur une photographie.

La zone derrière le titre varie du bleu foncé au blanc.

Tester le blanc contre « la couleur moyenne » de l’image n’a aucun sens.

Il faut évaluer la zone réelle derrière les glyphes.

Une solution solide consiste souvent à maîtriser l’arrière-plan du texte plutôt que d’espérer que toutes les photographies fonctionneront.

Par exemple :

• panneau semi-opaque suffisamment contrôlé ;
• dégradé conçu pour stabiliser la zone ;
• position réservée dans le cadrage.

Mais la composition finale doit être testée, car la transparence change la couleur réellement obtenue.

Exemple : graphique avec plusieurs séries

Une palette contient bleu, violet, vert et turquoise.

Les quatre couleurs sont agréables ensemble.

Pourtant, deux séries peuvent être difficiles à distinguer.

Ajoutez éventuellement :

• marqueurs ;
• styles de ligne ;
• labels directs ;
• motifs.

Le contraste est important, mais l’information ne doit pas reposer uniquement sur la couleur.

Comment auditer rapidement une page ?

Une première passe manuelle peut suivre cet ordre.

1. Texte principal

Contrôlez les paragraphes, titres et liens.

2. Texte secondaire

Inspectez légendes, métadonnées, dates, aides et placeholders.

3. Composants

Regardez champs, boutons, cases, radios, interrupteurs et leurs états.

4. Focus

Naviguez uniquement au clavier.

5. Messages

Vérifiez erreurs, succès, avertissements et informations.

6. Graphiques et icônes

Repérez les éléments qui transmettent une information sans texte.

7. Images et dégradés

Contrôlez tous les textes superposés.

8. Thèmes

Répétez l’analyse en mode clair et sombre lorsqu’ils existent.

Le vérificateur de contraste peut accompagner cette passe pour les couples de couleurs simples.

Pourquoi le mode sombre doit-il être testé séparément ?

Un thème sombre n’est pas une inversion automatique du thème clair.

Une couleur parfaitement adaptée sur blanc peut :

• vibrer excessivement sur noir ;
• perdre sa hiérarchie ;
• manquer de contraste avec une surface sombre ;
• devenir trop lumineuse.

Chaque thème crée de nouveaux couples de couleurs.

Il faut donc tester les tokens dans leurs contextes respectifs.

Par exemple :

[data-theme="light"] {
  --surface: #ffffff;
  --text: #0f172a;
}

[data-theme="dark"] {
  --surface: #0f172a;
  --text: #f8fafc;
}

Les couleurs secondaires, liens, bordures et états doivent suivre la même logique.

Peut-on se fier à la pipette d’un logiciel ?

Une pipette est utile pour récupérer une couleur visible, mais plusieurs éléments peuvent compliquer l’analyse :

• transparence ;
• antialiasing ;
• photographie ;
• dégradé ;
• profil colorimétrique ;
• composition de plusieurs couches.

Pour du texte simple sur fond uni, utilisez de préférence les valeurs CSS réellement appliquées.

Pour une composition complexe, inspectez le rendu effectif.

Pourquoi l’antialiasing peut-il tromper une capture d’écran ?

Les bords des glyphes comportent souvent des pixels intermédiaires produits par le rendu du texte.

Prélever un pixel sur le bord d’une lettre peut donc donner une couleur différente de la couleur CSS du texte.

Les WCAG définissent le contraste à partir des couleurs spécifiées dans le contexte pertinent plutôt qu’en exigeant de mesurer chaque pixel antialiasé.

C’est une raison supplémentaire de préférer les valeurs source lorsque vous les connaissez.

Contraste et taille de police : les erreurs fréquentes

« Mon texte fait 18 px, donc il est grand »

Pas nécessairement selon la définition WCAG du texte de grande taille.

« Il est en semi-bold, donc le seuil 3:1 suffit »

La définition repose sur des seuils précis ; il ne faut pas transformer « un peu gras » en exemption automatique.

« Le titre est grand visuellement »

Un titre n’est pas automatiquement du « large text » simplement parce qu’il joue un rôle de titre.

« Le ratio est 4,49:1, c’est pratiquement 4,5 »

Les seuils ne sont pas arrondis de manière à transformer un résultat inférieur en réussite. Il vaut de toute façon mieux conserver une marge plutôt que viser exactement la limite.

Pourquoi viser une marge plutôt que le seuil exact ?

Une couleur juste au seuil peut devenir problématique lorsque :

• le fond change ;
• une transparence est ajoutée ;
• un état différent est utilisé ;
• une variable CSS est modifiée ;
• le composant est réutilisé ailleurs.

Construire une petite marge rend le système plus robuste.

Cela ne signifie pas qu’il faut pousser toutes les combinaisons à 21:1.

Il s’agit simplement d’éviter une palette conçue au centième près autour du minimum.

Le contraste suffit-il pour rendre une interface accessible ?

Non.

Le contraste n’est qu’un ensemble de critères parmi beaucoup d’autres.

Une interface peut présenter :

• un excellent contraste ;
• des images avec de bons textes alternatifs ;
• des composants correctement identifiés ;

et rester difficile à utiliser si la navigation clavier est cassée ou si l’ordre de lecture est incohérent.

À l’inverse, une page techniquement bien structurée peut échouer sur une palette illisible.

L’accessibilité est cumulative.

Cet article se concentre volontairement sur les couleurs et la perception visuelle, dans le cadre de la collection Images, couleurs et graphismes du Web.

Contraste et choix du format d’image

Le contraste WCAG n’est pas déterminé par le fait qu’une image soit JPEG, PNG, WebP ou AVIF.

Cependant, le format et la compression peuvent influencer le rendu d’un texte intégré dans une image ou de détails graphiques fins.

Une compression agressive peut introduire :

• flou ;
• halos ;
• artefacts ;
• perte de netteté.

C’est une raison supplémentaire d’éviter d’intégrer du texte dans une image lorsque du vrai texte HTML convient mieux.

Le prochain article de la collection, PNG, JPEG, WebP ou AVIF : quel format choisir ?, explique comment choisir un format selon le contenu, la transparence, le poids et la qualité attendue.

Contraste et compression d’image

Lorsqu’une interface contient des informations graphiques dans une image, une compression excessive peut dégrader la distinction des contours et des détails.

L’article Comment compresser une image sans perdre en qualité ? approfondit ce compromis entre poids et fidélité.

La question est différente pour les éléments d’interface en HTML/CSS ou en SVG : leur rendu ne dépend pas d’un encodage photographique avec perte.

Pour les graphismes vectoriels, SVG : comprendre le format vectoriel explique pourquoi les formes restent définies mathématiquement et comment leurs couleurs sont représentées.

Contraste et SVG

Un SVG peut contenir :

• icônes ;
• illustrations ;
• graphiques ;
• logos ;
• texte vectorisé ou véritable texte.

Les règles d’accessibilité dépendent de la fonction de ces éléments, pas du simple fait qu’ils soient en SVG.

Une icône SVG interactive doit être pensée comme un composant d’interface. Un graphique SVG qui transmet une information doit rester compréhensible. Un élément décoratif n’a pas le même rôle.

Lorsque vous optimisez ensuite le fichier avec un outil comme l’optimiseur SVG, veillez à ne pas altérer les informations nécessaires. Le guide Optimiser un fichier SVG sans altérer son rendu approfondit cette étape.

Un workflow couleur accessible avec Bethemesh

Voici une chaîne simple qui relie les premiers articles de cette collection.

1. Comprendre la couleur

Lisez RGB, HEX ou HSL pour distinguer représentation, lightness HSL et luminance.

2. Construire ou extraire une palette

Utilisez l’extracteur de couleurs d’image ou le générateur de palette, puis consultez Créer une palette à partir d’une image.

3. Convertir si nécessaire

Le convertisseur de couleurs permet de passer d’une notation à l’autre.

4. Attribuer des rôles

Définissez les couleurs de texte, surfaces, actions, états et accents.

5. Tester les couples

Utilisez le vérificateur de contraste.

6. Tester l’interface réelle

Contrôlez les états, le clavier, les images, les dégradés et les thèmes.

Cette méthode évite de considérer l’outil de contraste comme une étape isolée.

Checklist avant de valider une palette

Avant de considérer votre système de couleurs comme prêt :

• le texte courant atteint-il au moins le seuil applicable ?
• le texte de grande taille est-il correctement identifié avant d’utiliser le seuil 3:1 ?
• les textes secondaires restent-ils lisibles ?
• les liens sont-ils identifiables ?
• les erreurs utilisent-elles autre chose que la couleur seule ?
• les états de succès et d’avertissement ont-ils des libellés ou indices supplémentaires ?
• les composants nécessaires sont-ils perceptibles ?
• le focus clavier est-il visible ?
• les icônes fonctionnelles sont-elles suffisamment perceptibles ?
• les graphiques restent-ils compréhensibles sans dépendre uniquement des teintes ?
• les textes sur images ont-ils été testés sur leur zone réelle ?
• les transparences sont-elles prises en compte ?
• le mode sombre a-t-il été vérifié séparément ?
• les états hover, focus, active et disabled ont-ils été examinés ?

Cette checklist est plus utile qu’un simple « toutes mes couleurs sont AA ».

Les erreurs les plus fréquentes

Vérifier seulement le texte principal

Les petits textes secondaires sont souvent ceux qui échouent.

Croire qu’une couleur est « accessible »

Une couleur doit être évaluée contre son contexte.

Utiliser la lightness HSL comme ratio

Ce sont deux mesures différentes.

Tester un texte transparent comme s’il était opaque

Le fond modifie sa couleur visible.

Tester la moyenne d’une photographie

Le contraste d’un texte superposé varie localement.

Penser que AA valide toute l’interface

Un ratio de texte ne couvre ni les composants, ni l’utilisation de la couleur, ni les autres critères WCAG.

Utiliser uniquement rouge et vert pour deux états

Ajoutez texte, symboles ou autres indices.

Rendre les placeholders presque invisibles

La discrétion visuelle ne doit pas sacrifier la lisibilité.

Oublier le focus

Une interface à la souris peut sembler correcte alors que la navigation clavier est très difficile.

Viser exactement 4,5:1

Une petite marge rend le système plus robuste.

Ce qu’il faut retenir

Le contraste WCAG ne consiste pas à choisir entre une interface jolie et une interface accessible.

Il consiste à faire en sorte que la couleur remplisse son rôle sans rendre l’information ou les actions inutilement difficiles à percevoir.

Les points essentiels sont :

• 4,5:1 constitue le seuil AA du texte courant ;
• 3:1 s’applique au texte de grande taille au niveau AA ;
• 7:1 et 4,5:1 correspondent aux seuils renforcés AAA pour ces catégories ;
• certains composants et éléments graphiques nécessaires utilisent un seuil de 3:1 dans le cadre du contraste non textuel ;
• la couleur ne doit pas être le seul moyen de transmettre certaines informations ;
• la lightness HSL n’est pas la luminance relative WCAG ;
• transparence, images, dégradés et états interactifs exigent une analyse du contexte réel.

Le vérificateur de contraste fournit la mesure. Le convertisseur de couleurs aide à manipuler les valeurs. Mais la décision finale reste une décision de conception : quelle information doit être perçue, dans quel contexte, et par quels moyens ?

Après les couleurs et leur accessibilité, la collection passe à la manière dont les pixels sont enregistrés et distribués. Continuez avec PNG, JPEG, WebP ou AVIF : quel format choisir ?.

Questions fréquentes

Quel contraste faut-il pour du texte normal ?

Au niveau WCAG AA, le texte courant doit atteindre un ratio d’au moins 4,5:1 avec son arrière-plan, sauf exceptions prévues par le critère.

Quel contraste faut-il pour un grand texte ?

Au niveau AA, le seuil est 3:1 pour le texte répondant à la définition WCAG du texte de grande taille.

Quel est le seuil AAA ?

Le critère renforcé utilise 7:1 pour le texte courant et 4,5:1 pour le texte de grande taille.

Un ratio de 4,49:1 peut-il être arrondi à 4,5:1 ?

Il ne faut pas arrondir un résultat inférieur pour le transformer en réussite. En pratique, visez également une petite marge plutôt que la limite exacte.

HSL 50 % de luminosité signifie-t-il que la couleur a toujours le même contraste ?

Non. La lightness HSL n’est pas la luminance relative WCAG. Deux couleurs à 50% de lightness peuvent avoir des contrastes très différents sur le même fond.

Le noir sur blanc est-il obligatoire ?

Non. De très nombreuses combinaisons colorées peuvent respecter les critères. Le noir sur blanc représente simplement le contraste maximal.

Les logos doivent-ils respecter 4,5:1 ?

Le texte faisant partie d’un logo ou d’un nom de marque bénéficie d’une exception dans le critère 1.4.3. Cela n’empêche pas de rechercher une bonne lisibilité.

Les placeholders doivent-ils être lisibles ?

Oui. Le fait qu’un texte soit un placeholder ne constitue pas en soi une raison pour le rendre presque invisible.

Une icône doit-elle avoir un contraste de 3:1 ?

Cela dépend de son rôle. Lorsqu’une information visuelle est nécessaire pour identifier un composant ou comprendre un graphique, le critère de contraste non textuel peut s’appliquer. Une icône purement décorative n’a pas la même fonction.

Puis-je utiliser rouge et vert pour succès et erreur ?

Oui, mais ne faites pas reposer l’information uniquement sur la couleur. Ajoutez par exemple un libellé, une icône ou un symbole distinct.

Comment tester du texte sur une photographie ?

Il faut évaluer le contraste sur les zones réellement situées derrière le texte. Une couleur moyenne de l’image n’est pas représentative. Une surface ou un overlay maîtrisé peut faciliter la conception.

Un bouton qui passe le test de contraste est-il automatiquement accessible ?

Non. Il faut également vérifier son identification, ses états, son focus, son libellé et les autres critères applicables.

Le mode sombre utilise-t-il les mêmes ratios ?

Les critères de contraste restent pertinents, mais les couples de couleurs changent. Le thème sombre doit donc être testé séparément.

Comment corriger rapidement une couleur trop claire ?

Assombrissez-la, modifiez le fond ou créez une variante dédiée au texte. Puis mesurez à nouveau le couple avec le vérificateur de contraste.

Faut-il tester toutes les combinaisons de la palette ?

Testez en priorité les couples réellement utilisés : texte/fond, bouton/texte, liens, erreurs, focus, icônes fonctionnelles et graphiques.

Quel outil utiliser pour vérifier deux couleurs ?

Le vérificateur de contraste Bethemesh permet de mesurer directement une paire. Si vous devez d’abord passer de RGB ou HSL vers une autre notation, utilisez le convertisseur de couleurs.