Générateur de palettes de couleurs accessibles

Par Bogdan Sandu (EN) · Publié 22 décembre 2025 · Dernière mise à jour 14 septembre 2026

Ce générateur de palettes de couleurs accessibles crée une palette de cinq couleurs à partir d’une couleur de base. Pour chacune, il indique si un texte blanc ou noir sur ce fond atteint les seuils de contraste des WCAG. Choisissez une couleur et un type de palette, puis consultez les indicateurs.

Ce que vous pouvez définir :

• Couleur de base provenant du sélecteur, d'un code hexadécimal saisi ou du bouton Aléatoire
• Type de palette : Vibrant, Monochromatique, Contrasté 1, Contrasté 2, Pastel, Pastel contrasté 1, Pastel contrasté 2 ou Foncé à clair
• Lock sur n'importe quelle carte, afin que cette couleur survive à la prochaine régénération

Chaque carte affiche les valeurs HEX, RVB et HSL de la couleur, chacune avec son propre bouton de copie. En dessous se trouvent le rapport de contraste et deux badges : WCAG AA (4,5 :1) et WCAG AAA (7 :1).

Comment utiliser ce générateur de palette de couleurs accessible

1. Entrez la couleur de votre marque dans le champ hexadécimal ou cliquez sur Aléatoire pour un point de départ.
2. Choisissez un type de palette. La palette se régénère à chaque changement et les modes Vibrant, Contrasté et Pastel ajoutent un peu d'aléatoire, alors choisissez deux fois le même mode pour voir les variations.
3. Verrouillez les couleurs que vous souhaitez conserver, puis changez le mode ou la couleur de base pour régénérer le reste.
4. Lisez les badges. Un AA vert signifie qu'un texte en blanc ou en noir, selon celui qui est le plus fort, atteint au moins 4,5 : 1 sur cette couleur.
5. Copiez les valeurs dans votre feuille de style ou vos jetons de conception.

Une carte pour #2C5F8A se lit comme ceci :

HEX   #2C5F8A
RGB   44, 95, 138
HSL   207°, 52%, 36%
WCAG AA ✓   WCAG AAA ✗
Contrast: 6.75:1

Le rapport est la formule WCAG que l'outil exécute dans le navigateur : luminance relative de la couleur la plus claire plus 0,05, divisée par la luminance relative de la couleur la plus foncée plus 0,05, après linéarisation de chaque canal RVB.

function luminance(r, g, b) {
  const lin = c => {
    c /= 255;
    return c <= 0.03928 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4;
  };
  return 0.2126 * lin(r) + 0.7152 * lin(g) + 0.0722 * lin(b);
}

function contrast(a, b) {
  const [l1, l2] = [luminance(...a), luminance(...b)].sort((x, y) => y - x);
  return (l1 + 0.05) / (l2 + 0.05);
}

Ce que l'outil ne fait pas

• Cela ne contraint pas la génération par contraste. Les palettes proviennent de décalages de teinte, de saturation et de luminosité autour de votre couleur de base. Les badges sont une vérification du résultat, pas une contribution à celui-ci. Si une carte échoue, régénérez-la, verrouillez les passes et réessayez, ou rendez la couleur de base plus foncée ou plus claire.
• Il vérifie chaque couleur par rapport au texte blanc et noir uniquement. Il ne teste pas les couleurs de la palette les unes par rapport aux autres. Pour une association texte sur couleur entre deux couleurs de palette, exécutez les deux codes hexadécimaux via la formule ci-dessus ou un vérificateur de contraste dédié.
• Il utilise les ratios WCAG 2. Il n’y a pas de score APCA.
• Il ne simule pas le daltonisme. Consultez la palette dans Coblis (EN) ou Color Oracle (EN) avant l'expédition.
• Il n'y a pas d'exportation. Copiez les valeurs dont vous avez besoin ou nommez-les avec le outil de recherche de noms de couleurs.

Le reste de cette page couvre les normes, les mathématiques et le flux de travail plus large dans lequel l'outil s'intègre.

