Farbkontrast nach WCAG richtig prüfen: Schwellenwerte, Tools und Audit-Vorgehen

Von Manuel Hack, ihp media · Aktualisiert am 14. Juni 2026

Kontrast lässt sich messen. Das unterscheidet ihn von vielen anderen Gestaltungsfragen, bei denen Geschmack und Kontext regieren. Wer weiß, wie das Kontrastverhältnis berechnet wird und welche Schwellenwerte die WCAG 2.2 für welche Inhalte vorschreibt, kann eine Website objektiv auditieren statt nach Gefühl zu urteilen. Dieser Artikel legt die technische Grundlage, erklärt alle drei relevanten Kontrast-Kriterien und zeigt ein konkretes Audit-Vorgehen, das in der Praxis funktioniert.

Warum Kontrast eine Zahl ist, kein Gefühl

Der subjektive Eindruck täuscht zuverlässig. Kräftige Komplementärfarben wie Rot auf Grün wirken auf viele sehr kontrastreich. Das tatsächliche Verhältnis kann trotzdem bei 1,3:1 liegen, weil beide Farben nahezu gleich hell sind. Für Menschen mit Rot-Grün-Sehschwäche, von der in Deutschland rund acht Prozent aller Männer betroffen sind, verschwimmt die Kombination komplett.

Umgekehrt gilt: Ein technisch ausreichendes Verhältnis von 4,6:1 kann sich für jemanden mit gutem Sehvermögen selbstverständlich anfühlen und trotzdem das einzige sein, was ältere Nutzer, Menschen nach einer Augenoperation oder wer das Smartphone im Sonnenlicht bedient, überhaupt noch lesen können.

Wie die relative Luminanz berechnet wird

Die WCAG berechnen Kontrast aus der relativen Luminanz zweier Farben, wie in WCAG 2.2 §1.4 (Definition relative luminance) festgelegt. Die Formel in drei Schritten:

Schritt 1: sRGB-Werte normalisieren. Die drei Farbkanäle R, G, B (jeweils 0–255) werden auf den Bereich 0–1 gebracht, indem man durch 255 teilt.

Schritt 2: Gammakorrektur aufheben. sRGB ist nicht linear. Für jeden Kanal gilt: Werte unter 0,04045 werden durch 12,92 geteilt. Werte darüber: ((Wert + 0,055) / 1,055)^2,4. Das Ergebnis sind die linearisierten Kanalwerte.

Schritt 3: Luminanz gewichten. Die menschliche Wahrnehmung gewichtet die drei Kanäle unterschiedlich stark. Grün trägt am meisten zur wahrgenommenen Helligkeit bei, Blau am wenigsten:

L = 0,2126 × R_lin + 0,7152 × G_lin + 0,0722 × B_lin

Das Kontrastverhältnis ergibt sich dann aus den Luminanzwerten L1 (hellere Farbe) und L2 (dunklere):

Kontrast = (L1 + 0,05) / (L2 + 0,05)

Der Offset von 0,05 verhindert eine Division durch null bei absolutem Schwarz und bildet das Streulicht in realen Anzeigemedien nach.

Das Ergebnis ist der Grund, warum Tools wie der WebAIM Contrast Checker bei derselben Eingabe immer dieselbe Zahl liefern. Die Formel ist in WCAG normiert, kein Tool entscheidet nach eigenem Maßstab.

Die WCAG-Schwellenwerte im Überblick

Die folgende Skala ordnet einen gemessenen Kontrastwert sofort ein. Ziehen Sie den Regler auf Ihren Wert, etwa aus dem WebAIM Contrast Checker.

Kriterium 1.4.3, 1.4.6 und 1.4.11 im Detail

1.4.3 Kontrast (Minimum), Stufe AA

Das Kriterium gilt für alle Texte und Bilder, die Text zeigen, zum Beispiel ein Textelement in einer Infografik. Es gilt nicht für inaktive Steuerelemente wie einen ausgegrauten Button, für rein dekorativen Text wie Wasserzeichen und für typografische Logos, also den Markennamen als gestalteten Schriftzug. Diese Ausnahme wird regelmäßig auf normalen Fließtext ausgeweitet, für den sie nicht gilt.

