Hell und Dunkel: Zwei Darstellungen konsistent gestalten

Eine dunkle Darstellung ist eine zusätzliche Gestaltungsaufgabe. Texte, Karten, Formulare und Bilder müssen weiterhin zusammenpassen. Das bloße Austauschen von Weiß und Schwarz kann die Ebenen einer Oberfläche verwischen oder Markenakzente auf ihrem neuen Hintergrund unlesbar machen.

Dieser Leitfaden entwickelt ein überschaubares System für einen fiktiven Beratungsauftritt. Es verbindet Farbrollen, Systemvorgabe und einen direkten Umschalter. Der Beispielcode ist Lernmaterial und muss vor einer Übernahme mit den tatsächlichen Komponenten, Sicherheitsvorgaben und Ladeabläufen des Projekts verbunden werden.

1. Konsistenz über die Bedeutung herstellen

Die Darstellung darf wechseln, die Aufgabe einer Komponente bleibt erhalten. Eine primäre Aktion bleibt eine primäre Aktion. Eine Fehlermeldung erklärt weiterhin denselben Zustand. Die Navigation sollte nicht allein deshalb andere Begriffe verwenden, weil ihre Fläche jetzt dunkel ist.

Für die Beispielberatung werden zunächst die vorhandenen Rollen erfasst: Seitenfläche, Inhaltsfläche, Haupttext, ergänzender Text, Linie, Aktion und Fokus. Erst danach wird für jede Rolle die helle und dunkle Ausprägung gewählt. Das verhindert, dass einzelne Seiten neue Ausnahmen erfinden.

Auch die Hierarchie muss in beiden Varianten verständlich bleiben. Wenn Karten im hellen Modus durch eine Hintergrundfläche voneinander getrennt sind, muss im dunklen Modus eine entsprechende Beziehung erkennbar sein. Eine zusätzliche Rahmenlinie kann dafür geeigneter sein als ein nahezu unsichtbarer Schatten.

Beurteilen Sie deshalb vollständige Aufgaben. Ein einzelner dunkler Farbausschnitt kann hochwertig aussehen, während der Kontaktweg im Zusammenhang seine Orientierung verliert. Die Abnahme verbindet Gestaltung und tatsächliche Bedienung.

2. Systemvorgabe und persönliche Wahl unterscheiden

Ohne gespeicherte eigene Entscheidung kann die Webseite die angeforderte Darstellung des Systems berücksichtigen. Die MDN-Referenz zu prefers-color-scheme beschreibt das entsprechende Medienmerkmal. Es liefert eine Vorgabe und keine Aussage darüber, welche Darstellung für jede Person immer besser ist.

Ein direkter Umschalter erlaubt anschließend eine eigene Wahl. Der erste Klick wechselt von der tatsächlich sichtbaren Variante zur anderen. Eine Person muss dafür nicht erst ein Menü mit mehreren technischen Optionen verstehen. Der zugängliche Name beschreibt jeweils die nächste Handlung.

Eine persönliche Wahl wird in unserem Beispiel gespeichert. Danach verdrängt eine spätere Änderung des Systems diese Wahl nicht ungefragt. Solange keine eigene Wahl besteht, kann die Seite auf die Systemänderung reagieren. Diese Rangfolge wird ausdrücklich festgelegt und in beiden Richtungen geprüft.

3. Farbrollen gemeinsam definieren

Ein zentrales Rollensystem verhindert verstreute Werte. Komponenten greifen auf eine Bedeutung zu, etwa die Inhaltsfläche oder den Text darauf. Die Darstellung kann diese Rollen ändern, ohne dass jede Komponente ihre gesamte Gestaltung neu definieren muss.

:root {
  --page: #f3f0e9;
  --surface: #ffffff;
  --text: #202326;
  --line: #747474;
  --action: #d00000;
  --on-action: #ffffff;
  color-scheme: light;
}
:root[data-theme="dark"] {
  --page: #16191c;
  --surface: #202326;
  --text: #f3f0e9;
  --line: #91979d;
  color-scheme: dark;
}
body { color: var(--text); background: var(--page); }
.content-card { background: var(--surface); }
.primary-action { color: var(--on-action); background: var(--action); }

