Dark Mode mit Claude Code implementieren

Mit dem Produktrisiko beginnen

Dark Mode mit Claude Code implementieren bedeutet nicht, Claude Code um eine hübschere Oberfläche zu bitten. Ziel ist eine echte Verbesserung, ohne Conversion, Lesbarkeit, Barrierefreiheit oder mobile Darstellung zu beschädigen. In der Praxis zählen leere Zustände, Ladezustände, Fehler, Tastaturfokus, lange Texte, Anzeigen, Codeblöcke und die Position des CTA.

Lies dazu auch claude code design system, claude code accessibility, claude code code review. Offizielle Quellen: Claude Code docs, MDN prefers-color-scheme, MDN color-scheme, WCAG contrast. Die Anfrage an Claude Code sollte Ziel, Grenzen, use case, pitfall und Prüfung enthalten.

Empfehlenswerter Prompt

Implementiere diese Verbesserung mit der kleinsten sicheren Änderung.
Respektiere bestehende Komponenten, Design Tokens und Routen.
Berücksichtige use case, pitfall, Barrierefreiheit, mobile Ansicht und Fehlerzustände.
Gib kopierbaren Code und eine review checklist zurück.

Use case checklist

Landingpages und Artikel, bei denen der nächste Schritt sichtbar sein muss.
SaaS-Dashboards mit Ladezustand, leerem Zustand, Fehler und Erfolg.
Checkout, Registrierung und Beratung, bei denen der Hauptbutton klar bleibt.
Team-Reviews, in denen Claude Code Code und Prüfkriterien liefert.

Implementierungscode

:root {
  color-scheme: light;
  --color-page: #ffffff;
  --color-surface: #f8fafc;
  --color-text: #0f172a;
  --color-muted: #475569;
  --color-border: #dbe3ef;
  --color-link: #2563eb;
  --color-focus: #f59e0b;
}

[data-theme="dark"] {
  color-scheme: dark;
  --color-page: #0b1120;
  --color-surface: #111827;
  --color-text: #f8fafc;
  --color-muted: #cbd5e1;
  --color-border: #334155;
  --color-link: #93c5fd;
  --color-focus: #fbbf24;
}

body {
  background: var(--color-page);
  color: var(--color-text);
}

:focus-visible {
  outline: 3px solid var(--color-focus);
  outline-offset: 3px;
}

const storageKey = "theme";
const root = document.documentElement;
const stored = localStorage.getItem(storageKey);
const prefersDark = window.matchMedia("(prefers-color-scheme: dark)").matches;
const theme = stored === "light" || stored === "dark" ? stored : prefersDark ? "dark" : "light";

root.dataset.theme = theme;

type Theme = "light" | "dark" | "system";

export function ThemeToggle({ value, onChange }: { value: Theme; onChange: (theme: Theme) => void }) {
  return (
    <fieldset aria-label="Theme">
      {(["light", "dark", "system"] as const).map((theme) => (
        <button
          key={theme}
          type="button"
          aria-pressed={value === theme}
          onClick={() => onChange(theme)}
        >
          {theme}
        </button>
      ))}
    </fieldset>
  );
}

Das Theme-Flackern verhindern (kurzer Farbwechsel beim ersten Moment)

Der erste Fallstrick bei Dark Mode ist das Flackern: Für einen kurzen Moment sieht man beim Öffnen der Seite ein helles Bild, bevor es dunkel wird. Im Englischen heißt das FOUC (Flash of Unstyled Content) oder Theme-Flash. Die Ursache: Das Theme wird erst per JavaScript umgeschaltet, nachdem das HTML schon angezeigt wurde. Setzt du data-theme erst, nachdem CSS oder React geladen sind, ist während dieser Wartezeit die Anfangsfarbe (meist hell) sichtbar.

Die Lösung ist, ein sehr kurzes Skript, das nur das Theme bestimmt, synchron vor dem Inhalt im <head> auszuführen. So legst du data-theme fest, bevor das Bild gezeichnet wird, und liest dafür nur die gespeicherte Einstellung und die Geräteeinstellung.

<script>
  (function () {
    var stored = localStorage.getItem("theme");
    var prefersDark = window.matchMedia("(prefers-color-scheme: dark)").matches;
    var theme = stored === "light" || stored === "dark" ? stored : prefersDark ? "dark" : "light";
    document.documentElement.dataset.theme = theme;
  })();
</script>

