Farbkontrastfehler sind der mit Abstand häufigste Verstoß gegen Barrierefreiheitsrichtlinien im Web und betreffen die Mehrheit der Websites. Dieser Leitfaden erklärt genau, was WCAG verlangt, wie man Kontrastfehler mit den richtigen Tools findet und wie man sie in deinem CSS behebt – ohne die visuelle Identität deiner Marke zu opfern.

Stell dir eine Besucherin vor, die mit eingeschränktem Sehvermögen auf deiner Website landet, in einem sonnendurchfluteten Café sitzt und die Bildschirmhelligkeit ihres Smartphones auf Maximum gestellt hat. Wenn dein hellgrauer Fließtext auf einem weißen Hintergrund steht, kann sie deine Inhalte schlicht nicht lesen – ganz egal, wie sorgfältig du jedes Wort formuliert hast. Dieses Szenario ist nicht hypothetisch: Text mit zu geringem Kontrast wurde Anfang 2026 auf 83,9% der eine Million meistbesuchten Startseiten festgestellt und ist damit im siebten Jahr in Folge der am häufigsten identifizierte Barrierefreiheitsfehler im Web; jede betroffene Startseite wies im Durchschnitt 34 einzelne Vorkommen des Problems auf.

Warum Farbkontrast wichtiger ist, als du denkst

Die meisten Menschen gehen davon aus, dass Kontrastprobleme nur Nutzer betreffen, die vollständig blind sind oder Screenreader verwenden. Die Realität ist deutlich breiter. Weltweit gibt es etwa 300 Millionen Menschen mit einer Form von Farbsehschwäche, und viele weitere erleben geringen Kontrast als tägliche Reibungsquelle – Menschen mit billigen Monitoren, mit alternden Augen oder alle, die draußen an einem hellen Tag scrollen. Sehschwäche ist weit häufiger als vollständige Blindheit: Fast dreimal so viele Menschen haben eine Sehbehinderung wie gar kein Sehvermögen.

Die Forschung hinter den Kontrastschwellen der WCAG macht das greifbar. Das Mindestverhältnis von 4,5:1 für Standardtext wurde so kalibriert, dass es den Verlust der Kontrastempfindlichkeit ausgleicht, wie er typischerweise bei einer Sehschärfe von etwa 20/40 auftritt – der Sehleistung, die häufig bei Menschen in ihren Achtzigern berichtet wird. Die strengere 7:1-Schwelle der WCAG auf Level AAA wurde ähnlich kalibriert: Sie zielt auf Nutzer mit einer Sehschärfe von 20/80 ab und kompensiert den Verlust der Kontrastempfindlichkeit bei Menschen mit Sehbehinderung, die keine unterstützenden Technologien verwenden.

Es gibt außerdem sehr reale rechtliche und geschäftliche Konsequenzen. In den Vereinigten Staaten wurden 2024 insgesamt 4.605 ADA-Klagen zur digitalen Barrierefreiheit eingereicht, und der European Accessibility Act ist im Juni 2025 in Kraft getreten und hat die verpflichtenden Compliance-Pflichten auf eine breite Palette kommerzieller Websites und Apps ausgeweitet. Fehler beim Farbkontrast sind nachweisbar, dokumentiert und werden in Gerichtsverfahren routinemäßig angeführt. Für Compliance-Verantwortliche macht das ihre Behebung zu einer Priorität, nicht zu einem „Nice-to-have“.

Schließlich ist barrierefreier Kontrast einfach gutes Design. Text mit hohem Kontrast ist für alle leichter zu scannen, reduziert die kognitive Belastung und verbessert die Lesegeschwindigkeit insgesamt – und ist damit ebenso sehr eine geschäftliche Leistungsverbesserung wie eine Compliance-Verpflichtung.

Die WCAG-Kontrastregeln, die du wirklich kennen musst

