WCAG-Farbkontrast online prüfen: AA, AAA und großer Text

Zu geringer Kontrast zwischen Text und Hintergrund ist der häufigste Barrierefreiheitsfehler im Web. Prüfen Sie AA/AAA, indem Sie einfach zwei Farben einfügen — kein Plugin, keine Erweiterung nötig.

13.09.2026

10 Min. Lektüre

Teilen Sie diesen Artikel:

accessibilitywcagcolor-contrastCSSAnleitung

Kontrast, der häufigste Barrierefreiheitsfehler im Web

Jedes Jahr stuft der WebAIM-Million-Audit unzureichenden Textkontrast als häufigsten erkannten WCAG-Verstoß ein, noch vor fehlendem Alt-Text oder nicht beschrifteten Links. Der Audit analysiert die meistbesuchten Startseiten im Web. Kontrast ist zudem eines der wenigen Barrierefreiheitskriterien, die sich ohne Screenreader und ohne vollständiges Audit prüfen lassen. Der FastMinify-Kontrastprüfer berechnet das WCAG-2.2-Verhältnis zwischen zwei CSS-Farben (HEX, RGB, HSL, OKLCH, color() oder benannte Farben). Schon beim Tippen zeigt er AA- und AAA-Ergebnisse für normalen Text, großen Text und Nicht-Text-Elemente. Es wird nichts an einen Server gesendet. Er geht über ein einzelnes Farbpaar hinaus: Ein Matrixmodus prüft eine ganze Vordergrundpalette gegen eine ganze Hintergrundpalette in einem Durchgang. Die übrigen Werkzeuge liegen im Farbe-&-CSS-Hub.

Ergebnisse nach WCAG 2.2 live: AA, AAA und Nicht-Text 3:1 (SC 1.4.11) für jedes Farbpaar

Matrixmodus mit bis zu 16 Farben pro Achse, um die Palette eines ganzen Design-Systems in einem Durchgang zu prüfen

Deckkraft-Regler, um halbtransparenten Text gegen seinen tatsächlichen Hintergrund zu prüfen

Experimentelle APCA-Überlagerung (WCAG-3-Kandidat) zusätzlich zum klassischen WCAG-2.2-Verhältnis

Teilbare URL: die genaue Prüfung an das Designteam schicken oder in einen Pull Request einfügen

100 % im Browser, keine Markenfarbe verlässt Ihren Tab

Die Kontrastfehler, die immer wieder vorkommen

Das "elegante" hellgraue Textfeld auf Weiß

Ein Grauton #999999 auf Weiß ergibt ein Verhältnis von etwa 2,85:1, deutlich unter dem AA-Schwellenwert von 4,5:1. Trotzdem ist er eine der häufigsten Designentscheidungen für Sekundärtext, Platzhalter und Bildunterschriften.

Platzhaltertext in Formularen in zu hellem Grau (oft unter 3:1)

Metadaten und Bildunterschriften ("vor 2 Std.", "250 Aufrufe") in blassem Grau auf hellem Hintergrund

Ein "neutrales" Grau aus einem Figma-Mockup übernehmen, ohne das tatsächliche Verhältnis zu prüfen

"Auf meinem Bildschirm lässt es sich gut lesen" mit einem konformen Verhältnis verwechseln (Helligkeit, Kalibrierung, Ermüdung schwanken)

Nutzer mit Sehbehinderung, Personen in hellen Umgebungen (draußen, schlecht kalibrierte Bildschirme) und farbenblinde Nutzer verlieren einen Teil des Inhalts. Ein Audit mit axe oder Lighthouse schlägt in der CI ebenfalls fehl, wenn der Kontrast automatisch geprüft wird.

Ein Button in Markenfarbe, der still und leise durchfällt

"Weiche" Markenfarben (Pastellblau, Mintgrün, Hellorange) werden oft für die visuelle Identität gewählt, ohne je mit weißem Text darauf getestet zu werden.

Hellblauer Primär-Button + weißer Text: das Verhältnis liegt manchmal unter 3:1