Der vollständige Wortlaut und die offiziellen Erläuterungen stehen im WCAG 2.2 Understanding-Dokument zu 1.4.3.

1.4.6 Kontrast (Erhöht), Stufe AAA

Kriterium 1.4.6 ist die verschärfte Variante: normaler Text benötigt 7:1, großer Text 4,5:1. AAA ist keine Pflicht im BFSG-Kontext, aber für Anwendungen, die von Menschen mit stärkeren Seheinschränkungen genutzt werden, ist dieser Wert der realistischere Maßstab. Wer sicher gehen will, prüft beide Schwellen.

1.4.11 Nicht-Text-Kontrast, Stufe AA

Dieses Kriterium betrifft Komponenten der Benutzeroberfläche und grafische Objekte. Konkret gemeint sind die visuellen Merkmale, die notwendig sind, um ein Steuerelement zu identifizieren und seinen Zustand zu verstehen: sieht man, dass ein Eingabefeld ein Feld ist? Erkennt man, ob ein Toggle aktiv oder inaktiv ist? Das Ausführliche dazu im Understanding-Dokument zu 1.4.11.

Wichtig: Icons mit Textbeschriftung müssen das Kriterium nicht erfüllen, weil die Information auch ohne das Icon lesbar bleibt. Icons ohne Beschriftung, die allein eine Funktion kommunizieren, müssen es hingegen erfüllen.

Was zählt als große Schrift?

Die WCAG definieren große Schrift in Punkt (pt), einer typografischen Maßeinheit, nicht in Pixel. Die Grenze liegt bei 18 pt normalgewichtig oder 14 pt fett. In CSS-Pixel umgerechnet, wobei 1 pt = 1,333 CSS-Pixel gilt:

• 18 pt = ca. 24 CSS-Pixel (normalgewichtig)
• 14 pt = ca. 18,67 CSS-Pixel (fett, also font-weight: 700 oder höher)

Diese Umrechnung ist eine Näherung. Das tatsächliche Verhältnis hängt von der Pixeldichte des Ausgabegeräts und den Browser-Einstellungen ab. In der Praxis ist 24 px für normalen Text und 18 px für fetten Text die gebräuchliche Daumenregel.

Ein häufiger Fehler: Text, der auf einem Desktop-Monitor groß genug wirkt, um von der 3:1-Schwelle zu profitieren, wird auf Mobilgeräten oder bei aktivierter Textvergrößerung kleiner, und damit gilt wieder 4,5:1. Wer responsive Layouts prüft, muss bei jedem Breakpoint nachkontrollieren.

Tools, die verlässlich messen

Alle seriösen Prüfwerkzeuge rechnen mit derselben WCAG-Formel, unterscheiden sich aber in Bedienung und Einsatzbereich.

WebAIM Contrast Checker

Der WebAIM Contrast Checker ist der meistgenutzte Online-Prüfer. Hex-Code oder RGB-Wert eingeben, Ergebnis sofort für AA und AAA, jeweils für Normal- und Großtext. Keine Installation, kein Login. Zwei Einschränkungen: Man muss die Farbwerte kennen, und Verlaufshintergründe lassen sich nicht direkt prüfen.

TPGi Colour Contrast Analyser

Der Colour Contrast Analyser der TPGi (früher Paciello Group) ist eine Desktop-Anwendung für Windows und macOS. Sein Vorteil ist die Bildschirm-Pipette: Sie misst Farben direkt vom Monitor, unabhängig davon, ob die Quelle eine Website, ein PDF oder eine native App ist. Damit prüft man das, was eine Nutzerin tatsächlich sieht, nicht den Wert im Quellcode. Kostenlos.

axe DevTools

Die Browser-Erweiterung axe DevTools scannt die gesamte Seite in einem Durchgang und meldet jeden Kontrast-Verstoß mit CSS-Selektor, betroffenen Farbwerten und dem zugehörigen WCAG-Kriterium. Das macht die Übergabe an die Entwicklung direkt. Die Gratis-Erweiterung reicht für den normalen Einsatz; eine Pro-Version mit erweiterten Manualtests gibt es kostenpflichtig.

WAVE

