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:

accessibility

wcag

color-contrast

CSS

Anleitung

Kontrast: der häufigste Barrierefreiheitsfehler im Web

Jedes Jahr stuft der WebAIM-Million-Audit (eine Analyse der meistbesuchten Startseiten im Web) unzureichenden Textkontrast als häufigsten erkannten WCAG-Verstoß ein — noch vor fehlendem Alt-Text oder nicht beschrifteten Links. Es ist zudem eines der wenigen Barrierefreiheitskriterien, das sich in Sekunden prüfen lässt, ganz ohne Screenreader oder vollständiges Audit. Der FastMinify-Kontrastprüfer berechnet das WCAG-2.2-Verhältnis zwischen zwei CSS-Farben (HEX, RGB, HSL, OKLCH, color() oder benannte Farben) und zeigt sofort AA/AAA-Ergebnisse für normalen Text, großen Text und Nicht-Text-Elemente — ohne dass etwas an einen Server gesendet wird. Er geht über ein einzelnes Farbpaar hinaus: Ein Matrixmodus erlaubt es, eine ganze Vordergrundpalette gegen eine ganze Hintergrundpalette in einem Durchgang zu prüfen. Der gesamte Cluster liegt im Farbe-&-CSS-Hub.

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

Matrixmodus mit bis zu 16 Farben pro Achse — ein ganzes Design-System-Palette in einem Durchgang prüfen

Opazitäts-Regler — halbtransparenten Text gegen seinen tatsächlichen Hintergrund prüfen

Experimentelles APCA-Overlay (WCAG-3-Kandidat) zusätzlich zum klassischen WCAG-2.2-Verhältnis

Teilbare URL — den exakten Check an ein Designteam senden oder in einen PR einfügen

100 % im Browser — keine Markenfarbe verlässt jemals den 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 es eine der häufigsten Design-Entscheidungen 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)

Sehbehinderte Nutzer, Personen in hellen Umgebungen (draußen, schlecht kalibrierte Bildschirme) und farbenblinde Nutzer verlieren einen Teil des Inhalts — und ein Lighthouse/axe-Audit schlägt in der CI fehl, wenn 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 "disabled"-Zustand, der visuell wie ein schlecht kontrastierter aktiver Zustand 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 Call-to-Action senkt die Klickrate — über die Barrierefreiheit hinaus ist das auch ein Konversionsproblem.

Text auf einem Bild ohne Abdunkelung

Eine weiße Überschrift funktioniert über dem dunklen Teil des Himmels eines Hero-Fotos, wird aber unlesbar über dem hellen Teil einer Wolke — der Kontrast schwankt je nach Position im Bild.

Kein dunkler Verlauf oder Overlay (Scrim) 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 einen halbtransparenten Verlauf (Schwarz bei 40–60 %) zwischen Bild und Text ein und prüfen Sie den Kontrast dann gegen die zusammengesetzte Verlauffarbe — nicht gegen das rohe Bild.

Sichtbarer Fokus entfernt, um "aufzuräumen"

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