WCAG 2 definiert Kontrast als Maß für den Unterschied in der wahrgenommenen Leuchtdichte zwischen zwei Farben. Die Formel vergleicht die relative Helligkeit einer Vordergrundfarbe mit ihrem Hintergrund und drückt das Ergebnis als Verhältnis von 1:1 (kein Unterschied – Weiß auf Weiß) bis 21:1 (maximaler Unterschied – Schwarz auf Weiß) aus. Du musst das nicht manuell berechnen; entscheidend ist, zu verstehen, welche Verhältnisse gefordert sind und wann sie gelten.

Unter WCAG 2.x Level AA – dem Level, auf das sich die meisten Gesetze und Barrierefreiheitsstandards beziehen – gliedern sich die Anforderungen wie folgt:

Normaler Text (Fließtext, Labels, UI-Text unter 18pt oder 14pt fett): minimales Kontrastverhältnis von 4,5:1 zum Hintergrund.
Großer Text (mindestens 18pt / 24px oder 14pt / ~18,66px fett): minimales Kontrastverhältnis von 3:1. Die Logik dahinter: Größere Buchstabenformen sind von Natur aus leichter zu unterscheiden, daher ist eine entspanntere Schwelle gerechtfertigt.
Nicht-textliche UI-Komponenten und Informationsgrafiken (Erfolgskriterium 1.4.11, eingeführt in WCAG 2.1): minimales Kontrastverhältnis von 3:1 zu angrenzenden Farben. Dies umfasst Dinge wie Rahmen von Formulareingaben, Fokusindikatoren, reine Icon-Buttons und Teile von Diagrammen, die zum Verständnis der Daten erforderlich sind.

Unter Level AAA liegt die Messlatte höher: 7:1 für normalen Text und 4,5:1 für großen Text. Auch wenn Level AAA selten vollständig vorgeschrieben ist, lohnt es sich, es als Designziel für textlastige Seiten oder Benutzeroberflächen zu behandeln, bei denen Lesegenauigkeit kritisch ist.

Wichtige Nuance: WCAG definiert „großen Text“ über die gerenderte Größe im Browser, nicht über den Wert in deinem CSS. Eine Schrift, die auf 1.2rem gesetzt ist, kann je nach Basis-Schriftgröße des Browsers der Nutzerin als großer Text gelten oder nicht. Im Zweifel solltest du die 4,5:1-Schwelle anwenden und Tools nutzen, um die tatsächlich gerenderte Größe zu überprüfen.

Eine Handvoll Elemente ist ausdrücklich von den Kontrastanforderungen ausgenommen. Rein dekorative Bilder, deaktivierte Formularelemente, Logos und echte Fotografien unterliegen nicht dem Erfolgskriterium 1.4.3. Diese Ausnahme ist sinnvoll – ein Wasserzeichen-Hintergrund oder ein Produktfoto sollte nicht denselben Schwellenwert erfüllen müssen wie ein Navigationslabel – aber Teams wenden sie häufig falsch an, um nachlässige Designentscheidungen zu rechtfertigen. Wenn ein Bild oder eine Grafik erforderlich ist, um den Inhalt der Seite zu verstehen, muss es dennoch die 3:1-Anforderung für nicht-textlichen Kontrast erfüllen.

Eine weitere wichtige Regel verdient Aufmerksamkeit: WCAG 1.4.1 (Verwendung von Farbe). Wenn du Links vom umgebenden Fließtext ausschließlich über Farbe unterscheidest – ohne Unterstreichung, ohne Gewichtsunterschied, ohne andere visuelle Hinweise – müssen diese Links ein Kontrastverhältnis von 3:1 zum angrenzenden Fließtext erreichen, zusätzlich zur Erfüllung des standardmäßigen 4,5:1-Verhältnisses zwischen Text und Hintergrund. Alle drei Anforderungen gleichzeitig zu erfüllen, ist tatsächlich schwierig; die einfachste Lösung ist, die Unterstreichung deiner Links beizubehalten.

Wie man auf Kontrastfehler testet

