Dark-Mode-Kontrast: Fallstricke

Nimm die Vordergrundfarben eines Light-Themes, dem du vertraust — das Markenblau, beide Text-Grautöne, das Off-White, das nie zum Einsatz kommt, reines Weiß — und miss jede davon erneut gegen eine fast schwarze Seite statt gegen eine weiße. Die Zahlen verschlechtern sich nicht gleichmäßig; sie ordnen sich neu. Der Sekundärtext-Grauton, der mit reichlich Spielraum bestanden hat, fällt auf ≈2,5:1. Das Markenblau, das die Buttons getragen hat, sinkt auf ≈3,3:1. Und die beiden Werte, die auf Weiß unbrauchbar waren — Off-White und reines Weiß — liefern die stärksten Ergebnisse in der Spalte.

Dark-Mode-Kontrast läuft auf denselben Untergrenzen — 4,5:1 für Fließtext, 3:1 für großen Text und UI-Komponenten — aber die Geografie der Fehler verschiebt sich: Werte mittlerer Helligkeit, die auf Weiß Spielraum hatten, brechen gegen Fast-Schwarz ein, gesättigte Markenfarben sinken unter die Untergrenzen, und der nutzbare Bereich für Text wird von unten durch die nötige Abgrenzung und von oben durch Blendung eingeengt. Jede Paarung muss auf dem dunklen Grund neu gemessen und mit Blick auf die Polarität gelesen werden, denn das Verhältnis allein kann nicht erkennen, welche Seite der Text ist. Dieser Artikel kartiert, wohin sich die Fehler verlagern; wie eine dunkle Palette so hergeleitet wird, dass ihre Werte bereits vorgeprüft ankommen, ist das größere Thema unseres Dark-Mode-Leitfadens.

Ändern sich die WCAG-Kontrastanforderungen im Dark Mode?

Nein. WCAGs Kontrastminimum verlangt dieselben 4,5:1 für Fließtext und 3:1 für großen Text und Interface-Komponenten, egal welches Theme gerade angezeigt wird. Die Formel ist symmetrisch — sie teilt die hellere Leuchtdichte durch die dunklere und vergleicht das Ergebnis mit der Untergrenze — sie weiß also nicht und kümmert sich nicht darum, dass die Seite dunkel geworden ist.

Was sich ändert, ist, welche deiner Werte die Latte noch überspringen. Diese Menge erweist sich als fast das Gegenteil der des Light-Themes — weshalb ein Dark-Theme fast nichts von den Prüfungen des Light-Themes erbt: nicht weil der Standard strenger wurde, sondern weil sich beide Seiten jeder Paarung bewegt haben.

Warum scheitern Mitteltöne auf dunklen Hintergründen?

Weil auf einer dunklen Seite der Text alles Licht selbst mitbringen muss. Auf Weiß liefert der Grund den Kontrast — seine Leuchtdichte ist nahezu maximal, also besteht jeder ausreichend dunkle Vordergrund, und die infrage kommenden Werte breiten sich über die halbe Helligkeitsskala aus. Gegen Fast-Schwarz kehren sich die Rollen um: Die Seite trägt fast nichts bei, das Verhältnis wird von der eigenen Leuchtdichte des Vordergrunds bestimmt, und die Leuchtdichte fällt durch die Mitte des Helligkeitsbereichs steil ab. Ein Mittelton strahlt schlicht nicht genug ab, um sich abzuheben.

Die Arithmetik für neutrale Grautöne macht die Einengung greifbar. Auf einer weißen Seite besteht ein Grauton Fließtext bei jeder Helligkeit bis zu L ≈0,57 in OKLCH — alles von Schwarz bis Mittelgrau funktioniert. Auf einer fast schwarzen Seite bei L ≈0,22 braucht ein Grauton L ≈0,61 oder höher, um 4,5:1 zu erreichen, und das komfortable Ende hört bei etwa L ≈0,9–0,95 auf, wo die Blendung übernimmt. Das bestehende Band schrumpft um rund die Hälfte und verlagert sich vollständig ans helle Ende — und die beiden Bänder überlappen sich nicht: Gegen diese beiden Gründe kann kein einzelner Neutralton in beiden Themes Fließtext tragen.

Wo bestehen und scheitern dieselben Farben?

Fünf Vordergründe, zwei Gründe. Die helle Seite ist weiß; die dunkle Seite ist oklch(0.22 0.015 262.9) ≈ #171B22, ein Fast-Schwarz der Klasse neutral-900.

Die Blau-Zeile ist die, die Teams überrascht. #2563eb ist oklch(0.546 0.215 262.9): kräftig, gesättigt — und mittlerer Helligkeit. Sättigung fügt keine Leuchtdichte hinzu, also kann eine Farbe so intensiv sein, wie der Farbraum (Gamut) es erlaubt, und trotzdem in der Mitte der Skala sitzen — genau dort, wo dunkle Gründe unnachgiebig sind. Das Blau, das die Buttons verankert hat und auf Weiß als Text bestand, kommt auf Fast-Schwarz als Wert an, der Fließtext nicht regelkonform tragen kann. Das ist kein Fehler der Farbe; es ist die Geografie, die sich unter ihr verschiebt.

