So prüfen Sie Farbkontraste für WCAG

Um Farbkontraste für WCAG zu prüfen, vergleichen Sie die relative Leuchtdichte (relative Luminanz) Ihres Vordergrundtextes mit der seines Hintergrunds und stellen anschließend sicher, dass das resultierende Verhältnis den Schwellenwert für den jeweiligen Elementtyp erreicht: Auf Level AA sind das 4,5:1 für normalen Text, 3:1 für großen Text und 3:1 für Nicht-Text-UI.

Die meisten von uns lernen das auf die harte Tour – man veröffentlicht ein hellgraues Label, das auf dem eigenen Bildschirm gut aussah, und zwei Sprints später fällt es beim Audit durch. Berechnen muss man das nicht von Hand: Ein Checker erledigt das in Sekunden anhand zweier Hex-Werte. Dieser Leitfaden liefert Ihnen die exakten Schwellenwerte, die schnellsten Wege zur Messung eines Kontrastverhältnisses, die Fehler, über die die meisten Teams stolpern, und die Regeln, die über Fließtext hinaus auch UI-Komponenten, Fokusindikatoren und farbcodierte Bedeutung betreffen.

Welches Kontrastverhältnis verlangt WCAG?

Das Kontrastverhältnis misst den Leuchtdichteunterschied zwischen zwei Farben. Der Mindestwert liegt bei 1:1 – das erhält man, wenn Vordergrund und Hintergrund dieselbe Farbe haben – und der Höchstwert bei 21:1, Schwarz auf Weiß. WCAG berechnet es als (L1 + 0,05) / (L2 + 0,05), wobei L1 und L2 die relative Leuchtdichte der helleren bzw. dunkleren Farbe sind. Dies sind die Schwellenwerte, die jeder Checker durchsetzt:

Auf Level AA bedeutet das 4,5:1 für normalen Text und 3:1 für großen Text; Level AAA hebt dasselbe Paar auf 7:1 und 4,5:1 an. Was als „groß“ gilt, ist eine Frage von Größe und Schriftschnitt: 18 pt (etwa 24 px) und mehr, oder 14 pt (etwa 18,66 px) und mehr, wenn der Text fett ist. Der WebAIM Contrast Checker prüft genau gegen diese Schwellenwerte. Eine einzige Entscheidungsregel deckt die meisten Fälle ab: Ist der Text groß? → 3:1; andernfalls → 4,5:1.

Ein Mythos, mit dem aufgeräumt werden sollte: WCAG 2.2, veröffentlicht im Oktober 2023, ergänzte Vorgaben zur Fokusdarstellung, ließ die Kontrastminima aber unangetastet. Spätere Versionen fügen nur Erfolgskriterien hinzu, statt bestehende neu zu formulieren – mit 4.1.1 Parsing als einziger Ausnahme. Daher gelten 4,5:1 / 3:1 / 7:1 unverändert über 2.0, 2.1 und 2.2 hinweg. Zu geringer Kontrast bleibt der häufigste Barrierefreiheitsmangel im Web. Der WebAIM-Million-Report 2026 fand Text mit unzureichendem Kontrast auf 83,9 % der Startseiten der Top-1-Million-Websites.

Wie prüft man Farbkontraste?

Der schnellste Workflow lautet: die beiden gerenderten Hex-Werte ermitteln, in einen Checker einfügen, das Pass/Fail-Ergebnis ablesen. Verwenden Sie dabei die gerenderte Farbe, nicht den Wert aus Ihrer Design-Datei: Overlays, Verläufe und Transparenz verändern das, was Nutzende tatsächlich sehen.

• WebAIM Contrast Checker: Vordergrund- und Hintergrund-Hex einfügen. Sie erhalten das Verhältnis plus fünf Bewertungen, da normaler und großer Text jeweils gegen AA und AAA geprüft werden und Nicht-Text-Elemente eine eigene AA-Zeile bekommen. Verfehlt das Paar den Wert, können Sie mit den Lightness-Reglern eine der beiden Farben so lange nachjustieren, bis sie besteht – wie WebAIMs Anleitung zum Tool zeigt.
• TPGi Colour Contrast Analyser: eine Desktop-App für Windows und macOS. Wählen Sie beide Farben per Pipette direkt vom Bildschirm, geben Sie Werte in Hex, RGB, HSV oder HSL ein, setzen Sie einen Alphawert für den Vordergrund und ziehen Sie die Regler, bis ein durchgefallenes Paar besteht. Zusätzlich lassen sich Ihre Farben in acht Simulationen von Farbfehlsichtigkeiten vorschauen.
• Chrome DevTools: Element inspizieren, den Color Picker über das Farbfeld neben der color-Deklaration öffnen und den Abschnitt Contrast ratio aufklappen. Dort wird angezeigt, ob das Paar AA und AAA erfüllt; es gibt eine Schaltfläche Use suggested color, die einen bestandenen Wert übernimmt, und die AA- und AAA-Grenzwerte werden als Linien in der Farbtonvorschau eingezeichnet, sodass Sie den Picker manuell darunter ziehen können.
• Firefox: DevTools öffnen → Panel Barrierefreiheit → Knoten auswählen → Kontrast und Pass/Fail ablesen.

