Dark Mode technisch und barrierefrei umsetzen

Ein Dark Mode verbindet eine dunkle Farbpalette mit der Wahl durch den Nutzer. CSS liest die Systemeinstellung. Ein manueller Schalter ergänzt diese Voreinstellung. Kontrast, Fokus, Formulare, Bilder und Browser-Komponenten müssen in beiden Modi funktionieren.

Ein dunkler Hintergrund allein reicht nicht. Der Farbmodus betrifft jede Komponente und jeden Zustand.

Systempräferenz und manuelle Wahl verbinden

Die Media Query prefers-color-scheme erkennt, ob das Betriebssystem ein helles oder dunkles Farbschema bevorzugt.

:root {
  color-scheme: light dark;
  --bg: #ffffff;
  --surface: #f3f4f6;
  --text: #161616;
  --link: #004fc4;
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #111214;
    --surface: #1c1e22;
    --text: #f2f2f2;
    --link: #8ab4ff;
  }
}

Die Systemeinstellung bildet den Startwert. Nutzer können für eine Website eine andere Wahl treffen. Ein Schalter bietet drei Zustände: System, Hell und Dunkel.

Wahl speichern

Eine lokale Präferenz speichert das Skript in localStorage. Die Seite setzt den Modus früh im Dokument. Das verhindert ein Flackern beim Laden.

const savedTheme = localStorage.getItem('theme');
const root = document.documentElement;
if (savedTheme === 'light' || savedTheme === 'dark') {
  root.dataset.theme = savedTheme;
} else {
  delete root.dataset.theme;
}

Der Schalter verlangt eine Beschriftung und einen erkennbaren Zustand. Mond- und Sonne-Symbole ohne Text reichen nicht für jede Nutzungssituation.

Farben als semantische Token anlegen

Farben tragen den Namen ihrer Funktion. --text-muted bleibt semantisch verständlich; --gray-500 sagt nichts über seinen Zweck aus.

Jeder Modus definiert alle Token. Hart codierte Einzelfarben erzeugen sonst unlesbare Komponenten.

Die CSS-Funktion light-dark() führt zwei Werte in einer Deklaration, wenn color-scheme gesetzt ist und die festgelegte Browsermatrix die Funktion unterstützt.

:root {
  color-scheme: light dark;
}

