KIT-code-maker/color-system

Farbsystem

Übersicht

Eine kuratierte Sammlung gebrauchsfertiger Farbpaletten (Hell + Dunkel) für vier Bereiche – Web-App-UI, Marketing/Landingpages, Datenvisualisierung und Terminal/TUI – sowie die Methodik, um neue Paletten zu erstellen und ihre Barrierefreiheit zu überprüfen.

Kernprinzip: Wähle Farben nach semantischer Rolle (Hintergrund, Text, Primärfarbe, Fehler …), nicht nach rohem Farbton. Jede Palette hier bildet Hex-Codes auf Rollen ab, sodass ein Theme austauschbar, konsistent und zugänglich bleibt. Wähle zuerst eine Rolle, dann lies ihren Hex-Code ab – einen Hex-Code dort fest zu codieren, wo eine Rolle hingehört, ist das, was später Theming zerstört.

Navigation

Das Inhaltsverzeichnis und der Rollenvertrag unten beantworten von selbst „welche Palette“. Lade genau die Referenzdatei, die für die Aufgabe benötigt wird – nicht alle vier.

Laden	Wann
references/carbon.md	Wenn eine Seite oder ein Artefakt erstellt wird, das Carbon verwenden muss – nur diese Datei lesen; sie enthält Carbons Rollen, Dashboard-Kit und Triaden in beiden Modi
references/palettes.md	Du benötigst Hex-Werte für jede andere Palette – die vier Bereiche, Hell + Dunkel; die Fill/Subtle/Emphasis-Triaden; die 12-stufigen Skalen hinter Dusk, Driftwood und Meadow
references/contrast.md	Zum Überprüfen von WCAG/APCA-Schwellenwerten, Farbenblindheitssicherheit oder zum Debuggen eines Paares, das nicht funktioniert
references/build-your-own.md	Wenn keine Bibliothekspalette passt und du eine neue Skala generierst (das OKLCH-Rezept)
references/theory.md	Zum Auswählen eines Harmonieschemas oder zur Begründung einer Farbraum-/Skalenentscheidung

Palettenbibliothek (Kurzkatalog)

Wo eine Palette der erste richtige Griff ist, ist sie mit ⭐ markiert; Marketing und TUI haben keine Standardauswahl, da die Wahl der Marke oder dem eigenen Terminal-Theme des Benutzers folgt.

Web-App-UI – Hell + Dunkel, 13 semantische Rollen + eine Triade pro Farbe

• Carbon ⭐ (Standard) – tiefes Schieferblau, dunkel zuerst. Analyse-Dashboards, Leistungsberichte und Entwickler-Tools. Enthält ein vollständiges Dashboard-Kit (A–F-Noten-Pills, geordnete Stufenabfolge, Inline-Code-Ton, Erfolgshervorhebung). Greife stattdessen zu Graphite, wenn der Hellmodus handoptimiert gleichwertig sein muss.
• Graphite – kühles Schiefer + Blau. Dichte B2B-Dashboards, Entwickler-Tools; die Hell+Dunkel-Paritäts-Standardpalette.
• Evergreen – smaragdgrüne Marke auf echt-neutralem Zink. Frisch, selbstbewusst, nicht-blau.
• Terracotta – warme Lehm-/Espresso-Neutraltöne + Rost. Redaktionell, Content-Plattformen, Schreibwerkzeuge.
• Bloom – pastellfarbenes Immergrün/Violett, tiefer Dunkelmodus. Freundliche Entwickler-Tools, verspielte, aber saubere Apps.
• Teal Slate – tiefes Blaugrün auf kühlem Schiefer, einzelner warmer Akzent. Technische Berichte, SRE-/Ratenbegrenzungs-Dashboards; passt zu einer serifenlosen Schrift für Zahlen.

Generiert aus 12-stufigen OKLCH-Skalen, die zusammen mit ihren Rollen ausgeliefert werden, sodass sie erweitert oder neu abgeleitet werden können:

• Dusk – Indigo-Primärfarbe, Türkis-Akzent, nahezu neutrale kühle Grautöne. Fokus-Tools, Editoren, Apps für lange Sitzungen.
• Driftwood – tief marineblaue Primärfarbe auf warmen Sand-Neutraltönen, Lehm-Akzent. Diejenige, die im Dunkelmodus ihre Neutraltöne auf kühl schwenkt.
• Meadow – gedämpfter Salbei-Primärton, Altgold-Akzent, warme Knochen-Neutraltöne. Die weichste der Reihe; beruhigend statt selbstbewusst.