Für Audits ganzer Seiten nutzen Sie WAVE, axe DevTools oder Lighthouse. WAVE liest Text- und Hintergrundfarben aus Ihren Styles aus und erkennt den größten Teil des Fließtexts, der unter der AA-Grenze von 4,5:1 liegt, wobei für großen Text der niedrigere Schwellenwert von 3:1 angewandt wird. Nicht beurteilen kann das Tool Text über Bildern, Alpha-Komposition sowie Hover- und Fokuszustände – prüfen Sie wichtige Komponenten daher manuell.

Häufige Kontrastfehler und ihre Behebung

Die meisten Fehler gehen auf eine Handvoll Wiederholungstäter mit schnellen, überprüfbaren Lösungen zurück.

Hellgrauer Text auf Weiß. #767676 auf Weiß ist das hellste Grau, das AA noch erfüllt – mit 4,5:1 –, während #999 nur 2,85:1 erreicht und durchfällt. Dunkeln Sie den Fließtext auf #595959 ab; dieser Wert trifft exakt 7:1 und erfüllt sowohl AA als auch AAA.

/* FAIL: ~2.85:1 */  color: #999999; background: #fff;
/* PASS: 7:1 */      color: #595959; background: #fff;

Platzhaltertext. Platzhalter mit 40–50 % Deckkraft zu versehen ist die übliche Ursache für einen Verstoß gegen 1.4.3, weil der Hintergrund durchschlägt und das Verhältnis unter 4,5:1 drückt. Geben Sie ihnen stattdessen einen echten Hex-Wert von #767676 oder dunkler. Und verwenden Sie ein dauerhaft sichtbares <label> für alles, was Nutzende lesen müssen, da Platzhalter bei der Eingabe verschwinden.

Links nur durch Farbe gekennzeichnet. Ergänzen Sie text-decoration: underline, damit sich der Link nicht allein über den Farbton abhebt. Entfernen Sie die Unterstreichung, kommt eine zusätzliche Anforderung hinzu: Der Linktext benötigt dann 3:1 gegenüber dem umgebenden Fließtext, zusätzlich zu den 4,5:1, die beide Farben gegenüber dem Hintergrund einhalten müssen.

Text über Bildern. Die Leuchtdichte variiert über ein Foto hinweg, sodass derselbe Text in einem Bereich besteht und in einem anderen durchfällt. Fügen Sie einen halbtransparenten Scrim hinzu:

.hero {
  background:
    linear-gradient(rgba(0,0,0,.6), rgba(0,0,0,.6)),
    url("hero.jpg");
}
.hero-text { color: #fff; } /* now has guaranteed contrast */

Über Text hinaus: UI-Komponenten, Fokus und Verwendung von Farbe

Kontrastregeln reichen über Absätze hinaus. Erfolgskriterium 1.4.11 legt einen Mindestwert von 3:1 für Bedienelemente und für diejenigen Teile einer Grafik fest, die zum Verständnis des Inhalts erforderlich sind – gemessen gegenüber der jeweils angrenzenden Farbe. Eingabefeld-Rahmen, Button-Umrandungen, bedeutungstragende Icons und Diagrammreihen fallen alle darunter. Auch Zustände zählen, mit einer Einschränkung: Der Standardzustand benötigt 3:1, und kein Zustand darf die Komponente darunter drücken; ein zusätzlich aufgesetzter Hover-Effekt unterliegt jedoch selbst nicht den 3:1, solange er den bereits vorhandenen Kontrast des Bedienelements nicht aufhebt.

Bei Fokusindikatoren werden die Kriteriennummern gern durcheinandergebracht, deshalb hier die genaue Zuordnung. Die Sichtbarkeit des Fokus regelt 2.4.7 Focus Visible. Der 3:1-Kontrast für den Indikator stammt aus 1.4.11 Non-text Contrast, nicht aus 2.4.11 – das ist Focus Not Obscured (Minimum) und betrifft Overlays, die ein fokussiertes Element verdecken. Das auf AAA-Level angesiedelte 2.4.13 Focus Appearance ergänzt darüber hinaus Mindestgrößen und Kontrastanforderungen beim Zustandswechsel.

Schließlich bedeutet WCAG 1.4.1 Use of Color (Level A), dass Farbe allein niemals Bedeutung transportieren darf: Kombinieren Sie einen roten/grünen Status mit einer Textbeschriftung oder einem Icon und versehen Sie Links mit einer Unterstreichung. Eine Ausnahme sollte man sich merken: Inaktive (deaktivierte) Komponenten sind von den Nicht-Text- und Kontrastminima ausgenommen – sie dennoch lesbar zu halten, ist aber die bessere UX, als sie bis zur Unsichtbarkeit auszugrauen.

Verankern Sie Kontrast in Ihrem Workflow

Fangen Sie Kontrastprobleme ab, bevor sie ausgeliefert werden. Prüfen Sie bereits während des Designs mit einem Plugin wie Stark in Figma und kodieren Sie die Ergebnisse anschließend in einer Token-Ebene, die das Verhältnis jeder Farbe dokumentiert:

:root {
  --text-primary:   #171717; /* 18.8:1 — headings, body */
  --text-secondary: #595959; /* 7:1  — secondary text */
  --border-input:   #767676; /* 4.5:1 — meets 1.4.11 */
  --border-subtle:  #d4d4d4; /* 1.6:1 — decorative only */
}

Fließtext sollte deutlich über dem Minimum liegen (10:1 und mehr ist komfortabel), während sekundärer und großer Text bei 4,5:1 und Rahmen bei 3:1 bleiben können. Testen Sie auf Farbfehlsichtigkeit über Chrome DevTools → Rendering → Emulate vision deficiencies, um sicherzustellen, dass die Bedeutung auch ohne Farbe erhalten bleibt. Automatisieren Sie anschließend: Lassen Sie axe oder Lighthouse in der CI laufen, damit eine Kontrastregression den Build zum Scheitern bringt, statt bei den Nutzenden zu landen. Und geben Sie dem Dark Mode einen eigenen Durchgang: Das Invertieren der Leuchtdichte zerstört Verhältnisse, die im Light Mode bestanden haben – berechnen Sie also jedes Token pro Theme neu.

Kontrast gehört zu den am günstigsten zu behebenden und am leichtesten zu vermeidenden Barrierefreiheitsproblemen. Wählen Sie einen Checker, legen Sie Ihre Schwellenwerte als Tokens fest, binden Sie einen automatisierten Scan in die CI ein – und die oben genannten Fehler gehen nicht mehr in Produktion. Beginnen Sie noch heute damit, Ihren aktuellen Fließtext und Ihre Fokus-Styles gegen die Grenzwerte 4,5:1 und 3:1 zu prüfen.

FAQs

Misst der WCAG-Kontrast Farbton und Sättigung oder nur die Helligkeit?

Das Kontrastverhältnis misst ausschließlich die relative Leuchtdichte, also die wahrgenommene Helligkeit jeder Farbe, nicht Farbton oder Sättigung. Deshalb können zwei Farben, die unterschiedlich aussehen – etwa roter Text auf grünem Hintergrund –, dennoch durchfallen, wenn ihre Leuchtdichte nahe beieinanderliegt. Das Verhältnis wird als (L1 + 0,05) / (L2 + 0,05) aus dem helleren und dem dunkleren Leuchtdichtewert berechnet. Bedeutung, die allein über den Farbton vermittelt wird, ist daher separat durch WCAG 1.4.1 Use of Color geregelt.

Was ist der Unterschied zwischen WCAG 1.4.11 Non-text Contrast und 2.4.11 Focus Not Obscured?

WCAG 1.4.11 Non-text Contrast (Level AA) verlangt ein Kontrastverhältnis von 3:1 für UI-Komponenten und bedeutungstragende Grafiken – einschließlich des Fokusindikators – gegenüber angrenzenden Farben. WCAG 2.4.11 Focus Not Obscured (Minimum, Level AA), neu in WCAG 2.2, hat nichts mit Kontrast zu tun: Es verlangt, dass ein fokussiertes Element nicht vollständig durch autorenerstellte Inhalte wie Sticky-Header oder Overlays verdeckt wird. Kontrast ist 1.4.11; Sichtbarkeit trotz Verdeckung ist 2.4.11.

Warum besteht derselbe Text den Kontrasttest in meiner Design-Datei, fällt im Browser aber durch?

Plugins in Design-Dateien prüfen die flachen Farbwerte, die Sie zuweisen, während Browser das gerenderte Ergebnis zusammensetzen. Deckkraft, halbtransparente Overlays, Verläufe, Hintergrundbilder und Blend-Modi verändern alle die tatsächliche Leuchtdichte, die Nutzende sehen. Ein Platzhalter mit 50 Prozent Deckkraft oder Text über einem Foto kann im Mockup bestehen und nach dem Rendern durchfallen. Nehmen Sie den gerenderten Hex-Wert daher immer aus den DevTools oder mit einem Bildschirm-Pipetten-Tool ab, statt der Quellfarbe zu vertrauen.

Müssen deaktivierte Buttons und inaktive Bedienelemente die WCAG-Kontrastminima erfüllen?

Nein. WCAG 1.4.3 Contrast (Minimum) nimmt inaktive Benutzeroberflächenkomponenten ausdrücklich aus, und deaktivierte Elemente sind auch von der Nicht-Text-Kontrastanforderung 1.4.11 ausgenommen. Das bedeutet, dass ein ausgegrauter, deaktivierter Button ein automatisiertes Kontrast-Audit nicht zum Scheitern bringt. Deaktivierte Bedienelemente lesbar zu halten, ist dennoch die bessere Usability, da vollständig unsichtbare Elemente Nutzende verwirren – eine WCAG-Konformitätsanforderung für diesen Zustand ist es aber nicht.