Das Testen von Kontrast ist einer der tool-freundlichsten Teile der Barrierefreiheitsarbeit. Die zugrunde liegende Berechnung ist mathematisch und deterministisch, was bedeutet, dass automatisierte Tools sie zuverlässig erkennen können – anders als viele andere Barrierefreiheitsprobleme, die menschliches Urteil erfordern. Dennoch gibt es Randfälle, in denen Automatisierung an ihre Grenzen stößt, und das Verständnis des gesamten Test-Stacks macht deine Audits deutlich gründlicher.

Schritt 1: Einen automatisierten Seiten-Scan ausführen

WAVE (das WebAIM-Web-Barrierefreiheits-Tool) und axe DevTools sind die zwei am weitesten verbreiteten browserbasierten Scanner. Beide sind als Chrome- und Firefox-Erweiterungen verfügbar. Sie scannen den gerenderten DOM – das heißt, sie bewerten Farben so, wie der Browser sie tatsächlich zeichnet, nachdem CSS und JavaScript angewendet wurden – und markieren Textelemente, die die WCAG-AA-Kontrastschwelle verfehlen. Axe DevTools geht weiter, indem es die Schwere jedes Problems meldet, es mit dem entsprechenden WCAG-Erfolgskriterium verknüpft und Hinweise zur Behebung gibt. Für Enterprise-Teams kann axe-core direkt in CI/CD-Pipelines integriert werden, sodass Kontrastregressionen vor dem Deployment erkannt werden.

Google Lighthouse, in Chrome DevTools integriert, führt im Rahmen seines Barrierefreiheits-Audits ebenfalls Kontrastprüfungen durch. Es ist ein praktischer erster Durchlauf – besonders nützlich, weil es bereits im Workflow der meisten Entwicklerinnen vorhanden ist – aber es läuft nur auf einem Teil der axe-core-Regeln und ist daher nicht so umfassend wie die vollständige axe-DevTools-Erweiterung.

Eine wichtige Einschränkung: Automatisierte Scanner können den Kontrast für Text, der auf einem Verlaufshintergrund, einem Hintergrundbild, einer halbtransparenten Ebene oder einem Element mit komplexem CSS-Stacking liegt, nicht zuverlässig bewerten. Diese Fälle erfordern eine manuelle Prüfung.

Schritt 2: Den Farbwähler der Chrome DevTools für gezielte Prüfungen nutzen

In Chrome DevTools öffnet das Anklicken des Farbfelds neben einem Farbwert im Styles-Panel einen integrierten Farbwähler, der das aktuelle Kontrastverhältnis zum berechneten Hintergrund des Elements anzeigt. Wenn die Farbe durchfällt, bietet DevTools eine Autokorrektur-Funktion: Es zeigt die nächstgelegenen AA- und AAA-konformen Farben an, sodass du mit einem Klick einen konformen Wert übernehmen kannst. Das ist für schnelle Iterationen während der Entwicklung äußerst wertvoll. DevTools enthält außerdem einen Emulator für Sehbeeinträchtigungen im Rendering-Panel, mit dem du unscharfes Sehen, Protanopie, Deuteranopie, Achromatopsie und andere Zustände simulieren kannst, um ein qualitatives Gefühl dafür zu bekommen, wie farbfehlsichtige Nutzerinnen deine Palette erleben.

Schritt 3: Spezifische Farbkombinationen mit einem dedizierten Checker testen

Zur Validierung einzelner Farbkombinationen isoliert – etwa während eines Design-Reviews in Figma, bevor etwas gebaut wird – ist der WebAIM Contrast Checker (webaim.org/resources/contrastchecker) der Branchenstandard. Du gibst Hex-Werte für Vorder- und Hintergrund ein, und er liefert sofort das Kontrastverhältnis und eine Bestanden/Nicht-bestanden-Bewertung für AA und AAA bei normaler und großer Textgröße. Die Desktop-Anwendung Colour Contrast Analyser (CCA) für Windows und macOS ist ebenso nützlich und bewältigt komplexe Fälle wie halbtransparente Vordergründe und die Pipetten-Abtastung von jedem beliebigen Programm – nicht nur dem Browser.