Die Farben sind ein konkretes Lehrbeispiel. Jede tatsächlich eingesetzte Kombination muss geprüft werden. Die rote Aktion behält hier ihre weiße Beschriftung. Kleine rote Textlinks auf Anthrazit benötigen dagegen eine eigene geeignete Lösung, weil dieselbe Farbe nicht auf jedem Hintergrund gleich lesbar ist.

4. Browserkomponenten berücksichtigen

Neben eigenen Flächen gibt es vom Browser gestaltete Teile. Dazu können native Eingaben oder andere Oberflächenbestandteile gehören. Die MDN-Referenz zu color-scheme beschreibt, wie das unterstützte Farbschema mitgeteilt werden kann. Es ersetzt keine eigenen Farben für sämtliche Komponenten.

Prüfen Sie Formulare tatsächlich in beiden Darstellungen. Ein Eingabefeld kann einen anderen Hintergrund erhalten als erwartet. Platzhalter, markierter Text und Fehlermeldung müssen dann weiterhin verständlich sein. Ein dunkler Seitenhintergrund allein beweist nicht, dass die gesamte Eingabeoberfläche mitwechselt.

Der Kontrollbereich für Auswahlfelder verdient eigene Aufmerksamkeit. Pfeil, Beschriftung und Innenabstand müssen erkennbar bleiben. Bei einer projektseitig gestalteten Variante werden alle Zustände geprüft und die tatsächliche Darstellung wird nicht allein aus einem gesetzten Paddingwert abgeleitet.

Die verschiedenen Browser können Details unterschiedlich darstellen. Dokumentieren Sie daher, welche Kombinationen tatsächlich betrachtet wurden. Ein einzelner Screenshot in einem Browser ist keine allgemeine Abnahme aller nativen Steuerelemente.

5. Den Umschalter eindeutig gestalten

Für das Beispiel verwenden wir eine kompakte Schaltfläche mit einem halb hellen und halb dunklen Kreis. Sie wechselt direkt zwischen den beiden Darstellungen. Eine sinnvolle Klickfläche, sichtbarer Tastaturfokus und ein verständlicher zugänglicher Name gehören zur Komponente.

<button id="appearance-toggle" type="button" hidden
        aria-label="Dunkle Darstellung aktivieren">
  <span class="appearance-symbol" aria-hidden="true"></span>
</button>

Das Symbol ist dekorativ, weil der Button bereits einen zugänglichen Namen besitzt. Dieser Name wird nach jedem Wechsel angepasst. Die Beschriftung „Darstellung“ allein wäre weniger konkret, wenn die Schaltfläche unmittelbar eine Handlung ausführt.

Auch ohne Maus muss die Funktion erreichbar sein. Die sichtbare Gestaltung darf nicht nur einen kleinen Kreis als tatsächliche Klickfläche bieten. Ein größerer umgebender Button kann die Bedienung erleichtern, ohne den gesamten Kopfbereich zu dominieren.

6. Die direkte Wahl nachvollziehbar umsetzen

Die folgende JavaScript-Skizze wird nach dem vorhandenen Button ausgeführt. Sie zeigt die Rangfolge zwischen eigener Wahl und System. Ausnahmen beim Speichern unterbrechen die aktuelle Bedienung nicht. Der verwendete Schlüssel ist ein Beispiel und muss zu den Konventionen des Projekts passen.

const root = document.documentElement;
const toggle = document.querySelector("#appearance-toggle");
const system = matchMedia("(prefers-color-scheme: dark)");
let choice = null;
try {
  const stored = localStorage.getItem("appearance");
  if (["light", "dark"].includes(stored)) choice = stored;
} catch {}
const current = () => choice ?? (system.matches ? "dark" : "light");
function apply() {
  const mode = current();
  root.dataset.theme = mode;
  toggle.setAttribute("aria-label", mode === "dark"
    ? "Helle Darstellung aktivieren" : "Dunkle Darstellung aktivieren");
}
toggle.addEventListener("click", () => {
  choice = current() === "dark" ? "light" : "dark";
  try { localStorage.setItem("appearance", choice); } catch {}
  apply();
});
system.addEventListener("change", () => {
  if (choice === null) apply();
});
apply();
toggle.hidden = false;

Die MDN-Dokumentation zu matchMedia erklärt die Abfrage und das Beobachten ihrer Änderungen. Die Skizze zeigt bewusst nur einen abgegrenzten Ablauf. Weitere Seitenzustände, mehrere Fenster und projektbezogene Speicherkonzepte benötigen zusätzliche Entscheidungen.