Ein Zustand „disabled“, der optisch wie ein aktiver Zustand mit schwachem Kontrast aussieht

Monochrome Icons auf farbigem Hintergrund, ohne den Nicht-Text-Kontrast (3:1) zu prüfen

Nur der Standard-Button-Zustand wird getestet, nie hover/focus/disabled

Ein unleserlicher oder kaum sichtbarer Aufruf zum Handeln senkt die Klickrate. Über die Barrierefreiheit hinaus ist das auch ein Problem für die Konversion.

Text auf einem Bild ohne Abdunkelung

Eine weiße Überschrift funktioniert über dem dunklen Teil des Himmels auf einem Hero-Foto, wird aber über dem hellen Teil einer Wolke unlesbar. Der Kontrast schwankt je nach Position des Textes im Bild.

Kein dunkler Verlauf und keine abdunkelnde Überlagerung unter dem Text

Text nur an der Desktop-Version des Bildes getestet, nicht am Mobile-Zuschnitt

Ein leichter Schlagschatten als einzige Lesbarkeitsgarantie

Ein wechselndes Hintergrundbild (Karussell, Nutzer-Upload) ohne garantierten Kontrast

Fügen Sie zwischen Bild und Text einen halbtransparenten Verlauf ein (Schwarz mit 40–60 %). Prüfen Sie den Kontrast dann gegen die zusammengesetzte Farbe des Verlaufs, nicht gegen das Rohbild.

Sichtbarer Fokus entfernt, um "aufzuräumen"

outline: none ohne Ersatz zerstört die Tastaturnavigation. Der Nicht-Text-Kontrast (SC 1.4.11) gilt auch für Fokusindikatoren.

`outline: none` ohne alternativen Fokusring

Ein individueller Fokusring, der gegenüber dem Hintergrund zu blass ist (oft unter 3:1)

Sichtbarer Fokus nur im hellen Modus getestet, im Dark Mode vergessen

Keine Kontrastprüfung bei Rändern von Formularfeldern

Tastaturnutzer und Nutzer von Eingabehilfen (Switch Access) verlieren die visuelle Orientierung auf der Seite vollständig.

Welches Verhältnis für AA, AAA und großen Text gilt

Normaler Text, AA (4,5:1) oder AAA (7:1)

Das Kriterium WCAG 1.4.3 (Contrast Minimum) verlangt für normalen Text auf Stufe AA ein Verhältnis von mindestens 4,5:1. Die strengere Stufe AAA (Kriterium 1.4.6) erhöht die Anforderung auf 7:1. Fast alle gesetzlichen Vorgaben zielen auf Stufe AA (BITV und EN 301 549 in Europa, ADA in den USA, RGAA in Frankreich). AAA bleibt empfohlen, wird aber selten für eine ganze Website vorgeschrieben.

AA (4,5:1): die gesetzliche Mindestanforderung in den meisten Barrierefreiheitsvorschriften

AAA (7:1): empfohlen für kritische Inhalte wie Zahlungsformulare oder medizinische und rechtliche Inhalte

Ein Verhältnis von 21:1 (reines Schwarz auf reinem Weiß) ist das theoretische Maximum, mehr ist nicht möglich

Ein Verhältnis, das auf den ersten Blick gut aussieht (zum Beispiel 4,2:1), kann AA knapp verfehlen: Prüfen Sie immer die genaue Zahl, nicht den optischen Eindruck

Großer Text, bei dem der Schwellenwert auf 3:1 (AA) oder 4,5:1 (AAA) sinkt

WCAG definiert „großen Text“ als Text ab 24 px, also 18 pt, oder ab 18,67 px, also 14 pt, wenn er fett ist (Schriftstärke ab 700). Unterhalb dieser Schwellenwerte gilt Text als normal, selbst wenn er groß wirkt. FastMinify bestimmt den passenden Schwellenwert aus der eingegebenen Größe und Stärke.

≥ 24px, beliebige Stärke: großer Text → AA = 3:1, AAA = 4,5:1

≥ 18,67px UND Stärke ≥ 700 (fett): großer Text → gleiche reduzierte Schwellenwerte

