Farbkontraste prüfen und korrigieren: WCAG-Kontrastverhältnis einfach erklärt

Was ist das Kontrastverhältnis?

Das Kontrastverhältnis beschreibt den Helligkeitsunterschied zwischen zwei Farben auf einer Skala von 1:1 (kein Kontrast, gleiche Farbe) bis 21:1 (maximaler Kontrast, Schwarz auf Weiß). Die WCAG 2.1 definiert in mehreren Success Criteria exakte Schwellenwerte:

• SC 1.4.3 (Contrast Minimum, AA): Normaler Text muss mindestens 4,5:1 Kontrast zum Hintergrund haben. Großer Text (ab 18pt oder 14pt fett) mindestens 3:1.
• SC 1.4.6 (Enhanced Contrast, AAA): Normaler Text mindestens 7:1, großer Text mindestens 4,5:1. Dieser erhöhte Standard ist empfehlenswert, aber nicht vom BFSG verlangt.
• SC 1.4.11 (Non-text Contrast): UI-Komponenten und grafische Objekte (Icons, Formularrahmen, Fokus-Indikatoren) benötigen mindestens 3:1 Kontrast zu angrenzenden Farben.

Diese Werte stellen sicher, dass auch Menschen mit Sehschwäche – rund 8 % der männlichen und 0,5 % der weiblichen Bevölkerung haben eine Farbsehschwäche – den Inhalt zuverlässig lesen können.

Die Kontrast-Berechnungsformel verstehen

Das Kontrastverhältnis ist kein subjektiver Wert, sondern wird mathematisch aus der relativen Luminanz zweier Farben berechnet. Die Formel lautet:

Kontrastverhältnis = (L1 + 0,05) / (L2 + 0,05) Weitere Informationen finden Sie im Farbkontrast-Glossar.

Dabei ist L1 die relative Luminanz der helleren Farbe und L2 die der dunkleren. Die relative Luminanz selbst wird aus den linearisierten RGB-Werten ermittelt:

L = 0,2126 × R + 0,7152 × G + 0,0722 × B