7. Einen sinnvollen Zustand ohne JavaScript vorsehen

Inhalte müssen auch dann lesbar bleiben, wenn ein Skript nicht ausgeführt wird. Die helle Grundpalette liefert bereits eine nutzbare Ausgangsbasis. Die Systemvorgabe kann ergänzend direkt über CSS berücksichtigt werden, solange keine explizite Darstellung am Dokument gesetzt ist.

@media (prefers-color-scheme: dark) {
  :root:not([data-theme]) {
    --page: #16191c;
    --surface: #202326;
    --text: #f3f0e9;
    --line: #91979d;
    color-scheme: dark;
  }
}

Die Umschaltfunktion selbst benötigt im gezeigten Beispiel JavaScript. Ein Projekt sollte daher keinen funktionslosen Button als verfügbar anzeigen. Die Ausgabe kann erst nach erfolgreicher Initialisierung sichtbar werden oder eine andere tatsächlich funktionierende Rückfalllösung erhalten.

Die Darstellung der Inhalte bleibt davon getrennt. Eine fehlende Umschaltfunktion darf nicht dazu führen, dass Texte unlesbar oder Formulare unsichtbar werden. Diese Trennung wird mit abgeschaltetem beziehungsweise blockiertem Skript tatsächlich betrachtet.

8. Den ersten Seitenaufbau stabil halten

Wenn die gespeicherte Wahl erst spät angewendet wird, kann zunächst die falsche Darstellung erscheinen. Das kann störend wirken und zu einem sichtbaren Wechsel führen. Der Initialisierungszeitpunkt gehört deshalb zur Architektur und nicht erst zur letzten gestalterischen Korrektur.

Die Lernskizze ist für die Erklärung am Ende des Dokumentinhalts einfach gehalten. In einem produktiven Aufbau kann die reine Ermittlung der Anfangsdarstellung früh im Kopf stattfinden. Die spätere Anbindung des Buttons wird davon getrennt. Das muss mit den tatsächlichen Sicherheits- und Skriptvorgaben des Projekts verbunden werden.

Prüfen Sie einen leeren Cache und verzögerte Ressourcen. Eine bereits vollständig geladene Seite kann das Problem verdecken. Relevant sind die sichtbaren Zustände vom Beginn der Navigation bis zur fertigen Darstellung.

Vermeiden Sie überflüssige Übergänge auf der gesamten Seite. Ein kurzer Farbwechsel darf nicht plötzlich jedes Element animieren und Eingaben unruhig machen. Wenn eine Animation vorgesehen ist, wird sie als eigener Gestaltungsbestandteil geprüft.

9. Kontrast pro Zustand beurteilen

Ein gutes helles Farbpaar wird nicht automatisch zu einem guten dunklen Farbpaar. Prüfen Sie Haupttext, Hinweise, Links, Aktionen, Auswahl und Fokus jeweils auf ihrer tatsächlichen Fläche. Ein Platzhalter kann beispielsweise schwächer erscheinen als die eigentliche Eingabe.

Die W3C-Erläuterung zu Textkontrast beschreibt die betreffende Anforderung und ihre Bedingungen. Für die Abnahme wird der jeweilige Einsatz beurteilt. Die Wahl einer dunklen Hintergrundfarbe ist kein Beleg dafür, dass alle Kontraste passen.

10. Bilder und Dokumente passend behandeln

Ein echtes Anwendungsbild enthält eine konkrete Darstellung. Eine pauschale Invertierung kann Farben und Bedeutung verfälschen. Der Screenshot sollte seinen tatsächlichen Inhalt behalten und bei Bedarf in eine passende umgebende Fläche eingebettet werden.

Ein Logo kann eine eigens vorgesehene helle und dunkle Variante benötigen. Die Form bleibt markenkonform. Es reicht nicht, irgendeine dunkle Datei durch eine beliebige helle Fassung zu ersetzen. Prüfen Sie die tatsächlichen freigegebenen Quelldateien.

Auch eingebettete Dokumente und fremde Inhalte können eine eigene Farbdarstellung besitzen. Die umgebende Seite muss den Übergang verständlich gestalten. Sie kann nicht ohne Weiteres die gesamte interne Gestaltung eines fremden Dokuments kontrollieren.

