Dark Mode und Barrierefreiheit zusammen denken

1. Warum Dark Mode kein reines Design-Thema ist

Dark Mode wird in Projektbesprechungen oft als Ästhetikfrage behandelt: dunkles Farbschema an oder aus, je nach Trend. Diese Sichtweise übersieht, dass ein dunkles Farbschema unmittelbare Auswirkungen auf die Lesbarkeit für sehr unterschiedliche Nutzergruppen hat. Für einen Teil der Nutzer ist Dark Mode eine echte Barrierefreiheit-Maßnahme, die Blendung reduziert und längeres Lesen erst erträglich macht. Für einen anderen Teil verschlechtert dieselbe Umstellung die Zeichenerkennung spürbar, weil das menschliche Auge auf helle Objekte vor dunklem Hintergrund physiologisch anders reagiert als auf dunkle Objekte vor hellem Hintergrund.

Diese Ambivalenz bedeutet in der Praxis: Ein Dark Mode, der einfach nur die Farben eines hellen Designs invertiert, löst kein Barrierefreiheitsproblem, sondern verschiebt es nur. Wer Dark Mode und Barrierefreiheit gemeinsam plant, muss beide Nutzergruppen im Blick behalten, das Kontrastverhältnis für das dunkle Schema eigenständig berechnen und dem System die Entscheidung überlassen, welches Schema initial aktiv ist. Die folgenden Abschnitte zeigen, wie das konkret in Magento- und Hyvä-Shops umgesetzt wird, von der physiologischen Grundlage bis zur Alpine.js-Komponente für den manuellen Umschalter.

2. Wem Dark Mode hilft: Lichtempfindlichkeit und Migräne

Für Nutzer mit Photophobie, chronischer Migräne oder bestimmten neurologischen Erkrankungen wirkt ein grelles weißes Interface wie eine direkte Lichtquelle im Gesichtsfeld. Ein durchschnittlicher Bildschirm mit weißem Hintergrund strahlt deutlich mehr Licht ab als derselbe Bildschirm mit dunklem Hintergrund, gerade in dunklen Umgebungen oder bei längerer Nutzung am Abend. Für diese Gruppe reduziert Dark Mode nicht nur Unbehagen, sondern verhindert messbar Symptomverstärkung: Studien zur Migräneauslösung nennen grelles Licht regelmäßig als einen der häufigsten Trigger.

Auch für Menschen mit bestimmten Formen von Katarakt oder erhöhter Lichtempfindlichkeit nach Augenoperationen ist ein dunkles Farbschema keine Komfortoption, sondern eine funktionale Notwendigkeit, um eine Seite überhaupt längere Zeit nutzen zu können. Das WCAG-Regelwerk selbst schreibt kein bestimmtes Farbschema vor, aber Erfolgskriterium 1.4.8 (Visual Presentation) verlangt, dass Nutzer Vorder- und Hintergrundfarben selbst wählen können, wenn eine Textblock-Alternative angeboten wird. prefers-color-scheme ist die technische Umsetzung dieses Prinzips auf Betriebssystemebene, ohne dass jede Website einen eigenen Farbwähler bauen muss.

3. Wem Dark Mode schadet: Astigmatismus und der Halation-Effekt

Für Nutzer mit Astigmatismus, einer sehr verbreiteten Fehlsichtigkeit durch eine unregelmäßig gekrümmte Hornhaut, kann Dark Mode das Gegenteil bewirken. Der sogenannte Halation-Effekt beschreibt, wie helle Zeichen auf dunklem Grund im Auge streuen und einen leichten Lichthof um jeden Buchstaben erzeugen. Bei starkem Kontrast zwischen sehr hellem Text und sehr dunklem Hintergrund verschwimmen Zeichenkanten dadurch stärker, als es bei dunklem Text auf hellem Grund der Fall wäre. Für Menschen mit unkorrigiertem oder teilkorrigiertem Astigmatismus wird Lesen im Dark Mode dadurch anstrengender statt einfacher.