Marketing / Landingpages – Hell + Dunkel, Hero-Verläufe

• Sunbloom – verfeinerte Korallen-/Bernstein-Wärme. Zugängliche Verbraucher-/Kreativ-Marken.
• Tidewater – Blaugrün/Salbei. Fintech, Wellness, B2B-Vertrauen.
• Obsidian & Gold – nahezu Schwarz + metallisches Gold. Premium, Luxus, Agentur.
• Paper & Ink – warmes Papier + Tintenschwarz + ein Terrakotta-Akzent. Blogs, lange Texte, Portfolios.

Datenvisualisierung – farbenblindensicher, warm/kühl erdig

• Kategorial: Lunar Valley ⭐ (Standard) · Hearthstead · Vintage Warm · Glass Wall · Okabe-Ito (verwenden, wenn CVD-Sicherheit eine harte Anforderung ist)
• Sequenziell: Viridis ⭐ (Standard) · Magma · Inferno · Plasma · ColorBrewer Blues · YlOrRd (alle wahrnehmungsuniform)
• Divergierend: Console & Window ⭐ (Standard) · Alien Sun · Orchard Dusk · Coffee & Coolant – alle warm↔kühl, kein rot↔grün

Terminal / TUI – 16-ANSI + bg/fg/cursor/selection

• Solarized Dark · Nord · Catppuccin Mocha · Catppuccin Latte (das eine helle Schema) · Dracula · Tokyo Night

→ Vollständige Hex-Tabellen: Carbon in references/carbon.md, alle anderen Paletten in references/palettes.md

Semantische Rollen (der Vertrag)

UI-Paletten füllen diese Rollen aus. Ordne die Absicht einer Rolle zu, dann die Rolle einem Hex-Code.

Rolle	Was es ist
background	App-/Seiten-Basis-Leinwand
surface	Karten, Panels, Blätter
surface-elevated	Erhöhte Oberflächen (Popovers, Modals); im Dunkelmodus heller = höher
border	Trennlinien, Eingaberahmen, Fokusringe
text-primary	Vordergrund mit hoher Betonung
text-secondary	Gedämpfte Labels, Hinweise, Beschriftungen
primary / primary-hover	Markenaktionsfarbe + ihr Hover-Zustand
accent	Sekundäre Betonung, unterscheidbar von primary
success / warning / error / info	Semantische Zustände (Grün / Bernstein / Rot / Blau nach westlicher Konvention)

Jede farbige Rolle benötigt dann eine Triade, weil ein Hex-Code nicht drei Aufgaben erfüllen kann. Ein Wert, der erstellt wurde, um darauf zu sitzen, ist nicht automatisch als Text lesbar, und eine vollflächige Füllung ist als Badge-Hintergrund bei Tabellendichte viel zu laut.

Token	Aufgabe	Bootstrap 5.3 nennt es	Material 3 nennt es
{c}-fill + {c}-on-fill	Buttons, aktive Chips	--bs-{c} + color-contrast()	primary + on-primary
{c}-subtle + {c}-emphasis	Badge-/Callout-Hintergrund + sein Label	--bs-{c}-bg-subtle + -text-emphasis	primary-container + on-primary-container
{c}-subtle-border	Rahmen um diesen Hintergrund	--bs-{c}-border-subtle	—
link	Der Markenfarbton als Text auf surface	(getrennt in v6)	—

Gebrauchsfertige Triaden für alle neun UI-Paletten befinden sich in palettes.md, außer Carbons, die in carbon.md sind. Dunkelmodus-Füllungen sind helle Farbtöne, daher sind ihre Labels das dunkelste Neutrale der Palette, nicht Weiß.

Datenvisualisierungspaletten stellen stattdessen geordnete Farb-listen bereit (kategorial = unterschiedliche Reihen; sequenziell = niedrig→hoch Rampe; divergierend = warm↔kühl mit einem neutralen Mittelpunkt). TUI-Schemata bieten die 16 ANSI-Slots plus 4 spezielle Rollen.

Kernkonzepte