Für redaktionelle Grafiken werden Beschriftungen auf dem tatsächlich verwendeten Hintergrund geprüft. Eine transparente Grafik mit dunkler Schrift kann im hellen Modus funktionieren und im dunklen Modus verschwinden. Eine deckende geeignete Fläche kann die bessere Lösung sein.

11. Einen vollständigen Wechseltest durchführen

Der Test beginnt ohne gespeicherte Wahl. Zunächst wird die helle, dann die dunkle Systemvorgabe verwendet. Anschließend wechselt die Person über den Button. Die sichtbare Variante und der nächste zugängliche Aktionsname müssen zusammenpassen.

Nach dem Neuladen bleibt die eigene Wahl erhalten, sofern Speicherung verfügbar ist. Eine nachfolgende Systemänderung soll diese Entscheidung nicht verdrängen. Wird die Speichermöglichkeit absichtlich blockiert, bleibt die aktuelle Ansicht trotzdem umschaltbar.

Ergänzen Sie Tastaturbedienung, schmale Ansichten und Formulare mit Fehlerzuständen. Die reine Startseite deckt nicht automatisch alle Komponenten ab. Eine spätere neue Funktion wird in dieselbe Testmatrix aufgenommen.

Die Dokumentation nennt tatsächliche Browser, Breiten und untersuchte Zustände. Wenn nur eine Emulation stattgefunden hat, wird keine physische Geräteabnahme behauptet. Die Grenzen der Prüfung bleiben genauso nachvollziehbar wie ihr Ergebnis.

12. Die Symbolschaltfläche als vollständigen Baustein behandeln

Der Umschalter besteht aus mehr als seinem kleinen Symbol. Der umgebende Button schafft die tatsächlich aktivierbare Fläche. Sein Rand, Hintergrund und Fokus müssen in beiden Darstellungen erkennbar sein. Die folgende Ergänzung passt zur gezeigten HTML- und JavaScript-Skizze.

#appearance-toggle {
  display: inline-grid;
  place-items: center;
  min-inline-size: 44px;
  min-block-size: 44px;
  padding: .5rem;
  border: 1px solid var(--line);
  border-radius: .75rem;
  color: var(--text);
  background: var(--surface);
}
#appearance-toggle[hidden] { display: none; }
#appearance-toggle:focus-visible { outline: 3px solid currentColor;
  outline-offset: 3px; }