`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.

AA, AAA und großer Text: Welches Verhältnis ist das Ziel?

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. AA ist die Stufe, die von nahezu allen gesetzlichen Vorgaben verlangt wird (BITV/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 (Zahlungsformulare, medizinische/rechtliche Inhalte)

Ein Verhältnis von 21:1 (reines Schwarz auf reinem Weiß) ist das theoretische Maximum — mehr ist nicht nötig

Ein auf den ersten Blick gut aussehendes Verhältnis (z. B. 4,2:1) kann AA knapp verfehlen — immer die exakte Zahl prüfen, nicht den visuellen Eindruck

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

WCAG definiert "großen Text" als Text ab mindestens 24px (18pt), oder ab mindestens 18,67px (14pt), wenn er fett ist (Schriftstärke ≥ 700). Unterhalb dieser Schwellenwerte gilt Text als normal, selbst wenn er visuell groß wirkt. FastMinify berechnet automatisch den anwendbaren 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

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

Eine 40px-H1-Überschrift profitiert vom reduzierten Schwellenwert; ein 12px-Bold-Badge 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 für UI-Komponenten (Ränder von Formularfeldern, Kontrollkästchen, bedeutungstragende Icons, Fokusindikatoren) gegenüber ihrer angrenzenden Farbe — nicht nur für Text.

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, während es bei normalem Text durchfällt

Wie das Kontrastverhältnis tatsächlich berechnet wird

Die WCAG-Formel: relative Leuchtdichte, nicht nur ein Farbtonunterschied

Das WCAG-2.x-Verhältnis vergleicht die relative Leuchtdichte beider Farben (ein Wert von 0 bis 1, abgeleitet aus linearisierten RGB-Kanälen, gewichtet mit 0,2126 für Rot, 0,7152 für Grün, 0,0722 für Blau — das menschliche Auge nimmt Grün 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, während zwei ähnlich wirkende Farbtöne sehr unterschiedliche Leuchtdichten haben können.

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 (identische Farben) und 21:1 (reines Schwarz / reines Weiß)

Grün wiegt in der Formel schwerer als Blau — ein kräftiges Blau auf Weiß scheitert 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 Polarität (heller Text auf dunklem Hintergrund vs. umgekehrt) und Schriftgröße für eine feinere Bewertung. FastMinify bietet ein optionales APCA-Overlay 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 Vordergrund/Hintergrund-Zuordnung 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 — nicht für ein aktuelles Konformitäts-Audit

color-contrast-checker-Workflow: vom Farbpaar zur kompletten Palette

Ein Farbpaar in Sekunden prüfen

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

Schritt 1 — Beide Farben einfügen

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

Schritt 2 — Textgröße und -stärke einstellen

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

Schritt 3 — Ergebnis ablesen

Exaktes Verhältnis (z. B. 4,87:1), Badge AA/AAA/AA-large/nicht bestanden für Text, und ein separates Ergebnis für Nicht-Text-Kontrast (3:1, SC 1.4.11).

Szenario — einen Button und seinen disabled-Zustand prüfen

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

Text des Buttons auf dem "normalen" Hintergrund testen — mindestens AA (4,5:1) anstreben

Dasselbe Paar im "hover"-Zustand testen — die Farbe ändert sich oft, das Verhältnis also auch

Den "disabled"-Zustand separat testen — ein niedriges Verhältnis ist dort akzeptabel, wenn der Zustand wirklich nicht interaktiv ist und entsprechend angekündigt wird (aria-disabled)

Den Button-Rand (falls sichtbar) gegen den Seitenhintergrund prüfen — das ist Nicht-Text-Kontrast, Schwellenwert 3:1

Matrixmodus: eine ganze Palette auf einmal prüfen

Statt die Kombinationen eines Design-Systems einzeln zu testen, fügen Sie Ihre Liste von Textfarben als Zeilen und Ihre Liste von Hintergrundfarben als Spalten ein (bis zu 16 Farben pro Achse). Das Ergebnis zeigt ein Raster mit dem Ergebnis jeder Kreuzung, filterbar nach Konformitätsstufe (AAA / AA / AA-large / nicht bestanden).

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 und fügen Sie ihn 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 lebt in den URL-Parametern

Praktisch, um einen in der Review gefundenen Kontrastfehler zu dokumentieren

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

Kontrast zum CI-Kriterium machen, nicht nur zum Design-Hin-und-Her

Erkennung mit axe-core oder Lighthouse CI automatisieren

Ein manueller Prüfer eignet sich hervorragend zum Entwerfen einer Palette; um Regressionen zu vermeiden, sollte Kontrast außerdem bei jedem Pull Request automatisch geprüft werden. axe-core und Lighthouse CI erkennen die meisten Kontrastfehler bei statischem Text (bei 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 color-contrast-checker

Schnelle manuelle Prüfung, keine Installation, keine gesendeten Daten. Der Matrixmodus, einzigartig unter diesen Optionen, erlaubt es, ein komplettes Design-System in einem Durchgang zu prüfen, 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, und 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 — kein externes Tool nötig. Einschränkung: nur ein Element gleichzeitig, was bei einer ganzen Palette mühsam wird, ohne Matrixmodus oder Link-Sharing.

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.

Fazit

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, 3:1 für großen Text und Nicht-Text-Elemente: drei Zahlen, die man sich merken sollte, bevor eine Palette freigegeben wird. Der FastMinify-Kontrastprüfer liefert das Ergebnis sofort, im Paarmodus oder im Matrixmodus für ein ganzes Design-System — ohne Ihre Markenfarben jemals an einen Server zu senden. Kombinieren Sie ihn mit einem axe-core-Audit in der CI, um Regressionen zu vermeiden, und mit dem restlichen Farbe-&-CSS-Hub, um eine konsistente Palette von Anfang bis Ende aufzubauen.

Jetzt Ihren Kontrast prüfen

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

Alle Zustände einer interaktiven Komponente testen — normal, hover, focus, disabled — nicht nur 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