Dark Mode nachträglich einbauen: Warum mein Admin-Panel unlesbar war

Als ich mein Admin-Panel zum ersten Mal ernsthaft im Dark Mode getestet habe, war ich ziemlich ernüchtert. Im hellen Design sah alles gut aus. Sobald ich aber auf das dunkle Design umgeschaltet habe, waren Überschriften wie „Berufserfahrung“ kaum noch zu erkennen: dunkelgrauer Text auf fast schwarzem Hintergrund. Auch Tabelleninhalte, Hinweise und einige Icons ließen sich nur mit Mühe lesen.

In diesem Beitrag beschreibe ich, warum das passiert ist, was ich über Kontrast im Dark Mode gelernt habe und wie ich das Problem mit zentral definierten Farben gelöst habe.

Die Ursache: Farben, die nichts vom Dark Mode wissen

Zuerst dachte ich, ich hätte irgendwo eine Farbe vergessen. Nach etwas Recherche war klar: Das ist eines der häufigsten Probleme, wenn man einen Dark Mode nachträglich in ein bestehendes Projekt einbaut. Bei mir lag es an zwei Stellen:

• Mein Admin-Panel basiert auf einem älteren Template mit Bootstrap 4. Dort sind viele Textfarben fest im CSS hinterlegt, zum Beispiel für Kartenüberschriften, Tabellen oder Formularbeschriftungen. Diese Farben gelten immer – egal, welches Design gerade aktiv ist.
• Zusätzlich hatte ich in meinen Views über die Zeit viele Farben direkt als Hex-Werte oder Inline-Styles eingetragen. Jede einzelne davon ignoriert das Design.

Was ich über Kontrast gelernt habe

Bei meiner Recherche habe ich mehrere Leitfäden zu barrierefreien dunklen Oberflächen gelesen (Quellen unten). Vier Punkte haben meine Sichtweise verändert:

1. Ein Dark Mode ist nicht automatisch barrierefrei. Auch im dunklen Design gelten die WCAG-Regeln: mindestens 4,5:1 Kontrast für normalen Text und 3:1 für Icons, Rahmen von Eingabefeldern und andere Bedienelemente.
2. Kein reines Weiß auf reinem Schwarz. Maximaler Kontrast wirkt auf dunklem Hintergrund schnell grell. Besser sind ein leicht abgedunkeltes Weiß für Text und ein sehr dunkles Grau statt Schwarz.
3. Markenfarben brauchen eine eigene dunkle Variante. Mein Lila sieht auf Weiß gut aus, ist auf dunklem Grund aber zu dunkel. Für den Dark Mode nehme ich deshalb eine hellere Variante.
4. Farben gehören an eine zentrale Stelle. Statt Farben überall im Code zu verteilen, definiert man sie einmal als Variablen mit einer Bedeutung, sogenannte Design Tokens.

Meine Lösung: Design Tokens als CSS-Variablen

Statt jede Seite einzeln umzufärben, definiere ich alle Farben einmal – getrennt für Hell und Dunkel. Hier eine vereinfachte Version:

:root[data-theme="dark"] {
  color-scheme: dark;
  --bg: #0B0B0F;
  --surface: #141419;
  --text: #E5E7EB;      /* Haupttext, gut lesbar */
  --text-2: #A1A1AA;    /* Nebentext */
  --accent: #A78BFA;    /* hellere Lila-Variante */
}

:root[data-theme="light"] {
  color-scheme: light;
  --bg: #F6F7FB;
  --surface: #FFFFFF;
  --text: #18181B;
  --text-2: #52525B;
  --accent: #6D28D9;
}

Im übrigen CSS verwende ich dann nur noch die Variablen, zum Beispiel color: var(--text). Wechselt das Design, ändern sich alle Farben auf einmal.

Die Zeile color-scheme war für mich eine kleine Entdeckung: Damit passen sich auch Elemente des Browsers wie Scrollbalken, Checkboxen oder Datumsfelder automatisch an das helle oder dunkle Design an.

Eine „Brücke“ zum alten Bootstrap-CSS

Das alte Template wollte ich nicht umschreiben. Deshalb lade ich ganz zum Schluss eine eigene CSS-Datei, die die festen Farben von Bootstrap mit meinen Variablen überschreibt:

:root[data-theme="dark"] .card-header h4,
:root[data-theme="dark"] .table td,
:root[data-theme="dark"] label {
  color: var(--text);
}

Weil diese Datei als letzte geladen wird, gewinnt sie gegen die Regeln aus dem Template. So reagieren alle Seiten auf den Dark Mode, ohne dass ich das Template anfassen muss. Die fest eingetragenen Farben in meinen Views ersetze ich nach und nach durch wiederverwendbare Klassen.

Wie ich den Kontrast jetzt prüfe

Früher habe ich Farben nach Gefühl ausgewählt. Heute prüfe ich sie: In den Chrome DevTools zeigt der Farbwähler bei einer Textfarbe direkt das Kontrastverhältnis zum Hintergrund an und markiert, ob die WCAG-Werte erreicht werden. Das dauert nur ein paar Sekunden und verhindert genau die Fehler, die ich am Anfang gemacht habe.

Fazit

Mitgenommen habe ich vor allem drei Dinge:

• Farben zentral verwalten, statt sie im Code zu verstreuen.
• Kontrast messen, statt nur nach Gefühl zu entscheiden.
• Beide Designs testen – nicht nur das, in dem man selbst arbeitet.

Gleichzeitig war es beruhigend zu sehen, dass ich mit diesem Problem nicht allein bin. Viele Entwicklerinnen und Entwickler stoßen genau darauf, und die Lösungen sind gut dokumentiert, wenn man weiß, wonach man suchen muss.

Quellen

1. ColorContrast – Dark Mode Contrast: The Complete Guide to WCAG-Compliant Dark UI
2. Material Design – Dark theme
3. BOIA – Offering a Dark Mode Doesn’t Satisfy WCAG Color Contrast Requirements

Amir Afshar

Autor dieses Artikels