Qu'est-ce qu'un générateur de palette de couleurs accessible ?

Un générateur de palette de couleurs accessible est un outil de conception qui crée des combinaisons de couleurs pour répondre à une norme de contraste mesurable, et pas seulement pour un aspect agréable.

C'est la principale différence par rapport à un outil de palette classique. Un générateur régulier optimise l’harmonie des teintes. Un outil accessible soit optimise d'abord la lisibilité, soit, comme l'outil ci-dessus, génère l'harmonie, puis mesure la lisibilité de chaque résultat.

Les utilisateurs typiques incluent :

• Concepteurs de produits créant un système de couleurs pour une interface en direct
• Développeurs front-end qui ont besoin de codes hexadécimaux sans contraste avant de toucher CSS
• L'accessibilité conduit à auditer une palette de marques existante

Le texte à faible contraste est le problème d'accessibilité le plus courant trouvé sur le Web, présent sur 83,9 % des pages d'accueil testées dans le rapport WebAIM Million 2026 (EN), contre 79,1 % l'année précédente.

Cette seule statistique est la raison pour laquelle cette catégorie d’outils existe. La plupart des problèmes de couleurs sur le Web ne sont pas exotiques. Ce sont de simples échecs de contraste qu'un générateur détecte avant le lancement.

Cette pratique s'inscrit dans la discipline plus large de l'accessibilité web (EN), mais sa portée est plus restreinte.

Un générateur de palette accessible ne vérifie pas les étiquettes des lecteurs d'écran ou les pièges de clavier. Il vérifie une chose : si une combinaison de couleurs de premier plan et d'arrière-plan est lisible pour les personnes ayant une faible vision ou une déficience de vision des couleurs. Cela en fait un petit mais porteur morceau de design d'interface utilisateur (EN).

WCAG vs APCA : Quelle norme de contraste utiliser ?

Les WCAG mesurent le contraste par un rapport de luminance relative. APCA le mesure à travers un score de légèreté perceptuelle appelé Lc.

Les deux existent pour répondre à la même question de différentes manières : ce texte est-il lisible dans ce contexte ?

Chiffres clés, sources :

• WCAG 2.2 Niveau AA : rapport de contraste minimum 4.5 :1 pour le texte normal et 3 :1 pour le texte à grande échelle, selon le critère de succès 1.4.3 (EN)
• WCAG 2.2 Niveau AAA : minimum 7 :1 pour le texte normal, selon le critère de réussite 1.4.6 (EN)
• APCA : Lc 90 préféré et Lc 75 minimum pour le corps du texte, selon la documentation APCA (EN)

APCA (EN) a été développé par le chercheur Andrew Somers et est la méthode de contraste candidate pour WCAG 3, toujours en développement.

Il rapporte le contraste de couleur (EN) sur une échelle de Lc 0 à environ Lc 106, où Lc 15 est le minimum absolu pour qu'une frontière non textuelle soit discernable.

La Section 508 (EN), la Americans with Disabilities Act (EN) et la EN 301 549 (EN) européenne font toutes référence aux seuils de ratio des WCAG comme étant l'épine dorsale légale de l'accessibilité numérique.

Aucun d’entre eux ne cite actuellement APCA directement. C'est pourquoi la plupart des générateurs, y compris celui-ci, utilisent toujours les mathématiques WCAG par défaut, même si APCA gagne en popularité parmi les concepteurs.

Une paire de couleurs peut passer le test de rapport WCAG sur le papier et se sentir encore faible dans la pratique. Les mathématiques de la luminance relative ne tiennent pas pleinement compte de la façon dont l'œil humain perçoit la lumière à différentes tailles et poids.

Comment un générateur de palette de couleurs accessible calcule-t-il le contraste ?

Le calcul du contraste commence par la luminance relative (EN), une valeur dérivée des canaux rouge, vert et bleu de chaque couleur après correction gamma. Le bloc de code près du haut de cette page est la formule entière.

Le générateur prend la luminance du premier plan, la luminance de l'arrière-plan, et les combine en un seul rapport entre 1 :1 et 21 :1.