Dieser Effekt ist keine Randnotiz: Astigmatismus betrifft schätzungsweise ein Drittel der erwachsenen Bevölkerung in irgendeiner Ausprägung, viele davon unbemerkt oder nur leicht korrigiert. Die praktische Konsequenz für Barrierefreiheit-Arbeit ist eindeutig: Ein erzwungener, nicht abschaltbarer Dark Mode ist ebenso problematisch wie ein erzwungener heller Modus. Die Lösung liegt nicht darin, sich für ein Schema zu entscheiden, sondern darin, beide Schemata sauber zu implementieren, dem Betriebssystem die initiale Wahl zu überlassen und dem Nutzer jederzeit einen manuellen Umschalter anzubieten.

4. Kontrastverhältnis für ein dunkles Farbschema neu berechnen

Ein häufiger Fehler bei der Umsetzung: Entwickler kopieren die Farbwerte des hellen Designs, invertieren sie mechanisch und gehen davon aus, dass das Kontrastverhältnis erhalten bleibt. Das stimmt rechnerisch zwar oft, weil die WCAG-Kontrastformel auf relativer Luminanz basiert und bei einer reinen Invertierung symmetrisch reagiert, es ignoriert aber den Halation-Effekt aus Abschnitt 3 vollständig. Ein Kontrastverhältnis von 21:1 zwischen reinem Weiß (#ffffff) und reinem Schwarz (#000000) erfüllt WCAG AAA formal mit Bestnote, ist für viele Nutzer aber unangenehmer zu lesen als ein etwas reduziertes Verhältnis von 15:1 bis 17:1 mit einem gedämpften Weißton.

Für Fließtext verlangt WCAG 2.2 Erfolgskriterium 1.4.3 mindestens 4,5:1, für großen Text (ab 24px oder 19px fett) mindestens 3:1. Diese Mindestwerte gelten unverändert für Dark Mode, aber die praktische Empfehlung liegt bewusst darüber, im Bereich 7:1 bis 15:1, um Spielraum für Halation-Vermeidung zu lassen, ohne unter das Minimum zu fallen. Tools wie der WebAIM Contrast Checker oder die Chrome DevTools Kontrastprüfung müssen für jede Farbkombination im dunklen Schema separat durchgerechnet werden, eine automatische Übernahme der hellen Werte reicht nicht aus.

/* Contrast ratios calculated separately for light and dark scheme,
   not simply inverted from one another */
:root {
  --color-bg: #ffffff;
  --color-text: #1c1917;      /* ratio to bg: 17.9:1 */
  --color-muted: #57534e;     /* ratio to bg: 7.1:1  */
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-bg: #18181b;      /* not pure #000000 */
    --color-text: #e4e4e7;    /* not pure #ffffff, ratio to bg: 15.8:1 */
    --color-muted: #a1a1aa;   /* ratio to bg: 7.3:1, still passes AA for large text */
  }
}

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

5. prefers-color-scheme technisch sauber respektieren

Die Media Query prefers-color-scheme liest die Betriebssystemeinstellung des Nutzers aus und ist der korrekte Ausgangspunkt für jedes Dark-Mode-Konzept. Der entscheidende Grundsatz: Die Website soll dem System folgen, nicht umgekehrt. Ein Interface, das beim ersten Besuch immer im hellen Modus startet und den Nutzer zwingt, manuell umzuschalten, ignoriert eine bewusst getroffene Systemeinstellung und schafft unnötige Reibung, besonders für Nutzer, die aus medizinischen Gründen konsequent im dunklen Modus arbeiten.

In CSS-first-Ansätzen wie Tailwind CSS v4 lässt sich prefers-color-scheme direkt über CSS-Variablen und die dark:-Variante abbilden, ohne JavaScript beim ersten Rendern. Wichtig ist, das initiale Farbschema serverseitig oder per Inline-Script vor dem ersten Paint zu setzen, sonst entsteht ein sichtbarer Flash of Wrong Theme, bei dem die Seite kurz hell aufblitzt, bevor JavaScript nachträglich auf Dark Mode umschaltet. Dieser Flash ist nicht nur unschön, sondern für lichtempfindliche Nutzer eine reale kleine Belastung bei jedem Seitenaufruf.

<!-- Inline script in <head>, before any CSS or content paints,
     prevents a flash of the wrong color scheme on first load -->
<script>
  (function () {
    var stored = localStorage.getItem('color-scheme');
    var systemDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
    var isDark = stored ? stored === 'dark' : systemDark;
    document.documentElement.classList.toggle('dark', isDark);
  })();