• Entwerfe in OKLCH, nicht HSL. OKLCH ist wahrnehmungsuniform; HSL-„Helligkeit“ lügt (gleichhelles Blau sieht viel dunkler aus als gleichhelles Gelb), sodass selbst gleichmäßige HSL-Schritte ungleichmäßige Skalen erzeugen.
• Harmonie: Wähle ein Schema (monochromatisch / analog / komplementär / triadisch …) und lass eine Farbe in Sättigung und Fläche dominieren; entsättige den Rest.
• Skalen: 10–12 Schritte, Schritt-Helligkeit gleichmäßig, Chroma in der Mitte am höchsten und an den Extremen auslaufend, sodass Tönungen nicht ausgewaschen und Schattierungen nicht schlammig sind.
• Kontrast: WCAG AA – Fließtext ≥ 4,5:1, große Schrift & UI/Rahmen ≥ 3:1.
• Hell vs. Dunkel ist keine Umkehrung, und WCAG 2-Verhältnisse überschätzen den Kontrast nahe Schwarz. Beide Fehlermodi und ihre Behebungen sind unten in „Fallstricke“ beschrieben; Schwellenwerte und die APCA-Prozedur sind in references/contrast.md.
• Farbenblindensicherheit: Kodiere Bedeutung mit Text, Symbol oder Position zusätzlich zum Farbton, da ~8 % der Männer die Farbtöne allein nicht unterscheiden können. Verwende für divergierende Daten warm↔kühl (Blau/Orange, Blaugrün/Rosa) anstelle von rot↔grün.

Beispiele

Beispiel: Farben für ein SaaS-Dashboard auswählen

✅ Erwünscht

Benutzer: "Ich brauche Farben für ein Admin-Dashboard, Hell und Dunkel."
→ Empfehle Carbon (tiefes Schieferblau, dunkel zuerst, gemacht für dichte Daten-UI) – die Standardpalette;
  biete Graphite an, wenn handoptimierte Hellmodus-Parität wichtiger ist als das Dashboard-Kit.
→ Kopiere seine Rolle→Hex-Tabelle aus carbon.md (beide Modi).
→ Wende nach Rolle an: background→surface→border→text, primary für den Haupt-CTA,
  success/warning/error für Status-Badges. Bestätige text-primary auf background ≥ 4,5:1.

❌ Anti-Pattern

→ Wähle vier Farbtöne aus einer Coolors-Palette und weise sie ad hoc zu: #2b2d42 nav, #8d99ae text,
  #edf2f4 background, #ef233c Buttons. Dunkelmodus = invertiere die Hex-Codes.

Warum es funktioniert: Eine rollenzugeordnete Palette lässt sich direkt in CSS-Variablen übernehmen und ist von Natur aus barrierefrei. Die Ad-hoc-Version hat keine neutrale Rampe, keine Abstufungen, keine Statusfarben, und das Invertieren einer Hell-Palette erzeugt reine schwarze Oberflächen und ausgewaschene Markenfarbtöne (siehe Fallstricke: Hell vs. Dunkel ist keine Umkehrung).

Beispiel: Status-Badge-Farbe

✅ Erwünscht

