Générateur de palette accessible, gratuit

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 qui vous aide à assembler un ensemble de couleurs pour un site web, une application ou un design imprimé où chaque paire de couleurs destinée à être affichée ensemble (texte sur fond, bouton sur toile, étiquette sur champ) respecte les exigences de contraste WCAG. Le but est d'attraper les combinaisons à faible contraste au moment du design plutôt qu'au moment de l'audit. Vous ajoutez des couleurs à une palette, l'outil calcule le ratio de contraste entre chaque paire et étiquette chaque paire AAA pass, AA pass, ou échec. Vous itérez jusqu'à ce que chaque paire que vous avez réellement l'intention d'utiliser passe.

Le ratio de contraste est un nombre entre 1:1 (couleurs identiques, invisible) et 21:1 (noir sur blanc). WCAG 2.2 Critère de Succès 1.4.3 exige 4,5:1 pour le texte normal à taille standard (Niveau AA), 3:1 pour le texte large (24px+ régulier ou 18,66px+ gras), et 4,5:1 pour les éléments graphiques et contrôles UI (CS 1.4.11). WCAG AAA élève le texte normal à 7:1 et le texte large à 4,5:1. La plupart des sites web destinés au public doivent répondre au moins à AA selon ADA, EAA, AODA et lois similaires ; les sites gouvernementaux dans de nombreuses juridictions doivent répondre à AAA.

Cet outil s'exécute dans votre navigateur. Vous choisissez les couleurs avec le sélecteur de couleur, l'outil calcule la luminance relative et les ratios de contraste en utilisant la formule spécifiée par WCAG, et une grille montre le statut de chaque paire. Vous pouvez exporter la palette finale comme propriétés personnalisées CSS (var(--brand-primary)), liste HEX, snippet de configuration Tailwind, ou JSON pour les tokens de design. Rien n'est téléversé ; toute la palette reste sur votre appareil.

Ce qu'il y a dans l'outil

Le haut de l'outil est un sélecteur de couleur plus un bouton ajouter à la palette. Choisissez une couleur, nommez-la (Marque Primaire, Surface, Texte Corps, etc.), et ajoutez. La palette grandit comme une liste d'échantillons sur le côté gauche. Vous pouvez éditer n'importe quel échantillon, le supprimer, ou le glisser pour réorganiser. Des palettes accessibles prédéfinies sont disponibles comme points de départ (paires à fort contraste, palettes conçues style IBM Carbon, palettes tonales Material Design 3) ; choisissez-en une, puis personnalisez.

La grille de contraste prend chaque paire d'échantillons et montre le ratio de contraste plus un badge pass/fail pour chaque niveau WCAG : AA-normal (4,5:1), AA-large (3:1), AAA-normal (7:1), AAA-large (4,5:1). Une paire montrée comme 4,7:1 passe AA-normal mais échoue AAA-normal ; une paire montrée comme 2,1:1 échoue à tout. Survolez une cellule pour prévisualiser la paire comme texte réel. Triez la grille par ratio pour repérer d'abord les pires paires.

Le panneau d'export formate la palette de la manière que votre chaîne d'outils attend : propriétés personnalisées CSS pour CSS moderne, variables Sass pour pipelines plus anciens, configuration de thème Tailwind pour Tailwind CSS, tokens de design JSON (Style Dictionary, spec W3C Design Tokens Community Group) pour systèmes de design multi-plateformes, ou simplement une liste HEX pour coller dans Figma. Les conventions de nommage sont préservées ; vous pouvez copier et coller directement dans votre base de code.

Histoire et contexte

La colorimétrie CIE établit la couleur scientifique (1931)

La Commission Internationale de l'Éclairage (CIE) a publié l'espace colorimétrique CIE 1931 en 1931, la première description mathématique formelle de la façon dont les humains perçoivent la couleur à partir des spectres électromagnétiques. Chaque système de couleur moderne (RGB, HSL, OKLCH, Lab, XYZ) s'appuie sur CIE 1931 directement ou par des transformations dérivées. La formule de luminance relative que WCAG utilise pour calculer le contraste est un calcul dérivé du CIE : elle pondère les canaux rouge, vert et bleu selon la force avec laquelle l'oeil humain répond à chacun (vert le plus, bleu le moins).