.appearance-symbol {
  inline-size: 1.1rem;
  aspect-ratio: 1;
  border: 1px solid currentColor;
  border-radius: 50%;
  background: linear-gradient(90deg, #fff 50%, #202326 50%);
}

Die verborgene Ausgangslage verhindert im Lernbeispiel einen funktionslosen Umschalter bei fehlendem Skript. Erst nach erfolgreicher Initialisierung wird er sichtbar. Das Symbol muss dabei nicht jedes Mal seine Form verändern. Der zugängliche Name und die tatsächlich sichtbare Seite erklären gemeinsam den nächsten Wechsel.

Prüfen Sie zusätzlich die Position im Kopfbereich. Sprachwahl, Kontakt und Menü benötigen ebenfalls Platz. Die Schaltfläche sollte nicht dazu führen, dass eine andere wichtige Funktion bei schmalen Ansichten abgeschnitten wird. Die Komponente wird deshalb innerhalb des gesamten Kopfbereichs beurteilt.

13. Einen vorhandenen Auftritt schrittweise umstellen

Bei einer bestehenden Webseite werden zunächst verstreute feste Farbwerte erfasst. Ordnen Sie diese ihren tatsächlichen Rollen zu. Zwei ähnliche Grautöne können unterschiedliche Aufgaben besitzen oder unbeabsichtigt auseinanderentwickelt worden sein. Die Entscheidung wird am Inhalt und an den Komponenten getroffen, nicht allein durch eine automatische Textersetzung.

Überführen Sie danach einen klar abgegrenzten Bereich in das Rollensystem, etwa eine Leistungsübersicht. Prüfen Sie Normalzustand, Fokus und lange Inhalte in beiden Darstellungen. Erst wenn diese Fälle verständlich bleiben, werden weitere Bereiche nach denselben Regeln angepasst.

Bewahren Sie bereits funktionierende Sonderfälle. Ein eingebetteter Screenshot benötigt möglicherweise seine eigene helle Fläche. Eine fachliche Grafik kann für einen definierten Hintergrund erstellt worden sein. Solche Inhalte werden bewusst eingeordnet, statt jede Ausnahme durch globale Filter zu verändern.

Nach der Umstellung werden die vollständigen Besucherwege erneut betrachtet. Ein funktionierender Kartenbereich beweist nicht, dass die spätere Formularbestätigung ebenfalls lesbar ist. Die Migration endet deshalb mit einer aufgabenbezogenen Prüfung und einem dokumentierten Rückweg für die tatsächlich geänderten Projektdateien.

14. Neue Komponenten an die vereinbarten Rollen binden

Die langfristige Konsistenz hängt von der weiteren Pflege ab. Für einen neuen Hinweisbereich wird zunächst geklärt, welche Bedeutung er besitzt. Anschließend werden vorhandene Text-, Flächen- und Rahmenrollen verwendet oder eine nachvollziehbare zusätzliche Rolle definiert.

Eine Rollenbeschreibung enthält die vorgesehenen Hintergründe und Zustände. „Ergänzender Text“ ist beispielsweise auf einer Seitenfläche und einer hervorgehobenen Karte zu prüfen. Die Dokumentation sollte keine ungeprüfte Erlaubnis vermitteln, dieselbe Farbe auf beliebigen späteren Flächen einzusetzen.

Halten Sie außerdem fest, welche Motive oder Komponenten getrennte Varianten benötigen. Ein späterer Bearbeiter erkennt dann, warum ein Logo ausgetauscht wird, ein Screenshot aber unverändert bleibt. Diese Unterscheidung ist eine fachliche Gestaltungsentscheidung und gehört zum System.

Nehmen Sie auch weniger auffällige Zustände auf: eine ausgewählte Tabellenzeile, einen ausgefüllten Suchbegriff und eine deaktivierte Aktion. Diese Bereiche können andere Farbrollen verwenden als die primäre Ansicht. Die Prüfung sollte erklären, ob der Zustand erkennbar bleibt und welche Handlung noch möglich ist. Eine bloße Sammlung dunkler Screenshots beschreibt diese Unterschiede nicht ausreichend.

Checkliste für konsistente Darstellungen

• Farbrollen und funktionale Bedeutungen sind zentral definiert.
• Beide Varianten besitzen eine nachvollziehbare visuelle Hierarchie.
• Ohne eigene Wahl wird die Systemvorgabe berücksichtigt.
• Der erste Klick wechselt von der sichtbaren Variante zur anderen.
• Der zugängliche Name beschreibt die nächste Handlung.
• Eine eigene Wahl bleibt bei späterer Systemänderung erhalten.
• Fehlende Speicherung unterbricht die aktuelle Bedienung nicht.
• Ohne Skript bleiben Inhalte lesbar und nutzbar.
• Der erste Seitenaufbau wurde mit verzögerten Ressourcen geprüft.
• Formulare, Fokus, Logos und Inhaltsbilder wurden separat betrachtet.
• Neue Komponenten erhalten dieselbe vollständige Testmatrix.

Häufige Fragen zu Hell und Dunkel

Müssen beide Darstellungen dieselben Farbwerte verwenden?

Ihre Bedeutungen sollen konsistent sein. Die tatsächlichen Werte können sich unterscheiden, damit sie auf den jeweiligen Hintergründen funktionieren.

Ist eine dunkle Darstellung grundsätzlich besser?

Eine pauschale Aussage hilft der Gestaltung wenig. Vorlieben und Nutzungssituationen unterscheiden sich. Eine verständliche Wahl und gut ausgearbeitete Varianten sind die praktische Grundlage.

Kann die Systemvorgabe eine eigene Wahl ersetzen?

Sie ist ein sinnvoller Ausgangspunkt. Wer ausdrücklich eine andere Darstellung wählt, sollte diese Entscheidung nachvollziehbar beibehalten können.

Quellen und weitere Grundlagen

Die verlinkten MDN-Referenzen und die W3C-WAI-Erläuterung wurden am 9. November 2026 geprüft. Rollenmodell, Zustandsmatrix und Beispielcode sind eigene Lernmaterialien.

Weiterführend: Qualität von Unternehmenswebseiten und Bedeutungsvolle HTML-Struktur und Bedienung.