Deux phrases résument l'ensemble de la méthode : une luminance plus sombre plus une luminance plus claire produit un écart plus grand, et un écart plus grand produit un rapport plus élevé.

Le glissement d'une valeur de teinte dans les sélecteurs de couleurs HSL vs RGB (EN) est l'endroit où la plupart des échecs accidentels se produisent. Le réglage de la saturation peut déplacer la luminance sans que le concepteur ne s'en aperçoive.

Espace de couleur et pourquoi il change le résultat

Tous les espaces de couleurs ne représentent pas la luminosité de la même manière, ce qui est important lorsqu’un générateur ajuste une teinte pour atteindre un rapport cible. L'outil ci-dessus fonctionne en HSL, c'est pourquoi ses badges sont importants : la légèreté HSL seule ne prédit pas le contraste.

HSL traite la luminosité comme une moyenne simple des canaux RGB les plus élevés et les plus bas d'une couleur. C'est pourquoi deux couleurs avec la même valeur de luminosité HSL peuvent avoir une luminosité sensiblement différente.

L’OKLCH et le CIELAB modélisent tous deux la lumière plus près de la façon dont l’œil la perçoit. Le fait de pousser une valeur vers le haut ou vers le bas permet de maintenir le contraste souhaité intact.

Les concepteurs qui ont besoin de passer rapidement d'un format à l'autre utilisent souvent un convertisseur RGB vers HSL ou un HEX vers RGB pour vérifier la traduction d'une couleur de marque de base.

Comment ces outils simulent-ils le daltonisme ?

La simulation du daltonisme restitue une palette telle qu’elle apparaîtrait à une personne présentant un type spécifique de déficience de vision des couleurs. Le générateur sur cette page n'en inclut pas, alors considérez ceci comme l'étape qui le suit.

Trois types sont simulés le plus souvent :

• Deuteranopie, sensibilité réduite au vert
• Protanopie, sensibilité réduite au rouge
• Tritanopie, sensibilité réduite au bleu, beaucoup plus rare que les deux autres

Coblis (EN), Color Oracle (EN), et Sim Daltonism (EN) sont les simulateurs de référence auxquels le champ d'accessibilité pointe le plus. Plusieurs outils de palette autorisent ou répliquent leur logique de filtrage.

Il s'agit d'une vérification distincte des mathématiques de contraste. Une paire peut atteindre 4,5 :1 et encore s'effondrer dans presque la même teinte une fois que la deuteranopie est simulée. La formule de rapport ne sait pas quelles teintes un spectateur peut distinguer.

La déficience de la vision des couleurs touche environ 1 homme sur 12 (8 %) et 1 femme sur 200 (0,5 %), selon Colour Blind Awareness (EN).

C'est une part significative de n'importe quel public. C'est pourquoi la conception inclusive (EN) considère la simulation comme une étape obligatoire, et non comme une option supplémentaire.

La confusion rouge-vert représente l'écrasante majorité des cas, donc un générateur qui vérifie uniquement la tritanopie résout le problème le plus mineur.

Comment fonctionne la logique de génération de palette ?

La génération de la palette suit l'une des deux logiques suivantes : basée sur l'harmonie ou sur le contraste. Ce générateur est basé sur l'harmonie, avec le contrôle de contraste appliqué par la suite.

Les outils basés sur l'harmonie partent des règles de la théorie des couleurs.

• Complémentaire : deux teintes opposées sur la roue
• Analogique : nuances assises l'une à côté de l'autre
• Triadic : trois teintes espacées uniformément

Les outils de contraste d'abord fonctionnent en arrière. Verrouillez une couleur de base, définissez un rapport cible et laissez l’algorithme générer automatiquement des teintes et des ombres correspondant à ce nombre.

Adobe a construit une version hybride de ce logiciel appelée Leonardo (EN), un outil open source de son équipe Spectrum design system (EN).

Leonardo prend une couleur de marque en entrée et produit une échelle complète calibrée selon des rapports de contraste spécifiques. Par défaut, il est défini sur 3 :1 et 4.5 :1, les deux seuils définis par le WCAG pour le texte long et le texte normal.