WAVE von WebAIM läuft als Browser-Erweiterung oder direkt online. Es markiert Kontrast-Fehler visuell direkt auf der Seite, was für erste Sichtprüfungen praktisch ist. Die Darstellung ist weniger codier-freundlich als axe, dafür sehr intuitiv für Menschen ohne Entwicklungshintergrund.

Grenzen aller automatisierten Tools

Keines dieser Werkzeuge prüft automatisch Verlaufshintergründe, Text über Fotos, übereinanderliegende transparente Ebenen oder Hover- und Fokus-Zustände. Für diese Fälle ist immer die Bildschirm-Pipette des Colour Contrast Analyser die zuverlässigere Methode, weil sie misst, was auf dem Bildschirm gerendert wird.

Schritt-für-Schritt Audit

Schritt 1: Automatisierten Scan durchführen

Axe DevTools oder WAVE installieren, die wichtigsten Seitentypen aufrufen (Startseite, Inhaltsseite, Kontaktseite, Checkout oder Formularseite) und den Scan starten. Die Ergebnisse nach Schweregrad filtern, alle als „critical“ oder „serious“ gemeldeten Kontrast-Verstöße in einer Liste festhalten. Jeder Eintrag sollte den CSS-Selektor, die gemessenen Farbwerte und das Kontrastverhältnis enthalten.

Schritt 2: Kritische Elemente manuell nachmessen

Buttons, Links, Formularbeschriftungen, Fehlermeldungen und alleinstehende Icons werden mit dem TPGi Colour Contrast Analyser von Hand gemessen. Besondere Aufmerksamkeit verdienen Hover- und Fokus-Zustände: Ein Button kann im Ruhezustand 5:1 messen und beim Überfahren mit der Maus auf 2:1 fallen, weil das Theme einen helleren Hintergrund setzt. Automatische Tools erfassen diesen Zustand nicht.

Schritt 3: Responsive Breakpoints prüfen

Den Browser auf typische Mobilgrößen (360–430 px Breite) einstellen oder das DevTools-Gerätemenü nutzen. Texte, die auf dem Desktop groß genug sind für 3:1, können in der mobilen Ansicht kleiner werden und brauchen dann 4,5:1. Farbwechsel durch Media-Queries oder Dark-Mode-Varianten separat messen.

Schritt 4: Nicht-Text-Kontrast prüfen (1.4.11)

Eingabefelder, Checkboxen, Toggle-Schalter und alleinstehende Icons manuell messen. Dabei den Rahmen oder die Kontur gegen den Hintergrund messen, nicht gegen die Füllfarbe. Ein Eingabefeld mit hellem Grau-Rahmen auf weißem Hintergrund ist das klassische Versäumnis hier.

Schritt 5: Befunde dokumentieren

Jeder Befund wird festgehalten mit: Screenshot, gemessene Farbwerte (Hex), Kontrastverhältnis, Schwellenwert (AA oder AAA), betroffenes Element und WCAG-Kriterium. Diese Dokumentation ist die Grundlage für die Barrierefreiheitsprüfung und, wenn nötig, für eine Barrierefreiheitserklärung.

Praxisbeispiel mit konkreten Farbwerten

In einem Projekt sahen wir folgende Konstellation: Ein Mittelstandskunde hatte eine neue Website mit einem hellen, modernen Design. Die primäre Textfarbe war #767676 (mittleres Grau) auf weißem Hintergrund #FFFFFF. Das Kontrastverhältnis dieser Kombination beträgt genau 4,54:1, also knapp über dem AA-Schwellenwert von 4,5:1, formal bestanden, aber kaum Reserve.

Ergebnis im axe-Scan: kein Fehler. Die Farbe liegt haarscharf über der Schwelle. Das Problem: Wird die Schrift auf mobilen Geräten durch Skalierung oder abweichende Rendering-Einstellungen minimal kleiner dargestellt, können Werkzeuge je nach Viewport zu unterschiedlichen Einschätzungen kommen. Zudem hat der Kunde eine AAA-Anforderung angestrebt, für die 7:1 nötig wäre.