Schritt 4: Im Kontext testen – Dark Mode, Hover-Zustände und Fokusindikatoren

Hier lassen viele Teams nach. Ein Farbpaar, das im Standard-Light-Theme besteht, kann im Dark Mode komplett durchfallen. Markenakzentfarben, die auf weißem Hintergrund lebendig wirken, werden auf dunklen Flächen oft matschig oder grell. Jeder Interaktionszustand – Hover, Fokus, Aktiv, Besuchte Links – ist eine potenzielle Quelle neuer Kontrastfehler. Ebenso müssen Fokusindikatoren (die sichtbare Umrandung, die erscheint, wenn eine Tastaturnutzerin zu einem Steuerelement tabbt) nach WCAG 2.1 Erfolgskriterium 1.4.11 ein Kontrastverhältnis von 3:1 zu angrenzenden Farben erreichen. Teste immer beide Themes vor dem Release; Dark Mode ist nicht automatisch barrierefrei, nur weil er poliert aussieht.

Die häufigsten Kontrastfehler – und wie man sie behebt

Wenn du die Fehlermuster kennst, die in Audits am häufigsten auftreten, kannst du deine Behebungsarbeit priorisieren. Die meisten Kontrastprobleme fallen in eine vorhersehbare Reihe von Kategorien.

Grau-auf-weiß im Fließtext

Mittlere Grautöne wie #767676 oder #999999 auf weißem Hintergrund sind im modernen Flat Design allgegenwärtig. Für Designerinnen mit kalibrierten Monitoren wirken sie luftig und edel. Sie verfehlen häufig die 4,5:1-Schwelle und sind für Nutzerinnen mit Sehbehinderung unsichtbar. Die Lösung ist meist eine einfache Änderung des Farbwerts – die Verschiebung von #767676 (das mit 4,54:1 gerade so besteht) zu #595959 ergibt ein Verhältnis von 7,0:1 und deutlich bessere Lesbarkeit, bei einem für die meisten sehenden Nutzerinnen minimalen sichtbaren Unterschied.

Wenn du mit HSL arbeitest – einem intuitiveren Farbmodell für Kontrastanpassungen – musst du nur die Lightness-Komponente ändern, um das Kontrastverhältnis zu verändern, während Farbton und Sättigung erhalten bleiben. Auf einem weißen Hintergrund verbessert das Verringern des Lightness-Werts den Kontrast, indem es den Text abdunkelt; auf einem dunklen Hintergrund erhöht das Anheben des Werts die Helligkeit des Textes. Kleine Änderungen der Lightness (2–5 Prozentpunkte) reichen oft aus, um von „nicht bestanden“ zu einem klaren AA-Bestand zu kommen, ohne dein Design merklich zu verändern.

/* Vorher: fällt bei WCAG AA durch (Verhältnis ~3,9:1 auf Weiß) */
.body-text {
  color: #888888;
}

/* Nachher: besteht WCAG AA und AAA (Verhältnis ~7,0:1) */
.body-text {
  color: #595959;
}

Platzhaltertext in Formularfeldern

Platzhaltertext, der mit der Standardformatierung des Browsers gerendert wird – typischerweise ein helles Grau um #AAAAAA oder #BBBBBB – fällt auf einem weißen Eingabefeldhintergrund fast immer bei WCAG AA durch. Viele Designerinnen halten den Kontrast von Platzhaltern bewusst niedrig, um ihn visuell von benutzereingegebenem Inhalt zu unterscheiden, aber das ist keine zulässige Ausnahme. Platzhaltertext ist Benutzeroberflächen-Text und muss den 4,5:1-Standard erfüllen. Verwende einen dunkleren Farbton und nutze Kursivstil, Positionierung oder Animation, um die visuelle Unterscheidung statt über Helligkeit herzustellen.