WCAG 1.0 introduit les directives de contraste (1999)

Les Directives pour l'Accessibilité du Contenu Web 1.0 (W3C, mai 1999) ont introduit le contraste comme critère d'accessibilité formel (Point de Contrôle 2.2 : assurez-vous que les combinaisons de couleurs de premier plan et d'arrière-plan fournissent un contraste suffisant). La première version était qualitative ; le seuil était vague. WCAG 2.0 (décembre 2008) a été le premier à spécifier des ratios de contraste numériques en utilisant la formule de luminance relative WCAG. Les seuils 4,5:1 et 7:1 dans 2.0 ont été conservés inchangés à travers 2.1 (2018) et 2.2 (2023) parce qu'ils équilibrent la lisibilité à travers la plupart des handicaps (basse vision, perte de sensibilité au contraste liée à l'âge, daltonisme) avec les contraintes pratiques de design.

Les systèmes de design codés couleur mûrissent (à partir de 2014)

Material Design de Google (2014), Carbon Design System d'IBM (2015), et la montée plus large des design tokens (Salesforce 2014, Atlassian 2016) ont tous mis en avant la couleur accessible comme préoccupation au niveau du système. Material Design 3 (2021) a introduit les palettes tonales (une rampe de luminosité à 13 étapes par teinte) explicitement conçues pour que tout ton 600+ sur l'échelle de luminosité passe le contraste 4,5:1 sur blanc. Ce changement a fait des palettes accessibles par défaut une pratique standard dans les systèmes de design modernes, remplaçant l'ancienne approche brand-first-accessibility-second.

APCA proposé comme alternative plus précise (à partir de 2019)

L'Accessible Perceptual Contrast Algorithm (APCA) a été proposé par Andrew Somers à partir de 2019 comme remplacement plus précis perceptuellement pour la formule de contraste WCAG. Le contraste WCAG surévalue la lisibilité des couleurs claires et sous-évalue le texte sombre sur fonds sombres ; APCA corrige cela. WCAG 3.0 (le brouillon de successeur à 2.x, en développement depuis de nombreuses années maintenant) devrait adopter APCA ou un algorithme amélioré similaire. Jusqu'à ce que WCAG 3 soit publié et adopté dans la loi, les ratios de contraste WCAG 2.x restent la norme légale et industrielle. Cet outil utilise la formule WCAG 2.x.

Les design tokens deviennent la norme multi-plateforme (à partir de 2020)

Le W3C Design Tokens Community Group a été formé en 2020 pour standardiser les design tokens (valeurs nommées de couleur, espacement, typographie qui se traduisent à travers CSS, iOS, Android, Figma et autres plateformes). Des outils comme Style Dictionary, Tokens Studio et la spec W3C émergente reposent tous sur des formats de token lisibles par machine. Les palettes de couleurs accessibles sont de plus en plus livrées comme design tokens afin que la même palette vérifiée soit utilisée partout, éliminant le mode de défaillance où le site web passe le contraste mais pas l'application mobile.

OKLCH et espaces colorimétriques perceptuellement uniformes (à partir de 2020)

CSS Color Module Level 4 (Recommandation Candidate 2024) a ajouté OKLCH, OKLab, Lab, LCH et autres espaces colorimétriques perceptuellement uniformes au CSS natif. OKLCH (introduit par Bjorn Ottosson en 2020) est particulièrement utile pour générer des palettes accessibles parce que des étapes de luminosité égales semblent égales à l'oeil, contrairement à HSL où les étapes de luminosité produisent des sauts visuels inégaux. Les générateurs de palette modernes (Leonardo d'Adobe, Polychrom, cet outil quand réglé en mode d'entrée OKLCH) tirent parti de ces espaces pour produire des palettes visuellement plus cohérentes qui atteignent les cibles de contraste au même niveau de luminosité.

Flux de travail pratiques

Concevoir une nouvelle palette de marque

Commencez avec la couleur de marque que vous devez garder (la couleur du logo, le primaire béni par l'équipe marketing). Ajoutez-la à la palette, puis construisez des teintes (versions plus claires) et nuances (versions plus sombres) avec des neutres (blanc, surface, surface variante, texte). Vérifiez chaque paire texte-sur-fond contre AA-normal. Si votre couleur de marque primaire échoue sur blanc, vous avez deux options : utilisez-la uniquement pour les grands éléments (logos, accents décoratifs) et pairez le texte du corps avec une variante plus sombre, ou compromettez légèrement la couleur de marque. Cet outil fait remonter ces choix au moment du design.

Auditer les décisions de couleur d'un site existant

Tirez les valeurs de couleur de vos design tokens existants (propriétés personnalisées CSS, config Tailwind, variables Sass), entrez-les dans cet outil, et révisez la grille de contraste. Échecs courants : texte gris mat sur blanc (souvent #999 ou #aaa, qui donne 2,8:1 ou 2,5:1), boutons couleur marque avec texte blanc où le bouton est mi-ton, couleurs de lien sur des arrière-plans chargés. Documentez les échecs avec leurs ratios et quel critère WCAG ils violent ; cette documentation est le début d'un plan de remédiation.

Choisir des couleurs d'accent pour les graphiques et data viz

Pour la visualisation de données, vous avez besoin de couleurs d'accent qui passent le contraste contre l'arrière-plan du graphique et qui sont aussi distinguables les unes des autres pour les utilisateurs avec déficience de vision des couleurs. Pairez cet outil avec ColorBrewer (Cynthia Brewer, Penn State, 2002) qui publie des palettes conçues pour rester distinguables sous les simulations de daltonisme. Exécutez les palettes candidates à travers les deux outils : contraste contre arrière-plan (cet outil), distinguabilité entre couleurs de palette (ColorBrewer ou Viz Palette).

Construire des compléments de mode sombre à une palette claire

Le mode sombre n'est pas juste un mode clair inversé ; les exigences de contraste s'appliquent toujours mais l'oeil perçoit le texte clair sur sombre différemment du texte sombre sur clair (le débat APCA est largement à propos de cela). Construisez la palette sombre comme un ensemble parallèle de tokens nommés (surface-dark, text-dark, accent-dark) et vérifiez chaque paire de mode sombre contre AA. Échecs courants de mode sombre : pur blanc (#fff) sur pur noir (#000) cause de la halation (lumière qui saigne), donc les designers utilisent souvent #e5e5e5 sur #121212 ; cela passe toujours AA mais est plus confortable à lire.

Générer des variantes de palette pour différentes surfaces

Les UI modernes ont plusieurs niveaux de surface (arrière-plan, carte, carte-élevée, modale, popover). Chaque surface devrait se pairer correctement avec chaque couleur de texte et d'accent utilisée par-dessus. Ajoutez chaque surface comme échantillon de palette et vérifiez chaque couleur de texte contre chaque surface. La grille de contraste montre rapidement si votre paire texte-sur-modale échoue quand texte-sur-carte passe (la modale a généralement une teinte d'arrière-plan légèrement différente pour indiquer l'élévation, ce qui peut faire chuter le contraste sous AA sans que vous le remarquiez).

Documentation de conformité pour soumission légale ou d'audit

Pour la documentation de conformité ADA ou EAA, vous avez généralement besoin de montrer que chaque combinaison de couleurs dans votre système de design passe le niveau WCAG pertinent. Exportez la palette plus la grille de contraste comme partie de la déclaration d'accessibilité ou du VPAT (Voluntary Product Accessibility Template) pour votre produit. Le JSON exporté est suffisamment structuré pour alimenter des rapports de conformité automatisés ; la grille visuelle est bonne pour la revue humaine.

Pièges courants

Traiter la couleur de marque comme intouchable

Le motif le plus courant : marketing insiste sur la couleur primaire corporative, mais elle échoue le contraste AA sur blanc. Options : utilisez la couleur de marque uniquement pour les grands éléments ou décoratifs (passe la barre plus indulgente 3:1 grand texte), assombrissez légèrement la couleur pour l'usage texte (la plupart des marques ont de la flexibilité pour une variante plus sombre), ou changez la couleur du texte du corps du noir à un gris foncé moins dur afin que la couleur de marque se lise comme un accent. Des outils comme Leonardo (d'Adobe) génèrent des variantes accessibles d'une couleur de marque automatiquement ; pairez-les avec cet outil pour la vérification.

Utiliser le contraste comme seule vérification d'accessibilité

Passer le contraste ne garantit pas la lisibilité. Un ratio 4,5:1 est le plancher ; certains utilisateurs (basse vision, perte de sensibilité au contraste liée à l'âge, dyslexie) bénéficient de ratios plus élevés. WCAG CS 1.4.6 (Contraste Amélioré, AAA) recommande 7:1 pour le texte du corps précisément parce que 4,5:1 est le minimum, pas la cible. Combinez un contraste élevé avec une taille de police suffisante (16px+ pour le corps), une hauteur de ligne adéquate (1,5x taille de police), et des choix de police qui préservent les formes de lettre (évitez les poids ultra-fins pour le texte du corps).

Oublier le contraste non-texte (CS 1.4.11)

WCAG 1.4.11 (ajouté dans WCAG 2.1, 2018) exige un contraste 3:1 pour les composants UI et éléments graphiques : bordures de champ de formulaire, contours de bouton, icônes, indicateurs de focus. C'est facile à manquer parce que les designers pensent que le contraste ne s'applique qu'au texte. Un formulaire propre avec des bordures de champ gris subtiles sur blanc peut échouer 1.4.11 même si tout le texte passe 1.4.3. Auditez chaque élément visuel qui transmet du sens ou de l'état, pas seulement le texte sur arrière-plan.

Confondre les règles de grand texte

Le seuil de grand texte de WCAG (3:1 au lieu de 4,5:1) s'applique au texte qui est 18pt ou plus grand (environ 24px), ou 14pt gras (environ 18,66px gras). Tout ce qui est plus petit est texte normal et a besoin de 4,5:1. Les designers appliquent parfois la règle 3:1 grand texte à tous les niveaux de titre, mais un h5 à 16px est texte normal par la définition WCAG. Vérifiez la taille rendue, pas le niveau de titre. Le modificateur gras importe : 18px gras passe comme grand texte ; 18px régulier non.

Se fier à la couleur seule pour transmettre l'information

WCAG 1.4.1 (Utilisation de la Couleur, Niveau A) est séparé du contraste. Même avec des ratios de contraste parfaits, vous ne pouvez pas utiliser la couleur comme seul indicateur d'état (rouge égale invalide, vert égale valide, bleu égale lien). Pairez la couleur avec un second indice : icône (triangle d'avertissement pour les erreurs), motif (soulignement pour les liens), ou étiquette de texte (Requis à côté des champs obligatoires). Les utilisateurs daltoniens (environ 8% des hommes, 0,5% des femmes) et les utilisateurs sur écrans monochromes en niveaux de gris dépendent de ces indices secondaires.

Oublier les états hover, focus et active

Un bouton passe le contraste dans son état par défaut mais le style :hover l'éclaircit sous le seuil ; le contour :focus est un gris subtil qui échoue 3:1 contre l'arrière-plan du bouton ; l'état :active inverse les couleurs et la nouvelle combinaison échoue. Testez chaque état interactif dans votre grille de contraste, pas seulement le défaut. L'indicateur de focus en particulier est critique (CS 2.4.7 Focus Visible, AA) : si le focus n'est pas clairement visible, les utilisateurs clavier seul perdent leur place sur la page.

Confidentialité et gestion des données

Les couleurs que vous ajoutez, les noms de palette, et les tokens exportés restent tous dans votre navigateur. Les calculs de contraste s'exécutent en JavaScript sur votre machine ; rien n'est téléversé. Cela importe moins pour les palettes de couleur que pour les documents mais importe quand même quand la palette fait partie d'un refresh de marque non annoncé ou d'un projet client confidentiel : vous ne voulez pas qu'elle fuite vers un validateur SaaS tiers avant le lancement.

Une fois la page chargée, l'outil fonctionne hors ligne. Vous pouvez vous déconnecter d'internet, construire la palette, exécuter les vérifications et exporter. Les tokens exportés sont téléchargés directement via la boîte de dialogue de sauvegarde normale du navigateur. De nombreux outils de couleur cloud (Coolors, Adobe Color, même certains vérificateurs d'accessibilité) stockent les palettes côté serveur et peuvent les utiliser pour l'analyse ou l'entraînement ; pour le travail confidentiel, préférez les outils côté client.

Quand ne pas utiliser cet outil

Pour la simulation complète de daltonisme (utilisez un outil dédié)

Le contraste n'est pas la même chose que la compatibilité daltonisme. Une palette peut passer toutes les vérifications de contraste et confondre quand même un utilisateur daltonien (rouge et vert à la même luminance se ressemblent identiques pour un deutéranope). Pour la simulation de daltonisme, utilisez le Simulateur de Daltonisme Absolutool ou la vue d'accessibilité d'Adobe Color, les deux appliquent les transformations de couleur réelles de deutéranopie, protanopie et tritanopie. Exécutez les palettes candidates à travers cet outil et un simulateur.

Pour générer des schémas de couleur à partir de zéro (utilisez Leonardo ou Coolors)

Cet outil vérifie et audite les palettes ; il ne les génère pas à partir d'une seule couleur de départ. Pour la génération de palette à partir de zéro (schémas analogues, complémentaires, triadiques, complémentaires divisés), utilisez Adobe Color, Coolors, ou Leonardo (qui génère des variantes accessibles d'une couleur de marque). Générez avec ces outils, puis validez avec celui-ci. Leonardo spécifiquement génère des couleurs ciblées à des ratios de contraste spécifiques, qui est le format d'entrée naturel pour l'étape de vérification de cet outil.

Pour le contraste basé sur APCA (quand WCAG 3 sortira)

Cet outil utilise la formule de contraste WCAG 2.x, qui est la norme légale et industrielle actuelle. Si vous avez spécifiquement besoin de concevoir pour APCA (l'algorithme WCAG 3 proposé), utilisez le Calculateur de Contraste APCA de Myndex Research. APCA produit des évaluations différentes (et probablement plus précises perceptuellement), surtout pour le texte sombre-sur-sombre et clair-sur-clair. Jusqu'à ce que WCAG 3 soit ratifié et adopté dans la loi (probablement plusieurs années dans le futur), WCAG 2.x est ce que les auditeurs de conformité vérifieront.

Pour les audits WCAG complets (utilisez un outil complet)

Le contraste est un critère parmi des dizaines. Pour un audit d'accessibilité complet, utilisez axe DevTools, Lighthouse, WAVE, ou une solution payante comme Tenon ou PowerMapper. Ces outils vérifient le contraste, le texte alt, ARIA, les étiquettes de formulaire, l'ordre de focus, la structure de titre, et bien plus en un seul passage. Utilisez cet outil pendant le design de palette, et les outils complets pendant les tests d'intégration.

Plus de questions

Quelle est la différence entre le contraste AA et AAA ?

AA est la norme, légalement requise par la plupart des lois d'accessibilité (ADA, EAA, AODA, etc.) et ce que chaque site destiné au public devrait respecter. AAA est plus strict : 7:1 pour le texte du corps, 4,5:1 pour le grand texte. AAA n'est généralement requis que pour le contenu à enjeux élevés (sites web gouvernementaux dans certaines juridictions, informations médicales et juridiques, contenu pour utilisateurs avec basse vision comme audience primaire). Concevoir pour AAA est restrictif ; peu de marques peuvent le respecter sans limitations significatives de couleur. Visez AA par défaut et AAA où l'audience du contenu le justifie.

Pourquoi WCAG utilise-t-il 4,5:1 spécifiquement ?

Le seuil 4,5:1 a été choisi pour que le texte reste lisible pour les utilisateurs avec une vision 20/40 (le seuil de la cécité légale dans de nombreuses juridictions) sans grossissement assistif. C'est aussi approximativement le ratio de contraste auquel les utilisateurs avec déficience de vision des couleurs peuvent distinguer de manière fiable le premier plan de l'arrière-plan. Le nombre est calibré empiriquement à partir de la recherche en vision ; il n'est pas arbitraire. Le 7:1 d'AAA correspond approximativement à la vision 20/80, accommodant significativement plus de handicap.

Comment fonctionne la formule de contraste ?

Convertissez chaque couleur de sRGB en luminance relative en utilisant la formule : gamma-corrigez chaque canal (R, G, B) en appliquant une fonction par morceaux (linéaire pour les basses valeurs, exponentielle pour les hautes), puis pondérez par 0,2126 R + 0,7152 G + 0,0722 B (la sensibilité relative de l'oeil humain à chaque canal). Le ratio de contraste entre deux couleurs est (L1 + 0,05) / (L2 + 0,05) où L1 est la luminance plus claire et L2 la plus sombre. Le décalage 0,05 compense la réflexion ambiante de l'écran. Le résultat est un nombre entre 1 (identique) et 21 (max).

Devrais-je me soucier du contraste pour le texte d'espace réservé dans les champs de formulaire ?

Oui. Le texte d'espace réservé compte comme texte sous WCAG et doit respecter le contraste 4,5:1. Le défaut du navigateur pour l'espace réservé est gris clair (#a9a9a9 dans la plupart des navigateurs), qui échoue sur blanc. Remplacez avec CSS : ::placeholder { color: #595959; } ou similaire qui passe AA. Mieux encore, évitez complètement les espaces réservés pour les champs importants ; utilisez des étiquettes visibles au-dessus du champ et réservez les espaces réservés pour le formatage d'exemple. Les motifs d'étiquette flottante combinent l'étiquette visible et la clarté d'exemple.

Le contraste s'applique-t-il aux boutons et champs de formulaire désactivés ?

Non. WCAG CS 1.4.3 exempte explicitement les contrôles désactivés parce que l'apparence atténuée est elle-même un signal visuel que le contrôle est indisponible. Les boutons désactivés sont typiquement estompés à environ 38% d'opacité et échoueraient le contraste dans leur état désactivé par conception. Cependant, l'état désactivé doit toujours être clairement distinguable de l'état activé, donc ne supprimez pas simplement tout traitement visuel ; utilisez une différence visuelle claire plus un attribut désactivé accessible au lecteur d'écran.

Qu'en est-il du contraste pour le contenu graphique comme les graphiques et icônes ?

WCAG 1.4.11 Contraste Non-texte (ajouté dans 2.1) exige un contraste 3:1 pour les composants UI (boutons, bordures de formulaire, indicateurs de focus) et les éléments graphiques significatifs (icônes qui transmettent un état, éléments de graphique qui distinguent les séries de données). Le seuil 3:1 est plus bas que 4,5:1 pour le texte parce que les graphiques ont généralement des zones visibles plus grandes. Les graphiques décoratifs qui ne transmettent pas de sens sont exemptés. Appliquez 3:1 à chaque icône qui transmet un état (oeil ouvert pour visible, X pour supprimer, coche pour sélectionné) et chaque segment de graphique qui doit être distinguable.