Die Korrektur war minimal: #767676 wurde durch #595959 ersetzt. Das Kontrastverhältnis stieg auf 7,0:1, was nebenbei auch die AAA-Schwelle von 7:1 trifft. Visuell kein Unterschied. Der neue Farbwert war dunkler als der alte, blieb aber im Grau-Bereich und passte zum Gesamtdesign.

Ein zweites Muster, das wir häufiger sehen: Call-to-Action-Buttons in einem mittelgesättigten Orange wie #FF8C00 auf weißem Hintergrund. Das Verhältnis liegt bei 2,33:1, deutlich unter 3:1 für große Schrift und weit entfernt von 4,5:1 für normalen Text. Ein dunkleres Orange #C96B00 bringt 3,76:1, das erfüllt AA für große Schrift (Buttons ab 18 pt oder 14 pt fett), reicht aber nicht für normalen Fließtext (Schwelle 4,5:1). Es ist immer noch deutlich als Signalfarbe erkennbar.

Typische Fallstricke im Alltag

Placeholder-Text in Formularfeldern

Placeholder-Text wird in vielen Designs bewusst heller gehalten, damit er sich vom eingegebenen Text unterscheidet. Die WCAG sehen für Platzhalter keine eigene Ausnahme im Kriterium 1.4.3 vor. Wer auf der sicheren Seite sein will, prüft Placeholder-Text wie normalen Text und hält 4,5:1 ein. Die häufig genutzte Browser-Standardfarbe liegt bei rund #767676 auf Weiß, also exakt an der Grenze.

Text auf Fotos und Verlaufshintergründen

Manche Themes platzieren Texte über Hero-Fotos oder Verlaufshintergründen. Das Kontrastverhältnis schwankt dann je nach Bildbereich. Die korrekte Prüfung misst an der ungünstigsten Stelle, also dort, wo Hintergrund und Text in der Helligkeit am nächsten liegen. Der TPGi Analyser mit Bildschirm-Pipette ist hier das einzige zuverlässige Tool.

Sekundäre Informationen werden unterschätzt

Zeitstempel, Kategoriebezeichnungen, Fußnoten und Hilfetexte werden oft mit reduzierter Deckkraft oder sehr hellen Grautönen gesetzt. Sie müssen dieselben Kontrastwerte einhalten wie der Haupttext, sofern sie inhaltlich von Bedeutung sind. Rein dekorative Texte ohne Informationswert sind ausgenommen.

Hover- und Fokus-Zustände

Kein automatisches Tool prüft, was passiert, wenn sich der Mauszeiger über einem Element befindet oder es per Tab-Taste angesteuert wird. Manche Themes setzen für den Hover-Zustand eine helle Hintergrundfarbe, die den Kontrast des Textes darunter zerstört. Manuelle Prüfung ist hier Pflicht.

Deaktivierte Elemente, Ausnahme richtig verstehen

Inaktive Bedienelemente sind von den Kontrast-Anforderungen ausgenommen. Das gilt aber nur für Elemente, die technisch nicht aktiviert werden können, nicht für solche, die lediglich optisch dezent gestaltet sind, aber funktionieren. Ein „Weiter“-Button, der vor dem Ausfüllen aller Felder optisch schwach ist, aber trotzdem klickbar ist, fällt nicht unter die Ausnahme.

Markenvorgaben überschreiben die WCAG nicht

CI-Farben befreien nicht von den Anforderungen. Die einzige Ausnahme ist das typografische Logo. Für alle anderen Textelemente gilt der Mindestkontrast. In der Praxis lässt sich nahezu jede Markenfarbe durch eine geringfügige Anpassung der Helligkeit konform gestalten, ohne dass der Wiedererkennungswert verloren geht. Das barrierefreie Webdesign-Artikel zeigt, wie das in der Praxis funktioniert.

Sofort-Checkliste: Kontrast-Audit