body {
  background: light-dark(#ffffff, #111214);
  color: light-dark(#161616, #f2f2f2);
}

Kontrast und Zustände prüfen

WCAG 2.2 nennt für normalen Text ein Kontrastverhältnis von mindestens 4,5:1 und für großen Text 3:1. Für Bedienelemente und Grafikobjekte gelten eigene Kriterien.

Die Prüfung erfasst Fließtext und Systemzustände:

• →Links im Text
• →Fokusmarkierungen
• →Hover- und Aktivzustände
• →Formularrahmen und Platzhalter
• →Fehler- und Erfolgsmeldungen
• →deaktivierte Elemente
• →Diagramme und Icons
• →ausgewählte Navigation

Reines Weiß auf reinem Schwarz wirkt für manche Lesenden anstrengend. Die Palette entsteht deshalb nicht allein nach maximalem Kontrast. Lesbarkeit und Nutzerkontrolle gehen vor.

Der Beitrag Barrierefreie Websites technisch umsetzen behandelt Tastatur, Fokus, Formulare und Medien im Gesamtzusammenhang.

Bilder, Logos und Diagramme anpassen

Ein globaler Helligkeitsfilter verändert auch Hauttöne, Markenfarben und Informationsgrafiken. Bilder werden daher nicht über filter: brightness() abgedunkelt.

Je nach Zweck kommen infrage:

• →eigenes dunkles Logo
• →transparente Grafiken mit geprüften Konturen
• →alternative Diagrammfarben
• →dezente Fläche hinter Bildern
• →<picture> mit einer Quelle für den dunklen Modus

<picture>
  <source srcset="diagramm-dark.svg" media="(prefers-color-scheme: dark)">
  <img src="diagramm-light.svg" alt="Ablauf des Freigabeprozesses">
</picture>

Der Alternativtext bleibt auf die Information gerichtet. Er beschreibt den Inhalt, nicht den Farbmodus.

Browser-Komponenten und eingebettete Inhalte testen

color-scheme signalisiert Browsern, dass eine Seite helle und dunkle Formulare, Scrollbars und Oberflächen unterstützt. Das ersetzt nicht das Testen eigener Komponenten.

Fremde Einbettungen, Karten, Videos oder Widgets können eigene Modi nutzen. Ist die Darstellung nicht steuerbar, benötigt die Seite einen lesbaren Rahmen und eine Abgrenzung.

E-Mails, Druckansicht und Dokumente verlangen eigene Regeln. Die Website-Einstellung überträgt sich nicht automatisch.

OLED und LCD unterscheiden

LCDs nutzen meist eine Hintergrundbeleuchtung. Dunkle Pixel blockieren Licht, schalten die Beleuchtung aber nicht einzeln ab. Ein dunkles Farbschema senkt den Verbrauch des Displays auf LCDs nicht in derselben Weise wie bei OLED.

Bei OLED erzeugen Pixel ihr Licht selbst. Dunklere Pixel nehmen bei gleicher Gerätekonfiguration weniger Leistung auf als helle Pixel. Die Höhe des Effekts hängt von Display, Helligkeit, Farbwerten, dargestellten Flächen und Nutzung ab. Eine feste Prozentzahl für Websites ist nicht belegbar.

Ein Dark Mode ist keine Emissionsbilanz. Wer Energieeffekte belegt, dokumentiert:

Die W3C Web Sustainability Guidelines ordnen UI-Entscheidungen in einen breiteren Rahmen ein.

Umsetzung in sechs Schritten

1. →Farben und Zustände inventarisieren.
2. →Semantische Farbtoken für Hell und Dunkel festlegen.
3. →Systempräferenz als Standard auslesen.
4. →Manuellen Schalter mit den Zuständen System, Hell und Dunkel bauen.
5. →Kontrast, Fokus, Formulare, Medien und Einbettungen prüfen.
6. →Wahl speichern und Flackern beim Laden testen.

Abnahmekriterien

Häufige Fragen zum Dark Mode

Soll die Website immer dem Betriebssystem folgen?

Die Systemeinstellung ist ein guter Startwert. Ein manueller Schalter gibt Nutzern Kontrolle über den Modus der Website.

Muss der Hintergrund für OLED schwarz sein?

Nein. Reines Schwarz kann bei OLED weniger Licht erzeugen. Lesbarkeit, Kontrast, Smearing und Gestaltung verlangen trotzdem eigene Prüfschritte.

Spart Dark Mode auf jedem Gerät Energie?

Nein. Der Effekt hängt unter anderem vom Displaytyp, der Helligkeit und dem dargestellten Inhalt ab. Auf LCDs wirkt eine dunkle Darstellung anders als auf OLED.

Ist Dark Mode ein Rankingfaktor?

Nein. Eine garantierte Rankingwirkung folgt daraus nicht. Dark Mode ist eine Darstellungs- und Nutzungsfunktion.

Nächster Schritt

Der Beitrag User Experience (UX) als Rankingfaktor ordnet den Farbmodus aus Nutzersicht ein. Der Beitrag Technisches SEO: Infrastruktur, Architektur und Jamstack verbindet Frontend und Auslieferung. OLDSCHOOLSEO setzt Farbmodi, Kontrast und Nutzerwahl beim Bau einer Jamstack-Website ab 224 € um.

Projektanfrage per E-Mail senden · Erstgespräch mit Sandra buchen

Über den Autor: Sandra Krone

Sandra Krone ist Partnerin und Gründerin von OLDSCHOOLSEO. Ihre Arbeit beginnt bei der Analyse der Nutzerintention und der Content-Strategie, um daraus die Anforderungen für die redaktionelle und technische Umsetzung abzuleiten.

Mehr über die GründerProfil auf LinkedIn