Le compromis mérite d'être dit clairement. Une palette d'harmonie d'abord a généralement l'air mieux au premier essai, mais elle a besoin d'un passage de contraste par la suite, ce qui est ce que font les badges ci-dessus.

Une palette de contraste passe immédiatement le contrôle d'accessibilité. Il faut parfois un deuxième regard pour s’assurer que les nuances semblent toujours être une marque cohérente.

Meilleurs générateurs de palette de couleurs accessibles comparés

Coolors (EN), Adobe Color (EN), Khroma (EN), Stark (EN) et ColorBox (EN) couvrent la plupart des méthodes utilisées par les équipes pour générer des palettes accessibles aujourd'hui.

Les équipes qui travaillent déjà dans un flux de travail de conception basé sur Figma (EN) ont tendance à recourir à Stark. Il vérifie le contraste sans quitter le fichier.

Où chaque outil a tendance à convenir le mieux :

• Refroidisseurs pour une exploration rapide et générale de la palette avec un contrôle de contraste superposé sur le dessus
• Leonardo pour les équipes créant une échelle de jetons de conception complète à partir d'une couleur de marque
• Khroma pour l'inspiration précoce, le contraste a encore besoin d'un vérificateur séparé après

Les options open source comme Leonardo (EN) donnent aux équipes d'ingénierie un accès direct à l'algorithme sous-jacent. Cela est important lorsqu’une palette doit se régénérer automatiquement lorsque la couleur d’une marque change.

Les outils d’abonnement comme Stark échangent cette flexibilité pour un flux de travail plus fluide, basé sur des plugins que les concepteurs non techniques peuvent exécuter sans toucher au code.

Avantages et inconvénients de la génération automatisée de palettes accessibles

L’automatisation supprime la partie la plus lente et la plus sujette aux erreurs du travail de couleur accessible : tester manuellement chaque association de premier plan et d’arrière-plan.

Avantages :

• Vitesse, une échelle de couleurs complète se génère en quelques secondes au lieu d'heures
• Cohérence, chaque nuance dans un système est vérifiée par rapport au même rapport cible
• Moins d’erreurs humaines, personne n’oublie de tester un état de survol

Cons :

• La nuance de la marque peut s’aplatir lorsqu’un algorithme privilégie le rapport au toucher
• Les éléments non textuels tels que les icônes et les bordures de saisie ne sont souvent pas cochés, car la plupart des générateurs se concentrent sur le texte
• Les dégradés et les arrière-plans photographiques ne sont pas gérés du tout

Ce deuxième écart est plus important qu’il n’y paraît. Les champs de formulaire, en particulier, dépendent du contraste des bordures qu'un générateur de texte uniquement ne signalera pas. C'est l'une des raisons pour lesquelles les formulaires accessibles (EN) ont toujours besoin d'un passe de révision dédié.

La révision manuelle ne disparaît pas une fois qu'un outil approuve une palette. Il se réduit aux éléments que l'automatisation ne peut pas atteindre : le contraste non textuel, les dégradés et tout ce qui utilise la couleur seule pour véhiculer un sens.

La façon honnête de le formuler : l'automatisation gère l'arithmétique, un humain possède toujours les appels de jugement.

Comment générer et mettre en œuvre une palette de couleurs accessible

La génération d'une palette de couleurs accessibles suit un ordre fixe : couleur de base en premier, norme cible en deuxième, vérification du contraste en troisième, exportation en dernier. L'outil ci-dessus couvre les première et troisième étapes.

Sauter l'ordre est l'endroit où la plupart des palettes se trompent, généralement parce que quelqu'un exporte avant que le daltonien ne passe.

1. Choisissez une couleur de base et enregistrez son code hexadécimal
2. Choisissez une norme cible : WCAG AA, WCAG AAA ou une valeur Lc APCA spécifique
3. Générer l'échelle de teinte et de nuance, en vérifiant chaque pairing par rapport à cette cible
4. Exécutez l'échelle complète à travers un passage de simulation daltonien
5. Exporter la palette approuvée dans le format utilisé par votre build