</script>

/* Tailwind CSS v4 CSS-first dark mode setup */
@import "tailwindcss";

@custom-variant dark (&:where(.dark, .dark *));

/* Falls back to the OS setting when no class is set manually */
@media (prefers-color-scheme: dark) {
  :root:not(.light) {
    color-scheme: dark;
  }
}

6. Warum reines Schwarz mit reinem Weiß meist ein Fehler ist

Der praktische Kernpunkt aus Abschnitt 3 lässt sich in eine einfache Regel übersetzen: #000000 als Hintergrund und #ffffff als Text sollten in einem Dark-Mode-Farbschema vermieden werden, obwohl diese Kombination das höchstmögliche Kontrastverhältnis liefert. Der Grund liegt in der Physiologie des Auges, nicht in der Mathematik der Kontrastformel: OLED-Bildschirme mit echtem Schwarz erzeugen einen besonders starken Helligkeitssprung an jeder Zeichenkante, was den Halation-Effekt verstärkt und zusätzlich zu wahrgenommenem Flimmern bei Augenbewegungen führen kann.

Die praxiserprobte Lösung, die auch große Systeme wie Material Design und das macOS-Systemdesign verwenden, ist ein abgedunkeltes Grau statt reinem Schwarz für den Hintergrund (etwa #18181b bis #121212) und ein leicht gedämpftes Weiß statt reinem Weiß für den Text (etwa #e4e4e7 statt #ffffff). Diese Kombination bleibt komfortabel oberhalb der WCAG-Mindestwerte, reduziert aber den Helligkeitssprung an Zeichenkanten spürbar. Für Nutzer, die dennoch maximalen Kontrast benötigen, etwa bei starker Sehbehinderung ohne Astigmatismus, sollte ein zusätzlicher High-Contrast-Modus über prefers-contrast: more verfügbar sein, statt den Standard-Dark-Mode auf das Extremum zu trimmen.

7. Dark Mode in Hyvä-Themes mit Tailwind und Alpine.js

Hyvä-Themes bringen mit Tailwind CSS und Alpine.js bereits die passenden Werkzeuge für ein sauberes Dark-Mode-Konzept mit, ohne zusätzliche JavaScript-Bibliotheken laden zu müssen. Die Farbdefinitionen gehören zentral in die CSS-Variablen der tailwind.css, nicht verstreut in einzelne .phtml-Templates, damit jede Komponente automatisch beide Farbschemata unterstützt. Für Magento-spezifische Elemente wie Preisangaben, Verfügbarkeitsstatus oder Rabattbadges müssen die Farben im dunklen Schema eigens geprüft werden, da beispielsweise ein kräftiges Rot für „ausverkauft" auf dunklem Grund oft ein anderes Kontrastverhältnis ergibt als auf hellem Grund.

Für den initialen Zustand ohne Flash of Wrong Theme reicht in Hyvä ein kleines Inline-Script im Magento_Theme::html/head.phtml, das vor dem ersten Tailwind-Stylesheet ausgeführt wird. Die eigentliche Umschaltlogik lässt sich anschließend als eigenständige Alpine.js-Komponente kapseln, die den Zustand in localStorage persistiert und auf System-Änderungen per matchMedia-Listener reagiert, ohne dass ein Seiten-Reload nötig wird.

// Alpine.js component for manual dark mode toggle in a Hyvä theme,
// registered globally via Alpine.data() in default.phtml
document.addEventListener('alpine:init', () => {
  Alpine.data('colorSchemeToggle', () => ({
    isDark: document.documentElement.classList.contains('dark'),

    init() {
      // React to OS-level scheme changes when the user has no manual override
      window.matchMedia('(prefers-color-scheme: dark)')
        .addEventListener('change', (event) => {
          if (!localStorage.getItem('color-scheme')) {
            this.setScheme(event.matches);
          }
        });
    },

    toggle() {
      this.setScheme(!this.isDark);
      localStorage.setItem('color-scheme', this.isDark ? 'dark' : 'light');
    },

    setScheme(dark) {
      this.isDark = dark;
      document.documentElement.classList.toggle('dark', dark);
    }
  }));
});

8. Nutzersteuerung: Toggle, Persistenz und ARIA

Ein Umschalter für das Farbschema ist selbst ein Barrierefreiheits-relevantes Bedienelement und muss den gleichen Anforderungen genügen wie jeder andere interaktive Button. Er braucht einen erreichbaren Namen über aria-label oder sichtbaren Text, muss per Tastatur fokussierbar und auslösbar sein, und sein aktueller Zustand sollte über aria-pressed für Screenreader-Nutzer erkennbar sein. Ein reines Icon ohne Beschriftung, das nur durch visuelle Interpretation als „Sonne" oder „Mond" verständlich ist, erfüllt diese Anforderung nicht.

Die gewählte Einstellung sollte über Seitenaufrufe hinweg persistieren, üblicherweise in localStorage, damit der Nutzer die Entscheidung nicht bei jedem Besuch wiederholen muss. Gleichzeitig sollte ein „Systemstandard"-Zustand verfügbar bleiben, der die manuelle Wahl aufhebt und wieder auf prefers-color-scheme zurückfällt, für Nutzer, die ihre Systemeinstellung situativ ändern, etwa tagsüber hell und abends dunkel per Betriebssystem-Zeitplan.

<!-- Accessible dark mode toggle button in a Hyvä .phtml template -->
<button
    type="button"
    x-data="colorSchemeToggle"
    x-on:click="toggle()"
    x-bind:aria-pressed="isDark.toString()"
    aria-label="Dunkles Farbschema umschalten"
    class="inline-flex items-center gap-2 rounded-lg border border-zinc-300 px-3 py-2 text-sm font-medium text-zinc-700 hover:bg-zinc-100 dark:border-zinc-600 dark:text-zinc-200 dark:hover:bg-zinc-800"
>
  <svg x-show="!isDark" class="w-4 h-4" aria-hidden="true"><!-- sun icon --></svg>
  <svg x-show="isDark" class="w-4 h-4" aria-hidden="true"><!-- moon icon --></svg>
  <span x-text="isDark ? 'Dunkel' : 'Hell'"></span>
</button>

9. Dark-Mode-Entscheidungen im direkten Vergleich

Viele Dark-Mode-Implementierungen scheitern nicht an der grundsätzlichen Idee, sondern an denselben wiederkehrenden Detailentscheidungen. Die folgende Übersicht stellt typische Fehlmuster den empfohlenen Lösungen gegenüber, jeweils mit dem konkreten Barrierefreiheitsvorteil.

Die Tabelle zeigt ein durchgängiges Muster: Fast jeder Fehler entsteht dadurch, dass ein helles Design mechanisch invertiert wird, statt das dunkle Schema als eigenständiges Designsystem mit eigener Kontrastprüfung zu behandeln. Wer diese fünf Punkte konsequent umsetzt, deckt die Mehrheit der praxisrelevanten Dark-Mode-Barrieren bereits ab, bevor ein spezialisierter Accessibility-Test überhaupt nötig wird.

10. Zusammenfassung

Die Verbindung von Dark Mode und Barrierefreiheit löst ein Problem mit zwei entgegengesetzten Nutzergruppen: Lichtempfindliche Nutzer und Menschen mit Migräne profitieren spürbar von einem dunklen Farbschema, während Nutzer mit Astigmatismus durch den Halation-Effekt bei starkem Hell-Dunkel-Kontrast schlechter lesen können. Beide Gruppen werden bedient, indem prefers-color-scheme als Ausgangspunkt respektiert wird, das Kontrastverhältnis für das dunkle Schema eigenständig berechnet wird und reines Schwarz mit reinem Weiß durch ein gedämpftes Grau und ein leicht reduziertes Weiß ersetzt wird.

Technisch bedeutet das für Hyvä-Shops: ein Inline-Script vor dem ersten Paint gegen den Flash of Wrong Theme, zentrale CSS-Variablen statt verstreuter Farbwerte in einzelnen Templates, und ein Alpine.js-Toggle mit korrekter ARIA-Auszeichnung und localStorage-Persistenz. Wer diese Punkte von Anfang an einplant, spart sich spätere Nacharbeit und liefert ein Farbschema, das für deutlich mehr Nutzer tatsächlich funktioniert als eine simple Invertierung.

11. FAQ: Dark Mode und Barrierefreiheit