::placeholder {
  /* Fällt durch: #AAAAAA liegt bei etwa 2,3:1 auf Weiß */
  color: #AAAAAA;
}

::placeholder {
  /* Besteht: #767676 liegt bei etwa 4,54:1 auf Weiß */
  color: #767676;
  font-style: italic; /* Alternative visuelle Kennzeichnung */
}

Weiße oder helle Schrift auf einem mittelhellen Markenfarbton

Markenfarben im mittleren Sättigungsbereich – gängige Blau-, Grün- und Violetttöne im #5–6-Lightness-Bereich von HSL – liefern oft nicht genug Kontrast für weiße Schrift, die darübergelegt wird. Ein kräftiges Markenblau, das im Logo großartig aussieht, kann gegen Weiß nur ein Verhältnis von 2,8:1 erzeugen, weit unter dem Minimum von 4,5:1 für Fließtext. Die Lösung besteht darin, entweder die Hintergrundfarbe zu verdunkeln (den Markenton in deinem Designsystem auf ein 800er- oder 900er-Token zu verschieben), auf dunklen Text auf diesem Hintergrund umzusteigen oder den mittleren Farbton für rein dekorative Elemente zu reservieren, für die keine Kontrastregeln gelten.

Text auf Hintergrundbildern oder Verläufen

Text, der direkt über einem Foto oder einem Verlauf platziert wird, ist einer der kniffligsten Fälle, weil die Hintergrundleuchtdichte nicht einheitlich ist – das Kontrastverhältnis ändert sich über verschiedene Bereiche des Bildes hinweg. Die zuverlässigste Lösung ist eine halbtransparente dunkle oder helle Overlay-Fläche per CSS, die als Pseudo-Element angewendet wird, sodass das Bild darunter sichtbar bleibt. Ein schwarzes Overlay mit etwa 50–60% Deckkraft bringt weißen Text typischerweise von grenzwertigem Kontrast in einen soliden AAA-Bereich.

.hero {
  position: relative;
}

.hero::after {
  content: '';
  position: absolute;
  inset: 0;
  background: rgba(0, 0, 0, 0.55);
}

.hero__text {
  position: relative;
  z-index: 1;
  color: #ffffff;
}

Deaktivierte und sekundäre UI-Elemente

WCAG nimmt deaktivierte UI-Komponenten ausdrücklich von den Kontrastanforderungen aus – ein inaktiver Button muss kein Verhältnis von 4,5:1 erfüllen. Viele Teams überdehnen diese Ausnahme jedoch auf sekundären Text, Bildunterschriften, Hilfetext und Labels, die tatsächlich nicht deaktiviert sind. Wenn ein Element Informationen vermittelt, die die Nutzerin zum Verstehen oder Handeln benötigt, muss es den jeweils geltenden Kontraststandard erfüllen – unabhängig von seiner visuellen Hierarchie. Überprüfe jeden Farbton in der Neutral-Skala deines Designsystems gegen die Hintergründe, auf denen er verwendet wird.

Kontrast in dein Designsystem einbauen

Einzelne Kontrastfehler reaktiv zu beheben, ist langsam und fehleranfällig. Der nachhaltigere Ansatz ist, Konformität beim Kontrast in dein Designsystem einzubetten, sodass barrierefreie Farbkombinationen zum Standardoutput werden, nicht zum nachträglichen Gedanken.

Die Grundlage ist eine sauber abgestufte Token-Skala. Jede Farbe in deiner Palette sollte dokumentierte, vorab berechnete Kontrastverhältnisse zu deinen Standardhintergrundfarben haben. Eine sinnvolle Konvention ist, Tokens nach ihrer Kontrastleistung zu benennen: Ein --color-text-primary-Token sollte auf --color-surface-default immer AA bestehen, und diese Garantie sollte dokumentiert, getestet und durchgesetzt werden. Wenn eine Designerin ein Token zur Textfärbung auswählt, sollte sie sich darauf verlassen können, dass es den Mindeststandard erfüllt, ohne jedes Mal manuell prüfen zu müssen.