17 px fett zählt NICHT als großer Text, eine häufige Falle

Eine H1 mit 40 px profitiert vom reduzierten Schwellenwert, eine fette Plakette mit 12 px nie

Nicht-Text-Kontrast (SC 1.4.11), 3:1 für die Oberfläche

Seit WCAG 2.1 verlangt das Kriterium 1.4.11 (Non-text Contrast) ein Verhältnis von mindestens 3:1 zwischen UI-Komponenten und ihrer angrenzenden Farbe. Das betrifft Ränder von Formularfeldern, Kontrollkästchen, bedeutungstragende Icons und Fokusindikatoren.

Nicht fokussierter Rand eines Formularfelds: mindestens 3:1 gegenüber dem Seitenhintergrund

Fokusring (outline/box-shadow): mindestens 3:1 gegenüber Hintergrund UND Element

Rein dekorative Icons (ohne Information) sind von diesem Kriterium ausgenommen

Der FastMinify-Prüfer zeigt dieses Ergebnis separat an: Ein Paar kann bei Nicht-Text bestehen und bei normalem Text durchfallen

Wie das Kontrastverhältnis tatsächlich berechnet wird

Die WCAG-Formel beruht auf der relativen Leuchtdichte, nicht auf dem Farbton

Das WCAG-2.x-Verhältnis vergleicht die relative Leuchtdichte beider Farben. Das ist ein Wert von 0 bis 1, abgeleitet aus linearisierten RGB-Kanälen und gewichtet mit 0,2126 für Rot, 0,7152 für Grün und 0,0722 für Blau. Das menschliche Auge nimmt Grün nämlich deutlich intensiver wahr als Blau. Das endgültige Verhältnis ist (L1 + 0,05) / (L2 + 0,05), wobei L1 die Leuchtdichte der helleren Farbe ist. Deshalb können zwei „deutlich unterschiedliche“ Farben ein ähnliches Verhältnis ergeben. Zwei ähnlich wirkende Farbtöne können dagegen sehr unterschiedliche Leuchtdichten haben.

Vorher

color: #999999;
background: #ffffff;
/* Verhältnis ≈ 2,85:1 → AA nicht erfüllt (normaler Text) */

Nachher

color: #595959;
background: #ffffff;
/* Verhältnis ≈ 7,0:1 → AAA erfüllt (normaler Text) */

Ergebnis zwischen 1:1 bei identischen Farben und 21:1 bei reinem Schwarz auf reinem Weiß

Grün wiegt in der Formel schwerer als Blau. Ein kräftiges Blau auf Weiß scheitert daher oft früher als ein Grün mit vergleichbarer wahrgenommener Helligkeit

Die Formel ignoriert den wahrgenommenen Farbton, für das klassische WCAG-Verhältnis zählt nur die Leuchtdichte

FastMinify akzeptiert HEX, RGB, HSL, OKLCH und color() als Eingabe und konvertiert sie vor der Berechnung nach sRGB (über colorjs.io)

APCA, der Kandidat für WCAG 3 (experimentelle Vorschau)

Das WCAG-2.x-Verhältnis hat eine bekannte Schwäche: Es behandelt „Schwarz auf Weiß“ und „Weiß auf Schwarz“ symmetrisch, was nicht immer der tatsächlichen Wahrnehmung entspricht. APCA (Advanced Perceptual Contrast Algorithm), ein Kandidat für WCAG 3, berücksichtigt die Polarität, also hellen Text auf dunklem Grund oder umgekehrt. Auch die Schriftgröße fließt ein, die Bewertung wird dadurch feiner. FastMinify bietet eine optionale APCA-Überlagerung zusätzlich zum offiziellen WCAG-2.2-Verhältnis an, nicht als Ersatz, da WCAG 3 noch kein veröffentlichter Standard ist.

APCA liefert einen Lc-Wert (Lightness Contrast) statt eines klassischen Verhältnisses

Die Polarität (normal oder umgekehrt) beeinflusst den Wert: Dasselbe Farbpaar hat je nach Zuordnung zu Vorder- und Hintergrund einen anderen Lc-Wert

