WCAG-Kontrast prüfen: Text, Buttons und Fehlerzustände
28. September 2026 · 5 Min. Lesezeit · BarriereRadar RedaktionPrüfen Sie konkrete Farbpaare in den tatsächlich erreichbaren Zuständen.
Der Text ist dunkel, der Hintergrund hell. Das wirkt zunächst lesbar, beantwortet aber noch keine WCAG-Prüfung. Entscheidend sind das konkrete Farbpaar, die Textgröße und der dargestellte Zustand. Bei einem Button kommen Beschriftung und gegebenenfalls die zur Erkennung nötige Begrenzung als unterschiedliche Prüfgegenstände hinzu.
Die Anforderungen dem richtigen Gegenstand zuordnen
Das WCAG-2.2-Erfolgskriterium 1.4.3 auf Stufe AA verlangt für gewöhnlichen Text grundsätzlich ein Kontrastverhältnis von mindestens 4,5:1. Für großen Text gilt grundsätzlich 3:1. Die Definition großer Schrift liegt bei mindestens 18 Punkt beziehungsweise 14 Punkt in fetter Darstellung; in CSS entsprechen 18 Punkt 24 Pixeln. Die Norm nennt außerdem Ausnahmen, etwa für bestimmte dekorative Inhalte, inaktive Komponenten und Logos.
Nichttextliche Informationen werden gesondert betrachtet. Erfolgskriterium 1.4.11 behandelt unter seinen Voraussetzungen unter anderem visuelle Informationen zur Erkennung von Bedienelementen und deren Zuständen sowie bedeutungstragende grafische Objekte. Dafür ist grundsätzlich ein Verhältnis von mindestens 3:1 zu angrenzenden Farben maßgeblich. Nicht jede dekorative Linie muss deshalb automatisch denselben Test bestehen.
| Gegenstand | Typische Prüfung | Einordnung |
|---|---|---|
| Gewöhnlicher Text | Textfarbe gegen tatsächlichen Hintergrund | SC 1.4.3, grundsätzlich mindestens 4,5:1 |
| Großer Text | Textfarbe gegen Hintergrund | SC 1.4.3, grundsätzlich mindestens 3:1 |
| Buttonbeschriftung | Beschriftung gegen Buttonfläche | Textprüfung, Größe berücksichtigen |
| Erforderliche Elementbegrenzung | Erkennungsmerkmal gegen angrenzende Farbe | SC 1.4.11, grundsätzlich mindestens 3:1 |
| Fehlermeldung | Text sowie nötige visuelle Kennzeichnung | Mehrere Kriterien können einschlägig sein |
Diese Zusammenstellung ist eine technische Orientierung. Welche rechtlichen Anforderungen für Ihr Angebot gelten, ist eine eigene Frage. Eine bestandene Kontrastprüfung allein bestätigt weder vollständige WCAG-Konformität noch die Erfüllung sämtlicher Anforderungen des BFSG.
Das tatsächliche Farbpaar im Browser bestimmen
Prüfen Sie die gerenderte Seite, nicht nur zwei Farbfelder im Entwurf. Transparenz, Hintergrundbilder und überlagerte Flächen können verändern, welche Farben tatsächlich aufeinandertreffen. Bei einem Verlauf kann derselbe Text über unterschiedliche Hintergrundbereiche laufen. Dann reicht eine Messung an der günstigsten Stelle nicht aus.
Ermitteln Sie die vorgesehenen Vorder- und Hintergrundfarben mit einem geeigneten Prüfwerkzeug. Für Text erläutert das W3C, dass die zugrunde liegenden Farben maßgeblich sind und nicht zufällig abgetastete geglättete Randpixel eines Buchstabens. Kontrollieren Sie dennoch die tatsächliche Darstellung: Sehr dünne Schrift kann trotz rechnerisch ausreichender Werte schlecht lesbar wirken.
Runden Sie ein Ergebnis unterhalb des Grenzwerts nicht auf einen bestandenen Wert auf. Die W3C-Erläuterung nennt ausdrücklich, dass 4,499:1 die Anforderung 4,5:1 nicht erfüllt. Ein sinnvoller Designentscheid lässt deshalb etwas Abstand zur Grenze, statt jede Farbe bis an den rechnerischen Rand auszureizen.
Zustände gehören zur Prüfung dazu
Eine Seite besteht nicht nur aus ihrem ersten Bildschirmzustand. Öffnen Sie Menüs, lösen Sie Formularfehler aus und prüfen Sie vorhandene Hinweise beim Überfahren oder Fokussieren. Auch Platzhaltertexte können unter die Textanforderung fallen. Wenn die Farbe eines Buttons bei Interaktion wechselt, muss die Beschriftung auf dieser neuen Fläche erneut betrachtet werden.
- Auswählen Seite, Komponente und Zustand bestimmen.
- Ermitteln Tatsächliche Farbpaare und Textgröße erfassen.
- Zuordnen Passendes Erfolgskriterium und Ausnahmen prüfen.
- Bewerten Ungekürztes Messergebnis mit Anforderung vergleichen.
- Nachprüfen Geänderte Gestaltung in allen betroffenen Zuständen testen.
Die Tastaturbedienung ergänzt diesen Durchlauf. Ein sichtbarer Fokus hat eigene Anforderungen und sollte nicht allein über den Textkontrast beurteilt werden. Lesen Sie dazu Tastaturbedienung und Fokus prüfen. Bei Fehlern darf außerdem nicht ausschließlich die Farbe erklären, welches Feld betroffen ist; eine verständliche textliche Zuordnung hilft.
Beispiel: Die Fehlermeldung ist blasser als der Fließtext
Im erfundenen Beispiel besteht der normale Formulartext die Prüfung. Nach einer fehlerhaften Eingabe erscheint eine zusätzliche Meldung in einer anderen Farbe. Das Team hatte bisher nur die normale Textfarbe geprüft. In der Fehlerliste wird deshalb der genaue Auslöser ergänzt: Formular absenden, ohne das erforderliche Feld auszufüllen, und anschließend die neu sichtbare Meldung betrachten.
Die Gestaltung wird anhand des tatsächlichen Farbpaars angepasst. Danach prüft das Team erneut den Fehlerzustand und kontrolliert, ob die Änderung auch auf einer abweichenden Hintergrundfläche funktioniert. Es dokumentiert keinen erfundenen Messwert, sondern den im konkreten Browserlauf ermittelten Wert. Der Befund erhält einen Bezug zur Komponente, damit dieselbe fehlerhafte Farbe an anderen Stellen gefunden werden kann.
- „Rot zu hell“
- Kein Zustand genannt
- Kein Farbpaar dokumentiert
- Komponente und Auslöser genannt
- Farben und Textgröße erfasst
- Kriterium und Ergebnis zugeordnet
Verknüpfen Sie den Befund mit dem verwendeten Designwert, falls Ihre Oberfläche gemeinsame Farbdefinitionen nutzt. Eine zentrale Änderung kann mehrere Seiten verbessern, sollte aber anschließend auf unerwünschte Auswirkungen in anderen Zuständen geprüft werden.
Automatische Ergebnisse mit gezielter Handprüfung ergänzen
Automatische Prüfungen können viele problematische Farbpaare finden. Sie sehen aber nicht zwangsläufig jeden dynamischen Zustand oder jede komplexe Hintergrundsituation. Ein Ergebnis ohne gemeldeten Kontrastfehler ist deshalb kein Beweis dafür, dass jede relevante Darstellung geprüft wurde. Beschreiben Sie den tatsächlich getesteten Umfang.
BarriereRadar unterstützt das Auffinden und Nachhalten technischer Befunde. Die Grenzen automatischer Prüfungen erläutert Was ein WCAG-Scan erkennt. Ergänzen Sie die automatische Auswertung um die Zustände, die Ihre Nutzer im tatsächlichen Ablauf erreichen, und halten Sie fest, welche Fragen manuell beurteilt wurden.
Für die Übergabe zwischen Design und Entwicklung genügt oft eine kompakte Befundzeile: Seite, Komponente, Zustand, Farbpaar, Textgröße, Kriterium, Ergebnis und geplante Änderung. Nach der Umsetzung folgt derselbe Prüfschritt erneut. So bleibt nachvollziehbar, ob genau der ursprüngliche Fehler behoben wurde oder lediglich eine ähnliche Stelle verändert worden ist.
- Text und nichttextliche Erkennungsmerkmale werden getrennt geprüft.
- Das tatsächliche Farbpaar ist ermittelt.
- Größe, Gewicht und einschlägige Ausnahme sind berücksichtigt.
- Interaktions- und Fehlerzustände wurden einbezogen.
- Grenzwerte werden ohne günstiges Aufrunden bewertet.
- Die Änderung wurde am ursprünglichen Befund nachgeprüft.
Häufige Fragen
Braucht jede Buttonfläche 4,5:1 zum Seitenhintergrund?
Nein. Die Textbeschriftung wird gegen ihren Hintergrund geprüft. Für erforderliche nichttextliche Erkennungsmerkmale ist SC 1.4.11 gesondert einzuordnen.
Darf ich 4,49:1 auf 4,5:1 aufrunden?
Nein. Ein Wert unterhalb der geforderten Schwelle erfüllt sie nicht durch Aufrunden.
Beweist ein bestandener Kontrasttest vollständige Barrierefreiheit?
Nein. Kontrast ist ein Teilbereich. Weitere technische Kriterien und gegebenenfalls rechtliche Anforderungen müssen gesondert geprüft werden.
Das Wichtigste in Kürze
Prüfen Sie konkrete Farbpaare in den tatsächlich erreichbaren Zuständen.
Eine nachvollziehbare Fehlerbeschreibung macht die anschließende Korrektur und Nachprüfung deutlich einfacher.
Dieser Beitrag ersetzt keine Rechtsberatung. Eine automatisierte Erstprüfung ersetzt nicht den vollständigen BITV-/WCAG-Test – maßgeblich sind BFSG, BFSG-Verordnung und die harmonisierte Norm EN 301 549 in ihrer aktuellen Fassung.