Öffne diese Paarungen im Scale Composer — dieselben fünf Vordergründe gegen die dunkle Seite geprüft, jeweils mit ihrem WCAG-Verhältnis und ihrem APCA-Wert nebeneinander, die scheiternden Zeilen gegen ihre Untergrenzen markiert.

Ist Hell-auf-Dunkel derselbe Kontrast wie Dunkel-auf-Hell?

Nicht fürs Auge. Das WCAG-Verhältnis ist konstruktionsbedingt polaritätsblind — vertausche Text und Hintergrund, und die Zahl ist identisch — aber die Wahrnehmung ist nicht symmetrisch. Bei gleichem gemessenem Verhältnis liest sich heller Text auf dunklem Grund meist stärker: Helle Striche strahlen in das dunkle Feld hinein, statt von ihm eingefasst zu werden. Derselbe Effekt setzt dünner Schrift zu — das Leuchten frisst haarfeine Striche — weshalb Dark-Themes oft eine etwas kräftigere Textstärke wollen, als ihre gemessenen Verhältnisse nahelegen.

APCA, das aufkommende Kontrastmodell, bewertet die Polarität ausdrücklich: Es nutzt für jede Richtung unterschiedliche Kurven und versieht Hell-auf-Dunkel-Ergebnisse mit einem negativen Vorzeichen. Die beiden Modelle können sich über die Reihenfolge uneinig sein, nicht nur über die Größenordnung. Der Sekundärtext des Light-Themes von oben — der L ≈0,47-Grauton auf Weiß — misst ≈6,8:1 und erreicht in APCA ≈Lc 84. Der Sekundärtext des Dark-Themes — der L ≈0,78-Grauton auf Fast-Schwarz — misst ≈8,6:1, ein höheres Verhältnis, erreicht aber ≈Lc 62, deutlich niedriger. Das Verhältnis stuft die dunkle Paarung als stärker ein; APCA stuft sie als schwächer ein. Keine der Zahlen ist ein Fehler — sie modellieren Unterschiedliches — und APCA ist heute eher ein Instrument von Forschungsqualität als eine Konformitätsanforderung. Das spricht dafür, beide zu lesen, und deshalb gibt der Scale Composer APCA neben jedem WCAG-Verhältnis aus, das er prüft.

Kann ein Dark-Theme zu viel Kontrast haben?

Ab einem gewissen Punkt ja — im Dark Mode hört „mehr Kontrast ist besser” auf, anschaulich wahr zu sein. Reines Weiß auf Fast-Schwarz überspringt jede Untergrenze bei ≈17:1, und genau dieser Überschuss ist das Problem: Striche hoher Leuchtdichte auf dunklem Feld neigen dazu, auszublühen und zu halonieren — ein Effekt, der häufig als schlimmer bei Nacht und für Leser mit Astigmatismus beschrieben wird. Ein Off-White um L ≈0,9 misst immer noch ≈13:1 — fast das Dreifache der Fließtext-Untergrenze — und liest sich ruhiger. Die Untergrenzen sind Untergrenzen, keine Zielwerte; nichts im Standard belohnt die letzten vier Verhältnispunkte, und das Auge stellt sie in Rechnung.

Gilt die Ausnahme für deaktivierten Text weiterhin?

Ja — deaktivierte Bedienelemente und inaktive Elemente tragen in keinem Theme eine Kontrastanforderung. Was sich ändert, ist, wie schnell „gedimmt” in „verschwunden” übergeht. Nahe einer dunklen Seite sind die Nenner winzig, also lassen kleine Helligkeitsschritte das Verhältnis stark ausschlagen: Ein deaktivierter Grauton bei L ≈0,45 liegt bei ≈2,3:1 — matt, aber auffindbar — während ein Absenken auf L ≈0,38 nur noch ≈1,7:1 lässt, was die meisten Augen auf einem dunklen Bildschirm schlicht übersehen. Auf Weiß fällt dieselbe Drift von 0,07 L kaum ins Gewicht. Deaktivierte und Platzhalter-Werte auf Dunkel sollte man bewusst wählen, statt sie zu erben — Ausnahme hin oder her.

Prüfe die Geografie neu, nicht die Gewohnheit

Die Gewohnheiten, die eine helle Palette bestehen ließen, sind genau die, die hier scheitern — weshalb die Prüfung auf den dunklen Werten selbst laufen muss. Vergleiche WCAG und APCA über eine dunkle Palette hinweg — jede Text- und UI-Paarung neu auf dem dunklen Grund gemessen, beide Zahlen nebeneinander, damit die Paarungen, die in der Tabelle oben die Plätze getauscht haben, in deinen eigenen Farben sichtbar werden, bevor sie in Produktion gehen.