.badge-error { background: var(--error); color: #fff; }   /* Rolle, kein hartcodiertes Rot */

❌ Anti-Pattern

.badge-error { background: #ff0000; color: #000; }   /* roher Farbton; #f00 auf #000 ≈ 5,2:1, blendet aber
                                                         und funktioniert weder mit Theming noch im Dunkelmodus */

Warum es scheitert: Das Hartcodieren eines Farbtons zerstört Theming und Dunkelmodus, und reines Rot/reines Schwarz verursacht Halation.

Beispiel: Eine Diagrammpalette auswählen

✅ Erwünscht

Kategoriale Reihe (≤8) → Lunar Valley (Standard) oder Okabe-Ito, wenn CVD-Sicherheit erforderlich ist.
Kontinuierlich niedrig→hoch → Viridis (wahrnehmungsuniform, farbenblindensicher).
Signierte Daten mit einem Mittelpunkt → Console & Window (warm↔kühl, neutrales Zentrum).
Bei mehr als ~8 kategorialen Farben sind die Reihen nicht mehr unterscheidbar – fasse sie stattdessen unter "Sonstige" zusammen.

❌ Anti-Pattern

Zwölf kategoriale Reihen gefärbt mit den success/warning/error/info-Rollen der UI-Palette plus
Markentönen; Gewinn/Verlust grün↔rot ohne Labels codiert.

Warum es funktioniert: Es passt die Datenstruktur an die richtige Palettenfamilie an und respektiert die Unterscheidbarkeitsgrenze. Das Anti-Pattern verwendet UI-Status-Rollen wieder, die mit der Serienidentität kollidieren, überschreitet die ~8-Farbton-Grenze und codiert rot↔grün ohne Text- oder Symbol-Backup für farbenblinde Betrachter.

Fallstricke

• Symptom: Markenfarbe ist als Fließtext nicht lesbar. Ursache: Gesättigte Mitteltöne (Bernstein, Koralle, Blaugrün) erfüllen oft 4,5:1 auf ihrem eigenen Hintergrund nicht – eine Füllfarbe und eine Textfarbe sind unterschiedliche Schritte derselben Rampe. Behebung: behalte fill und link als separate Werte; setze den Text einen Schritt dunkler, bis er den Wert erreicht. In dieser Bibliothek weicht nur Evergreen light ab (#059669 trägt ein Button-Label bei 4,70:1, erreicht aber 3,77:1 als Link auf Weiß, daher ist sein link #00875b), was genau der Grund ist, warum die Trennung übersehen wird.
• Symptom: Status-Badges sehen korrekt aus, schreien aber bei Tabellendichte. Ursache: Ein vollflächiger --error-Hintergrund hinter weißem Text ist für einen Button richtig und für ein Badge auf Zeilenebene viel zu laut. Behebung: verwende den {c}-subtle-Hintergrund mit seinem dazugehörigen {c}-emphasis-Label. Die Wiederverwendung des Status-Farbtons als eigenes Label auf dieser Tönung verfehlt 4,5:1 häufiger, als nicht – nimm den zugehörigen Wert aus palettes.md (Carbons aus carbon.md), anstatt anzunehmen.
• Symptom: Eine aus einer 12-stufigen Skala generierte Palette erfüllt den Kontrast immer noch nicht. Ursache: Die Schrittkarte ist keine Kontrastgarantie. Radix garantiert die Schritte 11 und 12 gegen Schritt 2 und sonst nichts; Schritt 9 trägt selten ein 4,5:1-Button-Label, und Schritt 8 erreicht selten 3:1 als Steuerungskante. Behebung: löse diese beiden gegen ihren tatsächlichen Hintergrund. Gehe im Hellmodus ein weißes Label ein und setze die Füllung dunkler – die Lösung in Richtung des Labels, das bereits höher bewertet wird, erzeugt einen blassen, bestandenen, aber schwach wirkenden Farbton.
• Symptom: Eine Palette, die im Hellmodus richtig aussieht, wirkt im Dunkelmodus schlammig. Ursache: Der neutrale Farbton wurde einmal ausgewählt und vererbt. Ein warmer Farbton, der bei hoher Helligkeit wie Papier aussieht, wirkt bei geringer Helligkeit wie Braun. Behebung: entscheide den neutralen Farbton und die Chroma pro Modus neu; bei sehr niedriger Chroma auf kühl zu schwenken, ist die übliche Antwort. Driftwood in palettes.md macht dies (Farbton 64 hell, 224 dunkel); Meadows Salbei benötigte es nicht.
• Symptom: Eine Palette, die von Color Hunt, Coolors oder einem Trendartikel kopiert wurde, kann keine Benutzeroberfläche erstellen. Ursache: Galeriepaletten sind vier dekorative Farbtöne ohne neutrale Rampe, ohne dunkle Tinte und ohne Zustände – 16 der 30 meistgemochten Color-Hunt-Paletten können mit keinem ihrer Farbpaare 4,5:1-Fließtext tragen. Behebung: nimm die Farbtöne als Ausgangsmaterial und erstelle Skalen daraus (build-your-own.md); Dusk, Driftwood und Meadow wurden so erstellt.
• Symptom: Sekundärer/gedämpfter Text („abgedunkelt“, text-secondary) sieht im Design-Tool gut aus, erfüllt aber in der App den Kontrast nicht. Ursache: Komponentenbibliotheken liefern eine Standard-Gedämpft-Textfarbe (z. B. Mantine's dimmed), die für visuelle Hierarchie und nicht für Kontrast optimiert ist – meistens bei etwa ~3,4:1 liegend, weit unter der 4,5:1-AA-Schwelle. Behebung: wähle deinen eigenen text-secondary-Hex-Code aus und überprüfe ihn gegen contrast.md, anstatt den Standard der Bibliothek zu übernehmen, und überprüfe pro Theme erneut – derselbe Überschreibwert kann in einem Theme bestehen und in einem anderen durchfallen. Überprüfe auch auf getönten/erhöhten Oberflächen (Karten, gestreifte Zeilen) nach, nicht nur auf der flachen Leinwand.
• Symptom: Der Dunkelmodus „erfüllt WCAG“, ist aber schwer zu lesen. Ursache: Die WCAG 2-Mathematik überschätzt den Kontrast nahe Schwarz. Behebung: überprüfe dunkle Paare mit APCA (Lc), nicht allein mit dem 4,5:1-Verhältnis.
• Symptom: Das dunkle Thema wirkt flach, die Abstufung unlesbar. Ursache: Reiner #000-Hintergrund + gleich helle Oberflächen. Behebung: hebe die Basis auf etwa #0d1117–#1e1e2e an und mache jede Abstufungsebene heller.
• Symptom: Ein Diagramm ist für farbenblinde Betrachter nicht lesbar. Ursache: Rot↔grün-Kodierung oder reine Farbtonbedeutung. Behebung: wechsle zu einer warm↔kühl divergierenden Palette und füge Labels/Symbole hinzu; verwende für kategoriale Daten den Okabe-Ito-Sicherheitssatz (in palettes.md).
• Symptom: Diagrammtext bleibt kontrastarm, obwohl deine Palette die richtige Textfarbe definiert. Ursache: Diagrammbibliotheken (Recharts, Mantine charts) rendern Achsen-/Legenden-/Werttexte als SVG mit eigenem Inline-fill, das deine Farb-Tokens umgeht. Behebung: ziele direkt auf die Textelemente der Bibliothek (z. B. .recharts-wrapper text { fill: var(--text) }) – die CSS-Kaskade erreicht sie nie.
• Symptom: TUI-Farben verschwinden auf manchen Terminals. Ursache: Hartcodierter Hex-Code oder tragender Text in hellschwarz (Slot 8). Behebung: binde Bedeutung an ANSI-Slots 1–6, damit das eigene Theme des Benutzers sie rendert, und behalte Slot 8 nur für Abschwächung.
• Symptom: Palettenschritte wirken klumpig/ungleichmäßig. Ursache: Helligkeitsschritte in HSL/RGB. Behebung: erstelle die Skala in OKLCH neu (build-your-own.md).
• Symptom: Die geteilten Werte fill und link einer Palette unterscheiden sich farblich. Ursache: Sie sollen unterschiedliche Helligkeitsschritte derselben Farbe sein, aber eine Division durch eine Konstante erzeugt nicht den richtigen Kontrast. Behebung: behandle sie als unabhängige Variablen; erfülle die untere Kontrastschwelle für Füllung und die obere für Links. Die link-Werte in palettes.md sind genau das.
• Symptom: Eine Palette erfüllt den Kontrast auf weißem Hintergrund, nicht aber auf farbigen Surface-Karten. Ursache: Die Oberflächentönung reicht aus, um die Leuchtdichte unter den Schwellenwert zu senken. Behebung: validiere auf dem aufgehellten/abgedunkelten surface und verwende für Karten die surface-elevated-Rolle, wo verfügbar.
• Symptom: Der background-Wert einer Hell-Palette sieht in der Vorschau identisch mit surface aus. Ursache: Im Hellmodus liegen sie absichtlich nahe beieinander (gleiche Basis); überprüfe im Dunkelmodus, wo die Trennung klar ist.
• Symptom: Die error-Farbe wird auf der roten Badge-Tönung unlesbar. Ursache: {c}-emphasis auf {c}-subtle durchläuft dieselbe Kontrastlogik – überprüfe diesen Fehlermodus immer am Paar. Behebung: nimm das zugehörige {c}-emphasis aus palettes.md; nimm niemals an, dass derselbe Farbton funktioniert, indem du ihn abdunkelst.
• Symptom: Verlaufsfarben in Marketing-Paletten sehen flach aus. Ursache: Die beiden Stopps sind zu nah in Helligkeit oder Farbton. Behebung: halte mindestens 20 Helligkeitsschritte im Abstand und verwende komplementäre oder analag getrennte Farbtöne.
• Symptom: Ein am Terminal gerendertes Dashboard verwendet die Farben des UI-Themes anstelle der TUI-Palette. Ursache: Terminal-Paletten sind 16-Farben-Slots; etwas als --primary für UI und %{P-1}% für TUI zu definieren, kollidiert. Behebung: wende die TUI-Palette nur auf die Terminal-Darstellungsschicht an – sie macht nicht denselben Job wie die Web-Palette.
• Symptom: Das Auswählen einer Palette aus einer Liste von Zehn führt zu Entscheidungslähmung bei Teammitgliedern, die Farben nicht priorisieren. Ursache: Eine Reihe ähnlich guter Optionen ohne Empfehlung. Behebung: die ⭐-Standardpaletten schließen die Entscheidung kurz, indem sie die häufigste Wahl auswählen. Überschreibe sie in der Konfiguration; das Skill wird sie nicht überschreiben.