Aktuell zählt für die rechtliche Konformität ausschließlich das WCAG-2.2-Verhältnis (AA/AAA)

Nützlich, um sich auf einen künftigen Wechsel zu WCAG 3 vorzubereiten, aber nicht für ein aktuelles Konformitätsaudit

Vom Farbpaar zur kompletten Palette mit dem Kontrastprüfer

Ein Farbpaar prüfen

Öffnen Sie den Kontrastprüfer und fügen Sie Vordergrund- und Hintergrundfarbe in einem beliebigen CSS-Format ein (HEX, RGB, HSL, OKLCH, benannt). Verhältnis sowie AA-, AAA- und Nicht-Text-Ergebnis aktualisieren sich live. Passen Sie Textgröße und -stärke an, um zu sehen, wie der Schwellenwert für „großen Text“ automatisch greift.

Zuerst beide Farben einfügen

Vordergrund und Hintergrund, in jedem gültigen CSS-Format. Keine manuelle Umrechnung nötig.

Danach Textgröße und -stärke einstellen

Standard ist 16 px/400 (normaler Text). Wechseln Sie zu 24 px oder 18,67 px fett, um eine Überschrift zu testen: Der Schwellenwert für „großen Text“ (3:1/4,5:1) greift automatisch.

Zum Schluss das Ergebnis ablesen

Exaktes Verhältnis, zum Beispiel 4,87:1, Stufe AA, AAA, AA groß oder Fehler für Text und ein separates Ergebnis für den Nicht-Text-Kontrast (3:1, SC 1.4.11).

Einen Button und seinen disabled-Zustand prüfen

Ein Primär-Button hat oft drei Farbvarianten (normal, hover, disabled), die einzeln oft ungetestet bleiben.

Testen Sie den Text des Buttons auf dem „normalen“ Hintergrund und streben Sie mindestens AA (4,5:1) an

Testen Sie dasselbe Paar im Zustand „hover“: Die Farbe ändert sich oft, das Verhältnis also auch

Testen Sie den Zustand „disabled“ separat. Ein niedriges Verhältnis ist dort akzeptabel, wenn der Zustand wirklich nicht interaktiv ist und entsprechend angekündigt wird (aria-disabled)

Prüfen Sie den Rand des Buttons (falls sichtbar) gegen den Seitenhintergrund: Das ist Nicht-Text-Kontrast mit einem Schwellenwert von 3:1

Mit dem Matrixmodus eine ganze Palette auf einmal prüfen

Statt die Kombinationen eines Design-Systems einzeln zu testen, fügen Sie Ihre Textfarben in Zeilenfarben und Ihre Hintergrundfarben in Spaltenfarben ein. Nutzen Sie eine Farbe pro Zeile, bis zu 16 pro Achse. Das Ergebnis ist ein Raster mit dem Ergebnis jeder Kreuzung, das Sie nach Stufe filtern können (AAA, AA, AA groß oder Fehler).

Nützlich, um alle Farb-Tokens eines Design-Systems in einem Durchgang zu validieren

Filter nach Stufe: schnell nur die durchgefallenen Kombinationen isolieren

Erkennt "Grenzfälle" (z. B. 4,4:1, knapp unter dem AA-Schwellenwert), die ein manueller Paarvergleich leicht übersehen würde

Funktioniert mit denselben Farbformaten wie der Paarmodus (HEX/RGB/HSL können in derselben Liste gemischt werden)

Eine Prüfung mit dem Team teilen

Jede Prüfung (Farben, Textgröße, Matrix- oder Paarmodus, APCA-Optionen) wird in der URL kodiert. Kopieren Sie den Link aus der Adressleiste oder nutzen Sie die Schaltfläche Diese Einstellungen teilen. Fügen Sie ihn danach in einen Pull Request, ein Ticket oder eine Nachricht an Ihr Designteam ein. Die Seite öffnet sich exakt im selben Zustand.

Keine serverseitige Speicherung: Der gesamte Zustand steckt in den URL-Parametern

Praktisch, um einen bei der Code-Review gefundenen Kontrastfehler zu dokumentieren