Le format d’exportation est plus important que ce que les équipes s’attendent.

Une palette verrouillée dans des valeurs hexadécimales plates doit être éditée à la main chaque fois qu'une couleur de marque change. Une propriété personnalisée exportée en CSS (EN) se met à jour partout où elle est référencée au moment où la variable racine change.

Les équipes de conception travaillant avec Figma et le code exportent de plus en plus directement vers des jetons de conception. La fonctionnalité de variables propres à Figma, traitée dans ce guide des variables de Figma (EN), se mappe proprement sur cette structure de propriétés personnalisées CSS.

Les jetons de conception JSON se situent entre les deux : ils sont suffisamment portables pour un système de conception, et suffisamment structurés pour qu'un pipeline de construction puisse les utiliser sans traduction manuelle.

Lorsque les générateurs de palette de couleurs accessibles ne s’appliquent pas

Un générateur de palette de couleurs accessible cesse d'être utile au moment où la surface qu'il vérifie n'est pas une couleur plate connue.

Quatre situations sont en dehors de ce que ces outils peuvent vérifier :

• Éléments non textuels : les icônes, les bordures de saisie et les états de basculement sont soumis à une règle distincte, WCAG 1.4.11 (EN), et non au rapport de contraste de texte par défaut de la plupart des générateurs.
• Dégradés et arrière-plans photographiques : il n'y a pas de couleur d'arrière-plan unique pour mesurer un rapport contre
• Arrière-plans dynamiques ou générés par l'utilisateur : une bannière de profil ou une image téléchargée ne peut pas être vérifiée à l'avance
• Couleurs de marque déposées ou légalement fixées : une couleur qui ne peut pas être décalée n'a pas de place pour une correction de contraste

Le WCAG 1.4.11 fixe son propre seuil de 3 :1 pour les limites visuelles des composants d'interface et des graphiques significatifs. Il s'agit d'un critère distinct des ratios de texte couverts précédemment.

La documentation du Carbon Design System d'IBM (EN) nomme directement cette lacune. Il avertit les équipes de vérifier le contraste du texte à chaque point où il traverse un dégradé ou une image, car une seule valeur hexadécimale fixe ne tiendra pas sur un arrière-plan en mouvement.

Carbon oriente également les concepteurs vers le plugin Stark pour l'examen daltonien, une reconnaissance du fait qu'aucune étape de générateur ne couvre tous les attributs dont une interface réelle a besoin. C'est en partie pourquoi les composants accessibles de l'interface utilisateur (EN) sont audités comme leur propre catégorie plutôt que d'être repliés dans une vérification de palette.

Erreurs courantes qui cassent l'accessibilité après la génération

Une palette peut passer tous les contrôles effectués par un générateur et échouer en production.

Quatre erreurs expliquent la majeure partie de cet écart :

• Vérifier le mauvais calque : une superposition semi-transparente change la couleur d'arrière-plan effective, et un générateur testé contre la couleur de base seule ne le verra pas
• Ignorer les états de survol et de focus : le critère Apparence de focus (EN) des WCAG 2.2, publié en octobre 2023, nécessite un contraste d'au moins 3 : 1 entre les états focalisé et non focalisé d'un composant.
• Utilisation de la teinte seule pour porter un sens : un indicateur de statut rouge par rapport au vert disparaît pour les environ 8% d'hommes présentant une déficience de vision des couleurs rouge-vert couverte précédemment
• Ignorer le contraste non textuel sur les icônes et les bordures : une couleur de bordure gris clair, celle utilisée par défaut dans de nombreux systèmes de conception, est généralement proche de 1,6 : 1 par rapport au blanc, bien en dessous du minimum de 3 : 1.

Chacun de ces éléments passe un contrôle de contraste de texte uniquement sans aucun avertissement. Aucun d'entre eux ne touche le rapport de texte que le vérificateur est conçu pour capturer.