• Automatischen Scan mit axe oder WAVE auf allen wichtigen Seitentypen durchgeführt?
• Alle als „critical“ gemeldeten Kontrast-Verstöße mit Farbwerten und Selektor dokumentiert?
• Buttons, Links und Formularbeschriftungen manuell mit TPGi Analyser nachgemessen?
• Hover- und Fokus-Zustände aller interaktiven Elemente geprüft?
• Normaler Text überall mindestens 4,5:1, großer Text mindestens 3:1?
• Bedienelemente und Icons ohne Textlabel mindestens 3:1 (Kriterium 1.4.11)?
• Placeholder-Text in Formularfeldern auf mindestens 4,5:1 geprüft?
• Text über Fotos und Verlaufshintergründen an der ungünstigsten Stelle gemessen?
• Mobile Ansicht geprüft: Sind Texte dort noch groß genug für die 3:1-Schwelle?
• Befunde mit Screenshot, Farbwert und WCAG-Kriterium dokumentiert?

Häufige Fragen

Was bedeutet das Kontrastverhältnis 4,5:1 konkret?

Die hellere der beiden Farben ist 4,5-mal heller als die dunklere, gemessen als relative Luminanz nach WCAG. Bei Schwarz (#000000) auf Weiß (#FFFFFF) beträgt das Verhältnis 21:1, das Maximum. Das AA-Minimum von 4,5:1 für normalen Text liegt bei ungefähr mittlerer Helligkeit beider Farben, also einem spürbaren, aber nicht extremen Unterschied.

Gilt das Kriterium 1.4.11 für alle Grafiken auf der Seite?

Nein. Das Kriterium gilt für Bedienelemente der Benutzeroberfläche und für grafische Objekte, die Informationen vermitteln, die für den Inhalt erforderlich sind. Rein dekorative Grafiken, die keine Information enthalten, sind ausgenommen. Diagramme und Infografiken mit inhaltlicher Bedeutung müssen das Kriterium erfüllen, sofern die Farbe das einzige Unterscheidungsmerkmal ist.

Welches Tool empfehlen Sie für einen schnellen ersten Check?

Für eine erste Einschätzung ohne Installation: WebAIM Contrast Checker mit den Hauptfarben der Website. Für einen ganzseitigen Befund als Entwickler: axe DevTools als Browser-Erweiterung, sie liefert alle Treffer mit Selektoren auf einmal. Für alles, was nicht im CSS als fester Wert steht: TPGi Colour Contrast Analyser mit der Pipettenfunktion.

Muss ich auch Hover-Zustände prüfen?

Ja. Die WCAG verlangen, dass interaktive Elemente in all ihren Zuständen die Kontrastanforderungen erfüllen, also auch im Hover- und Fokus-Zustand. Kein automatisches Tool prüft das. Manuelle Prüfung mit der Bildschirm-Pipette ist der einzige zuverlässige Weg.

Wie genau ist die Umrechnung von pt in px?

1 pt = 1,333 CSS-Pixel bei 96 dpi (Standarddichte). Auf Retina-Displays und bei geänderten Browsereinstellungen verschiebt sich das Verhältnis. Die Schwelle ist eine Annäherung, deshalb ist es sicherer, für normalen Text immer 4,5:1 anzustreben, außer man ist sicher, dass der betreffende Text in allen relevanten Ansichten groß genug bleibt.

Wie hängt dieser Artikel mit der 30-Minuten-Selbstprüfung zusammen?

Die 7-Prüfungen-Anleitung erklärt den Kontrast-Check als einen von sieben Selbsttests. Dieser Artikel geht tiefer: Er legt die Formel offen, unterscheidet die drei WCAG-Kriterien und zeigt das vollständige Audit-Vorgehen inklusive manueller Prüfschritte. Wer den Selbsttest gemacht hat und Kontrast-Verstöße gefunden hat, findet hier, wie er sie sauber dokumentiert und behebt.

Ändert sich das mit WCAG 3.0 und APCA?

Mit WCAG 3.0 wird ein neues Berechnungsmodell namens APCA (Advanced Perceptual Contrast Algorithm) diskutiert. APCA berechnet Kontrast als gerichteten Helligkeitsunterschied statt als symmetrisches Verhältnis und berücksichtigt dabei Schriftgröße und -gewicht stärker. WCAG 3.0 ist mit Stand Juni 2026 noch kein verabschiedeter Standard. Für alle verbindlichen Anforderungen gilt weiterhin WCAG 2.1 beziehungsweise 2.2 auf Stufe AA. Wer APCA im Blick behalten will: Die Arbeitsgruppe dokumentiert den Stand auf der WCAG 3.0-Seite des W3C.