CSS-Custom-Properties machen das besonders gut handhabbar. Du kannst deine gesamte Palette als Variablen definieren und sie per Media Queries für den Dark Mode austauschen, ohne Farbkombinationen hart zu codieren – so bleibt das Kontrast-Management an einer zentralen Stelle.

:root {
  --color-surface-default: #ffffff;
  --color-text-primary: #1a1a1a;   /* ~16:1 auf Weiß */
  --color-text-secondary: #595959; /* ~7,0:1 auf Weiß */
  --color-text-subtle: #767676;    /* ~4,54:1 auf Weiß */
  --color-accent: #0052cc;         /* ~8,0:1 auf Weiß */
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-surface-default: #121212;
    --color-text-primary: #ededed;   /* ~14,5:1 auf #121212 */
    --color-text-secondary: #c0c0c0; /* ~9,4:1 auf #121212 */
    --color-text-subtle: #909090;    /* ~5,1:1 auf #121212 */
    --color-accent: #6fa8ff;         /* ~6,5:1 auf #121212 */
  }
}

Beachte die Dark-Mode-Tokenwerte oben. Farben, die auf weißem Hintergrund AA bestehen, fallen auf dunklen Flächen oft durch – und umgekehrt. Beim Design für den Dark Mode solltest du vermeiden, deine Light-Mode-Werte einfach zu invertieren. Voll gesättigte oder reinweiße Schrift auf reinem Schwarz (#000000) kann Halation verursachen – einen visuellen Unschärfeeffekt bei extrem hohem Kontrast, der für manche Nutzerinnen schwierig ist. Eine Fläche von #121212 und Text von #ededed ist eine deutlich angenehmere Kombination, die dennoch hervorragenden Kontrast bietet.

Automatisierte Kontrasttests lassen sich auch in deine Komponenten-Pipeline integrieren. Bibliotheken wie axe-core können in Jest- oder Playwright-Tests aufgerufen werden, um Kontrastfehler als Teil deiner Standard-Test-Suite zu markieren und Regressionen in dem Moment zu erkennen, in dem sie eingeführt werden – statt erst bei einem externen Audit.

Was automatisierte Tools nicht erkennen können – und was du dagegen tun kannst

Automatisiertes Scannen ist ein mächtiger Ausgangspunkt, hat aber klare Grenzen. Automatisierte Tests können typischerweise zwischen 20 und 30 Prozent potenzieller WCAG-Verstöße erkennen, wenn man das gesamte Spektrum der Barrierefreiheitskriterien betrachtet – obwohl Farbkontrast zu den zuverlässigeren Kategorien gehört. Dennoch entgehen automatisierten Tools regelmäßig mehrere Kontrastfehler-Szenarien.

Text auf Verläufen und Hintergrundbildern ist der häufigste blinde Fleck. Axe und WAVE können Farbkombinationen identifizieren, wenn Vorder- und Hintergrund jeweils einen einzigen, deterministischen Farbwert haben. Wenn der Hintergrund ein CSS-Verlauf oder ein JPEG-Foto ist, kann das Tool oft kein sinnvolles Verhältnis berechnen und markiert das Element eher als „muss überprüft werden“ denn als eindeutigen Fehler. Diese Fälle erfordern eine manuelle Prüfung, idealerweise mit einem Pixel-genauen Pipetten-Tool wie dem Colour Contrast Analyser, um tatsächliche Vorder- und Hintergrundwerte an mehreren Punkten im Überlappungsbereich zu sampeln.

Halbtransparente und zusammengesetzte Farben erzeugen ähnliche Herausforderungen. Eine weiße Button-Beschriftung auf einem blauen Button, der über einem grünen Seitenhintergrund gerendert wird, hat einen berechneten Kontrast, der von allen drei Farbschichten abhängt – eine Berechnung, die DOM-basierte Tools nicht immer korrekt durchführen können. Flache die Alpha-Werte manuell ab oder nutze ein Screenshot-basiertes Tool, um die gerenderte Pixel-Farbe zu sampeln.

Dynamisch generierte Zustände – JavaScript-gesteuerte Tooltips, Modaldialoge, Dropdown-Menüs, Fehlermeldungen – werden dynamisch gerendert und sind möglicherweise nicht sichtbar, wenn ein automatisierter Scan läuft. Tools, die skriptbar sind (wie axe-core in einem Playwright-Test), können diese Zustände ansteuern und bewerten, aber die Konfiguration dieser Abdeckung erfordert bewussten Aufwand. Baue sie in deinen QA-Workflow ein und nimm Kontrast in deine Definition of Done für jede neue Komponente auf, die neue Farbkombinationen einführt.

Schließlich ist die mathematische Kontrastformel der WCAG, so etabliert sie auch ist, kein perfekter Stellvertreter für die wahrgenommene Lesbarkeit. Die Formel berücksichtigt weder Schriftstärke noch Laufweite oder Antialiasing. Eine dünn gesetzte Schrift bei 4,5:1 wird sich schwerer lesen lassen als dasselbe Verhältnis mit einer kräftigeren Schrift. Behandle die WCAG-Schwelle als Untergrenze – das Minimum, das du erreichen musst – und nicht als Optimierungsziel. Strebe, wo Typografie, Lesbarkeit und Marke es zulassen, 7:1 an und führe Nutzertests mit Menschen durch, die tatsächlich eine Sehbehinderung haben, um zu validieren, dass deine Farbwahl in der realen Welt funktioniert.

Wesentliche Erkenntnisse

Farbkontrast ist der Barrierefreiheitsfehler Nummer eins im Web. Text mit geringem Kontrast trat 2026 auf 83,9% der eine Million meistbesuchten Startseiten auf. Unabhängig davon, wie ausgereift das Barrierefreiheitsprogramm deiner Organisation ist, ist Kontrast der wahrscheinlichste Bereich, in dem du derzeit ungelöste Probleme hast – und er gehört zu den am leichtesten zu behebenden.
Kenne die Schwellenwerte, die für deine Inhalte gelten. WCAG AA verlangt 4,5:1 für normalen Text, 3:1 für großen Text (18pt+ oder 14pt+ fett) und 3:1 für nicht-textliche UI-Komponenten wie Eingaberahmen und reine Icon-Steuerelemente. Diese gelten unabhängig davon, ob deine Oberfläche Light oder Dark Mode verwendet.
Teste in Schichten: automatischer Scan, DevTools-Inspektion, eigenständiger Checker und manuelle Prüfung. Führe axe DevTools oder WAVE für schnelle Vollseiten-Scans aus; nutze den integrierten Farbwähler der Chrome DevTools für schnelle Iterationen; verwende den WebAIM Contrast Checker oder CCA zur Validierung spezifischer Paare; und prüfe Verläufe, Bilder und dynamische Zustände manuell, die automatisierte Tools nicht zuverlässig bewerten können.
Behebe Kontrast auf Designsystem-Ebene, nicht auf Komponenten-Ebene. Baue eine Token-Skala mit vorvalidierten Kontrastverhältnissen auf, dokumentiere, welche Text-Tokens auf welchen Surface-Tokens bestehen, und erzwinge Konformität durch automatisierte Tests in CI. So eliminierst du ganze Klassen von Fehlern, bevor sie in die Produktion gelangen.
Behandle WCAG als Untergrenze, nicht als Ziel. 4,54:1 zu erreichen, besteht gerade so – lässt aber viele Nutzerinnen dennoch kämpfen. Wo Typografie, Lesbarkeit und Marke es zulassen, strebe 7:1 an und nutze Schriftstärke, Größe und Laufweite als zusätzliche Hebel, um Text wirklich angenehm lesbar zu machen, nicht nur technisch konform.

Farbenkontrast im Webdesign: So testen und beheben Sie Kontrastprobleme