Le correctif n'est pas un meilleur générateur. Il traite la sortie du générateur comme une palette de départ, puis exécute un deuxième passage sur les états, les superpositions et les éléments non textuels avant que tout ne soit expédié.

Questions fréquentes : Générateur de palettes de couleurs accessibles

À quelles normes juridiques font référence les générateurs de palette de couleurs accessibles ?

La plupart des générateurs de palettes de couleurs accessibles vérifient le contraste par rapport aux seuils de rapport du WCAG, puisque la Section 508, l'ADA et la norme européenne EN 301 549 citent tous cette norme directement. APCA n'est pas référencé dans la loi actuelle, même si c'est la méthode candidate pour WCAG 3.

Un jumelage de couleurs peut-il passer le WCAG et être difficile à lire pour un utilisateur daltonien ?

Oui, oui. La formule de rapport du WCAG mesure la différence de luminance, pas la différence de teinte, de sorte que deux couleurs peuvent atteindre 4.5 :1 et avoir toujours l'air presque identiques sous deuteranopie. Un passage de simulation daltonienne permet de combler cet écart ; le contrôle du ratio seul ne le fait pas.

Un générateur de palette de couleurs accessible gratuitement est-il suffisant ou un outil payant en vaut-il la peine ?

Des outils gratuits comme celui-ci, Coolors, et Khroma gèrent bien les contrôles de contraste à palette unique. Les outils payants comme Stark ajoutent des vérifications de contraste non textuelles, des bibliothèques d'équipe et des exportations de système de conception. Celles-ci sont importantes une fois qu'une palette doit être mise à l'échelle sur un produit complet.

Quel est le coût d’un contraste non conforme pour une entreprise en termes juridiques ou de convivialité ?

Les plaignants ont déposé 2 452 poursuites concernant l'accessibilité des sites Web devant les tribunaux fédéraux en 2024, selon le suivi des dépôts judiciaires de Seyfarth Shaw (EN). Les échecs de contraste sont parmi les défauts les plus couramment cités, aux côtés du texte alternatif manquant et des champs de formulaire non étiquetés.

APCA est-il plus fiable que WCAG pour un travail de conception réel ?

Les modèles APCA perçoivent la légèreté avec plus de précision, selon son développeur Andrew Somers, ce qui lui permet de mieux prédire la lisibilité réelle. Les WCAG restent la norme légalement citée. La plupart des équipes vérifient les deux jusqu'à ce que les WCAG 3 adoptent formellement une méthode perceptuelle.

Comment vérifiez-vous une palette qui a déjà passé un générateur avant de l’expédier ?

Testez chaque état de survol, de focus et désactivé séparément, car un générateur ne vérifie généralement que l'association par défaut. Vérifiez ensuite les éléments non textuels comme les bordures et les icônes. Enfin, visualisez une dernière fois la palette complète via un simulateur de daltonisme.

Que devriez-vous vérifier en premier lorsqu’un générateur de palette de couleurs accessible approuve une palette ?

Un générateur de palette de couleurs accessible ne gagne sa place dans la production que lorsque son approbation est traitée comme un point de départ. Un rapport de contraste passé confirme la lisibilité du texte seul.

Trois vérifications déterminent si cette approbation se maintient après le lancement.

• Couplages de texte en premier
• Deuxièmes bordures et icônes non textuelles
• Les états interactifs durent

Cet ordre suit l'exposition. Le texte cassé échoue immédiatement, les bordures cassées ralentissent la reconnaissance, et les états cassés n'apparaissent que lorsque quelqu'un interagit.

Le compromis est la vitesse. Vérifier trois seuils au lieu d’un ajoute une étape de révision que le travail d’harmonie des couleurs pures n’a jamais requis.

Le WCAG 3.0 working draft (EN) du W3C, mis à jour le 10 septembre 2026, est toujours un Working Draft qui ne peut pas être cité comme un standard. Les seuils actuels sont valables jusqu'à ce qu'une future recommandation les remplace.

Les équipes qui vont au-delà de la couleur peuvent ensuite travailler à travers une liste de contrôle d'accessibilité web (EN) complète.