Der Link bleibt unbegrenzt gültig, solange das Tool online ist

Kontrast zum CI-Kriterium machen statt zum Hin und Her im Design

Erkennung mit axe-core oder Lighthouse CI automatisieren

Ein manueller Prüfer eignet sich für den Entwurf einer Palette. Um Regressionen zu vermeiden, sollte der Kontrast außerdem bei jedem Pull Request automatisch geprüft werden. axe-core und Lighthouse CI erkennen die meisten Kontrastfehler bei statischem Text. Mit Text über Bildern oder Verläufen tun sie sich schwerer.

Einfaches Beispiel

// axe-core mit Playwright — Test schlägt bei unzureichendem Kontrast fehl
import { test, expect } from '@playwright/test'
import AxeBuilder from '@axe-core/playwright'

test('keine Kontrastregression', async ({ page }) => {
  await page.goto('/')
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2aa'])
    .analyze()

  const contrastIssues = results.violations.filter(
    (v) => v.id === 'color-contrast'
  )
  expect(contrastIssues).toEqual([])
})

FastMinify-Kontrastprüfer

Schnelle manuelle Prüfung ohne Installation und ohne gesendete Daten. Der Matrixmodus, einzigartig unter diesen Optionen, prüft ein komplettes Design-System in einem Durchgang, und die teilbare URL erleichtert die Zusammenarbeit zwischen Design und Entwicklung. Einschränkung: Es ist eine manuelle Prüfung, die kein automatisiertes CI-Audit ersetzt. Sie erkennt keinen Kontrast auf einem Bild oder einem komplexen Verlauf.

Browser-DevTools (Chrome/Firefox)

Der integrierte Farbwähler zeigt das Kontrastverhältnis direkt am ausgewählten Element auf der echten Seite an, mit berechneten Stilen, ganz ohne externes Werkzeug. Einschränkung: nur ein Element gleichzeitig, was bei einer ganzen Palette mühsam wird, ohne Matrixmodus und ohne Teilen per Link.

axe-core / Lighthouse CI

Ein automatisiertes Audit direkt in der CI-Pipeline erkennt systematisch Kontrastregressionen bei jedem Pull Request und deckt Barrierefreiheit über Kontrast hinaus ab. Einschränkung: Es ersetzt nicht die vorgelagerte Phase der Palettengestaltung und kann False Negatives bei Text über einem Bild liefern.

Zusammenfassung

Farbkontrast bleibt der häufigste Barrierefreiheitsfehler im Web und einer der am leichtesten zu behebenden, sobald er erkannt ist. AA (4,5:1) für normalen Text und 3:1 für großen Text und Nicht-Text-Elemente sind die zwei Schwellenwerte, die man sich vor der Freigabe einer Palette merken sollte. Der FastMinify-Kontrastprüfer liefert das Ergebnis schon beim Tippen, im Paarmodus oder im Matrixmodus für ein ganzes Design-System. Ihre Markenfarben gehen dabei nie an einen Server. Ein axe-core-Audit in der CI verhindert Regressionen, und mit dem restlichen Farbe-&-CSS-Hub lässt sich eine konsistente Palette von Anfang bis Ende aufbauen.

Jetzt Ihren Kontrast prüfen

WCAG-Kontrastprüfer Farbkonverter Farbnuancen-Generator Farbe-&-CSS-Hub

AA (4,5:1) bei normalem Text anstreben, 3:1 bei großem Text und bei Nicht-Text-Elementen wie Rändern, Fokus und Icons

Alle Zustände einer interaktiven Komponente testen (normal, hover, focus, disabled), auch den Standardzustand

Den Matrixmodus nutzen, um ein ganzes Design-System zu validieren, statt Paar für Paar

axe-core oder Lighthouse CI in die Pipeline einbauen, um Kontrastregressionen nach dem Release zu verhindern

Rechtlich zählt heute das WCAG-2.2-Verhältnis: APCA als Ausblick auf die Zukunft behandeln, nicht als Konformitätsreferenz

Teilen Sie diesen Artikel