Wichtig ist, dieses Skript leicht zu halten und vor dem Rendern des Inhalts laufen zu lassen. Steckst du hier schwere Logik oder die React-Initialisierung hinein, kehrt das Flackern zurück. Auch in Astro oder Next.js behandelst du genau dieses kleine Skript gesondert, damit das Theme ohne Warten auf die Hydration (das Beleben des serverseitig erzeugten HTML im Browser) feststeht. Da der Server die Geräteeinstellung nicht kennt, respektierst du beim ersten Mal die Geräteeinstellung; sobald der Nutzer umschaltet, speicherst du den Wert in localStorage und bevorzugst ihn beim nächsten Mal.

Kontrast, Bilder und Schatten auch im Dark Mode lesbar machen

Nur die Farben umzukehren macht den Dark Mode nicht fertig. Ein Kontrast, der im hellen Bild genügte, kann auf dunklem Hintergrund zu schwach werden. Prüfe das Kontrastverhältnis von Text zu Hintergrund mit dem von WCAG genannten Richtwert von mindestens 4,5:1. Besonders hellgrauer Zusatztext, Platzhalter und Buttons im deaktivierten Zustand werden auf dunklem Hintergrund schnell unlesbar.

Auch Bilder und Schatten brauchen Anpassung. Logos oder Icons, die für Weiß gemacht sind, verlieren auf dunklem Hintergrund ihre Kanten. Hinterlege transparente PNGs mit einer Hintergrundfarbe oder bereite eine Dark-Variante vor. Ein Schatten, der auf hellem Hintergrund mit dunklem Grau wirkt, ist auf dunklem Hintergrund kaum sichtbar. Begrenzungen, die du über Schatten gelöst hast, baust du besser mit einer Linie wie --color-border neu auf, damit die Struktur in beiden Themes erkennbar bleibt.

Element	Annahme in Light	Anpassung in Dark
Zusatztext	Helles Grau genügt	Helligkeit erhöhen, Kontrast sichern
Logo/Icon	Weißer Hintergrund	Hintergrund hinterlegen oder Dark-Variante
Schatten	Begrenzung über dunkles Grau	Über Rahmen (border) neu darstellen
Statusfarbe	Kräftiges Grün/Rot	Sättigung senken, Icon ergänzen

Zuletzt prüfst du auch Diagramme, Grafiken und Statusfarben (Grün für Erfolg, Rot für Warnung). Stark gesättigte Farben grellen auf dunklem Hintergrund und sind schwer lesbar, deshalb hältst du für Dark etwas ruhigere Farben bereit. Vermittle den Status nicht nur über Farbe, sondern ergänze Icons oder Labels – so kommt er auch bei schwachem Kontrast und bei Lesern mit Farbsehschwäche an. Lass Claude Code beim Review gezielt nach „Stellen mit nachlassendem Kontrast auf dunklem Hintergrund“, „für Weiß gedachten Bildern“ und „über Schatten dargestellten Begrenzungen“ suchen, dann sinken die Lücken.

Pitfall checklist

Nur für den Screenshot zu optimieren verschlechtert oft den echten Nutzerpfad.
Bedeutung nur über Farbe oder Bewegung zu vermitteln schwächt Barrierefreiheit.
Ohne Test bei 375px entsteht schnell horizontaler Scroll.
Leere Daten, lange Labels und langsame Netze müssen geprüft werden.
Unbezogene Dateiänderungen machen das Review teuer.

Prüfung

Fordere eine zweite reine Review-Runde von Claude Code an. Sie soll geänderte Dateien, Risiken, Browserchecks und manuelle Tests nennen. Danach im mobilen Viewport prüfen: kein Overflow, Codeblock scrollt, CTA sichtbar, Fokus sichtbar.

Monetarisierung

Dieses Thema wirkt auf Anzeigen, Produktkarten, Beratungslinks, Preistabellen und Formulare. Wer es in einem echten Repository einführen möchte, kann über Claude Code Training und Beratung einen wiederholbaren Ablauf aufbauen.

Zusätzliche Review-Punkte

Vergleiche Vorher/Nachher-Screenshots und prüfe CTA, Anzeigen, Text, Formulare und Codeblöcke.
Frage Claude Code, was entfernt werden kann, welche Namen nicht passen und welche Annahmen riskant sind.
Vor dem Deployment mobile Ansicht, Desktop, Tastatur, langsames Netz, leere Daten und Reload testen.

Praxistest

Ich habe Umsetzung, Review und mobilen Test getrennt. Dadurch blieb der Diff klein und Layout- sowie A11y-Probleme wurden vor dem Deployment sichtbar.