Vor der Berechnung müssen die sRGB-Werte (0–255) in den linearen Farbraum transformiert werden. In der Praxis brauchst du diese Formel nicht selbst anwenden – die Tools erledigen das automatisch. Aber das Verständnis hilft, warum manche Farbkombinationen überraschend schlecht abschneiden: Ein kräftiges Rot (#FF0000) auf Schwarz hat nur 5,25:1, weil Rot einen geringen Luminanz-Anteil hat.

Warum Kontraste einer der häufigsten BFSG-Verstöße sind

Viele Designer wählen Farben nach Ästhetik, nicht nach Lesbarkeit. Hellgraue Texte auf weißem Hintergrund sehen elegant aus, haben aber oft nur ein Verhältnis von 2:1 oder 3:1 – zu wenig für BFSG-Konformität gemäß § 3 BFSG in Verbindung mit der EN 301 549.

Besonders problematisch sind diese Bereiche:

• Platzhalter-Text in Formularen: Oft hellgrau (#CCCCCC) auf Weiß – Verhältnis nur 1,6:1.
• Footer-Links: Helle Farben auf dunklem Hintergrund, die knapp unter 4,5:1 liegen.
• Text auf Bildern: Ohne Overlay ist der Kontrast an wechselnden Stellen des Bildes nicht gewährleistet.
• Deaktivierte Buttons: Grau auf Grau – selbst wenn deaktiviert, sollten sie erkennbar bleiben.
• Fokus-Indikatoren: Ein hellblauer Fokusrahmen auf weißem Hintergrund erfüllt SC 1.4.11 nicht.

Laut dem WebAIM Million Report scheitern über 80 % aller Webseiten an Kontrast-Anforderungen – es ist damit der häufigste einzelne Barrierefreiheits-Fehler weltweit.

Kostenlose Tools zur Kontrast-Prüfung

Du musst Kontraste nicht manuell berechnen. Diese Tools erledigen das zuverlässig:

WebAIM Contrast Checker

Unter webaim.org/resources/contrastchecker gibst du zwei Hex-Farben ein und siehst sofort das Verhältnis plus die AA/AAA-Bewertung für normalen und großen Text. Ideal für schnelle Einzelprüfungen während des Designs.

Colour Contrast Analyser (CCA)

Ein kostenloses Desktop-Tool der Paciello Group (jetzt TPGi). Der Vorteil: Du kannst mit einer Pipette direkt Farben von deinem Bildschirm aufnehmen – auch aus Bildern, PDFs oder nativen Anwendungen. Besonders nützlich für die Prüfung von Text auf Fotohintergründen.

Browser DevTools (Chrome, Firefox, Edge)

In den Chrome DevTools klickst du im Elements-Tab auf eine Farbangabe in den CSS-Styles. Im Farbwähler erscheint automatisch das Kontrastverhältnis und ein Hinweis, ob AA und AAA erfüllt sind. Zusätzlich kannst du über Rendering → Emulate vision deficiencies verschiedene Formen von Farbenblindheit simulieren.

WAVE Browser Extension

Markiert Kontrast-Probleme direkt auf der Seite mit roten Icons. Besonders hilfreich für einen schnellen Überblick über alle Kontrastfehler einer Seite. Lies dazu auch unseren kompletten Tool-Überblick für Barrierefreiheits-Tests.

Und natürlich: bf-check.de prüft Kontraste automatisch im Rahmen des BFSG-Scans.

Farbenblindheit simulieren und berücksichtigen

Ausreichender Kontrast allein reicht nicht, wenn dein Design nur über Farbe Informationen transportiert. Menschen mit Deuteranopie (Grünblindheit), Protanopie (Rotblindheit) oder Tritanopie (Blaublindheit) können bestimmte Farbunterschiede nicht wahrnehmen.

WCAG SC 1.4.1 (Use of Color) fordert: Farbe darf nicht das einzige visuelle Mittel sein, um Informationen zu vermitteln. Das bedeutet konkret:

• Fehlerhafte Formularfelder nicht nur rot umranden, sondern zusätzlich ein Icon oder Text anzeigen.
• Links im Fließtext nicht nur durch Farbe, sondern auch durch Unterstreichung kennzeichnen.
• Diagramme mit Mustern oder Beschriftungen ergänzen, nicht nur mit Farben unterscheiden.

In Chrome DevTools kannst du unter Rendering → Emulate vision deficiencies die verschiedenen Formen von Farbenblindheit simulieren. Firefox bietet eine ähnliche Funktion unter Barrierefreiheit → Farbenblindheit simulieren.

Kontraste korrigieren ohne das Design zu zerstören

Oft reicht eine kleine Anpassung: Statt #999999 auf Weiß (Verhältnis 2,8:1) nutze #595959 (Verhältnis 7:1). Der Unterschied ist visuell subtil, aber der Kontrast verdoppelt sich. Grundregel: Dunkle Texte dunkler machen, nicht helle Hintergründe dunkler.

Weitere bewährte Strategien:

• Schriftgröße erhöhen: Ab 18pt (24px) oder 14pt fett (ca. 19px) gilt die niedrigere Schwelle von 3:1 – manchmal reicht das, um ein Designproblem zu lösen.
• Halbtransparente Overlays: Bei Text auf Bildern ein background: rgba(0, 0, 0, 0.6) hinter den Text legen.
• Farbpalette systematisch prüfen: Erstelle eine Kontrast-Matrix deiner Designfarben und prüfe jede Kombination.

Für ein vollständiges Redesign mit Barrierefreiheits-Checkliste findest du bei uns eine Schritt-für-Schritt-Anleitung.

CSS Custom Properties für konsistente Kontraste

Mit CSS Custom Properties (Variablen) definierst du deine Farbpalette zentral und stellst sicher, dass kontrastgeprüfte Werte überall konsistent verwendet werden:

:root {
  --color-text: #1a1a2e;          /* Luminanz 0,026 */
  --color-text-muted: #4a5568;    /* auf Weiß: 7,1:1 ✓ */
  --color-bg: #ffffff;
  --color-primary: #1e40af;       /* auf Weiß: 7,8:1 ✓ */
  --color-error: #b91c1c;         /* auf Weiß: 6,1:1 ✓ */
  --color-focus: #1e40af;         /* Fokusrahmen: 7,8:1 ✓ */
}

/* Dark Mode mit geprüften Kontrasten */
@media (prefers-color-scheme: dark) {
  :root {
    --color-text: #e2e8f0;        /* auf Dunkel: 11,3:1 ✓ */
    --color-text-muted: #a0aec0;  /* auf Dunkel: 5,6:1 ✓ */
    --color-bg: #1a202c;
    --color-primary: #63b3ed;     /* auf Dunkel: 7,2:1 ✓ */
    --color-error: #fc8181;       /* auf Dunkel: 5,5:1 ✓ */
  }
}

Der Vorteil: Du änderst die Farbwerte an einer Stelle und die gesamte Seite ist automatisch aktualisiert. Außerdem ist der Dark Mode sofort mitabgedeckt.

Dark Mode: Kontraste in beiden Welten sicherstellen

Immer mehr Nutzer verwenden den Dark Mode. Die WCAG-Anforderungen gelten für beide Darstellungsmodi gleichermaßen. Häufige Fehler im Dark Mode:

• Reißender Weißtext auf Schwarz: Reines Weiß (#FFFFFF) auf reinem Schwarz (#000000) hat zwar 21:1 Kontrast, kann aber für Menschen mit Astigmatismus (ca. 30 % der Bevölkerung) blendend wirken. Besser: Leicht getöntes Weiß auf Dunkelgrau.
• Farbige Links: Ein Link in #3b82f6 hat auf Weiß 4,7:1 – knapp AA. Auf dunklem Hintergrund (#1a202c) hat dieselbe Farbe nur 3,7:1 – durchgefallen.
• Schatten und Trennlinien: Visuelle Trennelemente, die im Light Mode funktionieren, verschwinden oft im Dark Mode.

Teste beide Modi separat. Ein responsives Design mit Barrierefreiheit berücksichtigt auch unterschiedliche Farbschemata.

Hinweis: Dieser Artikel dient der allgemeinen Information über Barrierefreiheits-Anforderungen und ersetzt keine Rechtsberatung. Die WCAG-Kriterien und BFSG-Anforderungen können sich ändern. Für eine verbindliche Einschätzung deiner konkreten Situation wende dich an einen spezialisierten Rechtsberater.

Häufig gestellte Fragen

Kontrast bei Buttons, Icons und Fokusrahmen

Neben Fließtext verlangt die WCAG auch für grafische Bedienelemente einen Mindestkontrast: Buttonränder, Icon-Symbole, Eingabefeld-Umrandungen und Fokusrahmen müssen sich ausreichend von ihrer Umgebung abheben, damit Nutzer mit Sehschwäche sie überhaupt als klickbare oder aktive Elemente erkennen. Dieser Kontrast wird getrennt von der Textlesbarkeit bewertet und beim Redesign häufig übersehen, weil die Aufmerksamkeit meist auf Schriftfarben liegt.

Besonders anfällig sind dezente, moderne Interfaces mit dünnen grauen Linien und flachen Buttons ohne sichtbaren Rahmen: Sieht ein Eingabefeld im unfokussierten Zustand aus wie normaler Text, verschwimmt die Grenze zwischen Inhalt und Bedienelement. Ein kräftigerer Rahmen oder ein deutlicher Hintergrund im Fokuszustand behebt das Problem meist, ohne dass die restliche Gestaltung angepasst werden muss.

Text über Bildern und Verlaufshintergründen zuverlässig lesbar halten

Steht Text direkt über einem Foto oder einem Farbverlauf, lässt sich das Kontrastverhältnis nicht mehr an einer einzelnen Hintergrundfarbe ablesen, denn an manchen Bildstellen kann der Kontrast ausreichen, an anderen nicht. Ein heller Schriftzug über einem Himmelfoto etwa kann über einer Wolke gut lesbar sein und über einem dunklen Ast fast verschwinden.

Bewährt hat sich ein halbtransparenter, einfarbiger Überlagerungsbalken zwischen Bild und Text, der unabhängig vom Motiv einen konstanten Hintergrund erzeugt und sich zuverlässig prüfen lässt. Alternativ hilft ein kräftiger Schlagschatten oder eine dünne Textkontur, die den Kontrast zum Bild in jedem Bildbereich erhöht. Wichtig ist, die Kombination an der dunkelsten und hellsten Bildstelle zu testen, nicht nur an einer einzigen Beispielstelle.

Nicht-Text-Kontrast: Buttons, Icons und Fokus-Rahmen

Neben dem Textkontrast nach WCAG 1.4.3 gibt es ein zweites, oft übersehenes Kriterium: WCAG 1.4.11 (Nicht-Text-Kontrast) verlangt ein Kontrastverhältnis von mindestens 3:1 für Bedienelemente und grafische Objekte, die zum Verständnis notwendig sind – etwa Rahmen von Eingabefeldern, Icon-Buttons oder die Balken eines Diagramms. Dieses Kriterium wird deutlich seltener geprüft als der Textkontrast, obwohl es genauso zur BFSG-Konformität gehört.

Ein klassisches Beispiel: ein schlanker, hellgrauer Rahmen um ein Eingabefeld auf weißem Hintergrund. Der Text im Feld mag ausreichend Kontrast haben, doch die Feldgrenze selbst ist für sehbehinderte Nutzer kaum erkennbar. Ohne sichtbare Begrenzung ist unklar, wo ein Feld beginnt und endet, besonders wenn mehrere Felder dicht beieinander liegen.

Noch häufiger betrifft das Problem den Fokus-Rahmen: Viele Redesigns entfernen die browserseitige Standardmarkierung mit outline: none, weil sie optisch nicht ins Design passt, ohne einen gleichwertigen Ersatz zu definieren. Tastaturnutzer verlieren dadurch komplett die Orientierung, welches Element gerade aktiv ist. WCAG 2.4.7 (Fokus sichtbar) verlangt, dass der Fokus jederzeit erkennbar bleibt, und in Kombination mit 1.4.11 muss dieser Fokusrahmen ebenfalls das 3:1-Verhältnis zur Umgebung einhalten.

Bei der Prüfung hilft es, sich mit der Tabulatortaste einmal komplett durch eine Seite zu klicken und bei jedem Element bewusst zu beobachten, ob der Fokus deutlich sichtbar ist – nicht nur ein hauchdünner, kaum wahrnehmbarer Strich in einer ähnlichen Farbe wie der Hintergrund.