Themen
Kontraste auf Websites richtig prüfen
Dieser Leitfaden erklärt, warum Farbkontraste für barrierefreie Websites zentral sind, welche Werte für Text und Bedienelemente praktisch zählen, wo typische Probleme entstehen und wie Betreiber Kontrastprobleme im Alltag systematisch vermeiden können.
Kontraste sind kein reines Designdetail. Schlechte Lesbarkeit betrifft nicht nur Fließtext, sondern auch Buttons, Formulare, Statusmeldungen, Icons, Charts und Fokuszustände. Wer Kontraste nur auf einzelnen Textblöcken prüft, übersieht oft die wichtigsten Hürden.
Warum Kontraste wichtig sind
Kontraste entscheiden darüber, ob Inhalte überhaupt wahrnehmbar sind. Wenn Text, Icons, Linien oder Zustände zu wenig Abstand zum Hintergrund haben, verschwinden sie für viele Menschen teilweise oder vollständig. Das betrifft Menschen mit geringerem Sehvermögen, Farbsehschwächen oder Vergrößerung genauso wie Nutzer im hellen Tageslicht, auf kleinen Displays oder in stressigen Alltagssituationen.
In der Praxis scheitern Websites selten nur an einem dramatischen Kontrastfehler. Häufiger ist die Summe vieler kleiner Probleme: zu helles Grau für Metatexte, schwache Formularränder, zarte Fokusindikatoren, farbige Statusbadges ohne ausreichende Lesbarkeit oder Buttons, deren Text gerade noch sichtbar ist. Genau diese Details entscheiden darüber, ob ein Angebot klar und belastbar nutzbar bleibt.
Was mit Kontrast überhaupt gemeint ist
Bei Farbkontrast geht es nicht einfach darum, dass zwei Farben unterschiedlich sind. Entscheidend ist, wie stark sie sich in ihrer wahrgenommenen Helligkeit voneinander abheben. Zwei Markenfarben können subjektiv deutlich verschieden aussehen und trotzdem zu wenig Kontrast für lesbaren Text haben.
Für die Bewertung zählt außerdem immer die direkte Nachbarschaft. Ein Button wird nicht gegen den gesamten Seitenhintergrund geprüft, sondern gegen die unmittelbar angrenzende Farbe. Dasselbe gilt für Text, Icons, Fokusrahmen, Linien in Diagrammen oder Formularränder. Gerade bei Verläufen, Bildern, Overlays oder halbtransparenten Farben wird das schnell komplexer, als es im Designfile zunächst aussieht.
Welche Kontrastwerte wichtig sind
Für Websites sind vor allem drei Werte relevant. Sie kommen aus den WCAG und bieten eine praktische Mindestorientierung für Text, Bedienelemente und grafische Informationen.
Normaler Text
4,5:1
Das ist der typische Mindestwert für Fließtext, kleinere Labels, Navigation, Hinweise, Metatexte und sonstigen Standardtext. Alles, was wie gewöhnlicher Text erscheint, sollte mindestens diesen Wert erreichen.
Großer Text
3:1
Für großen Text gilt ein geringerer Mindestwert. W3C definiert das vereinfacht als etwa 24 px normal oder ungefähr 18,5 px fett. Für Headlines kann das ausreichen, für kleine Interface-Texte nicht.
UI-Komponenten und Grafiken
3:1
Wenn die sichtbare Form eines Feldes, Buttons, Tabs, Icons oder Diagrammteils notwendig ist, um die Funktion oder Information zu verstehen, sollte diese visuelle Information mindestens 3:1 zum angrenzenden Hintergrund erreichen.
Wichtiger Praxispunkt
Kontrastwerte werden nicht aufgerundet. Ein Verhältnis von 4,49:1 besteht den Mindestwert 4,5:1 nicht. Sichtbarer Placeholder-Text, Hover-Text und Text im Fokus sind ebenfalls normaler Text und müssen entsprechend lesbar bleiben.
Logos und reine Wortmarken sind nach WCAG bei den Textkontrastanforderungen andere Sonderfälle. Für normale Interface-Texte, Labels, Buttons oder Statusmeldungen gilt diese Ausnahme aber nicht.
Wo Kontrastprobleme typischerweise auftreten
Kontrastprobleme verstecken sich selten nur im offensichtlichen Fließtext. Besonders häufig treten sie in Komponenten, Zuständen und Nebentexten auf, die im Design sekundär wirken, für die Nutzung aber trotzdem wichtig sind.
Text in Nebenzonen
Metadaten, Captions, kleinere Navigation, Datumsangaben, sekundäre Buttons oder vermeintlich „ruhige“ Interface-Texte sind besonders oft zu blass gestaltet.
Buttons und Interaktionsflächen
Farbige Primär- und Sekundärbuttons verlieren schnell Kontrast, wenn die Marke dominieren soll und die Lesbarkeit nicht systematisch mitgedacht wird.
Formulare
Placeholder, Labels, Hilfetexte, Fehlermeldungen und Feldränder sind klassische Schwachstellen. Gerade feine Grautöne und subtile States reichen häufig nicht aus.
Statusfarben und Auszeichnungen
Warnungen, Fehler, Erfolgsmeldungen, Badges und Diagrammfarben funktionieren oft nur in der Theorie, aber nicht unter realen Bedingungen oder bei Farbsehschwächen.
Fokuszustände
Tabs, Links, Buttons und Formularelemente verlieren schnell ihre Erkennbarkeit, wenn Fokusrahmen zu dünn, zu hell oder farblich zu nah am Hintergrund liegen.
Grafiken und Charts
Linien, Balken, Icons und Statuspunkte sind oft sichtbar gedacht, aber in helleren Farben nicht ausreichend unterscheidbar oder nur über Farbe codiert.
Was für Text gilt
Für normalen Text ist 4,5:1 der entscheidende Richtwert. Das betrifft Fließtext, Navigationspunkte, Formularlabels, Hilfetexte, Datumsangaben, Hinweise in Modalen, Accordion-Überschriften und praktisch alle kleineren Beschriftungen im Interface. Größerer Text darf ab 3:1 auskommen, sollte aber in der Praxis oft trotzdem stärker sein, damit er auch auf schwächeren Displays oder bei dünnen Schriftschnitten stabil lesbar bleibt.
Besonders kritisch ist Text auf Bildern, Verläufen oder halbtransparenten Overlays. Was im statischen Mockup noch funktioniert, kann im echten Frontend schnell kippen, wenn sich Hintergrundbilder, Systemschriften oder Rendering unterscheiden. Dasselbe gilt für sehr feine Schriftstärken, kleine Uppercase-Texte und lange Passagen in sehr hellen Grautönen.
Wichtig ist außerdem: Placeholder-Text ist sichtbarer Text und muss lesbar bleiben. Er sollte ohnehin kein Ersatz für ein korrektes Label sein. Wenn Hinweise, Pflichtfeldmarkierungen oder Fehlermeldungen nur als blasser Placeholder erscheinen, entstehen gleich mehrere Barrieren gleichzeitig.
Was für Buttons, Formulare und Zustände gilt
Bei Bedienelementen muss man zwei Dinge getrennt betrachten: erstens den Text im Element und zweitens die sichtbare Form oder den Zustand des Elements. Der Text in einem Button braucht den passenden Textkontrast. Wenn die sichtbare Umrandung, Füllung oder Markierung notwendig ist, um das Element zu erkennen, muss auch diese visuelle Information ausreichend Kontrast zum angrenzenden Hintergrund haben.
Das betrifft typische UI-Muster wie Input-Borders, Checkboxen, Radiobuttons, Tabs, Toggle-Zustände, Fehlerränder, Erfolgshinweise oder aktive Navigation. Besonders heikel wird es, wenn ein Zustand fast nur über Farbe vermittelt wird. Ein roter Fehlerrahmen ohne klare Fehlermeldung, ein Fokuszustand, der nur minimal heller wird, oder ein sekundärer Button, dessen Schrift kaum noch lesbar ist, sind klassische Schwachstellen.
Bei inaktiven Komponenten sieht WCAG bei Nicht-Text-Kontrast Ausnahmen vor. Für die Praxis heißt das aber nicht, dass deaktivierte Zustände beliebig blass sein sollten. Wenn Nutzer nicht mehr erkennen können, dass überhaupt ein Button oder Feld vorhanden ist, leidet die Verständlichkeit der Oberfläche trotzdem.
Gute Faustregel: Prüfe immer Default, Hover, Fokus, Aktiv-, Fehler- und Disabled-Zustand. Viele Kontrastprobleme treten nicht im Grundzustand auf, sondern erst in States.
Was bei Icons, Grafiken und Nicht-Text-Elementen relevant ist
Kontraste sind nicht nur ein Textthema. Wenn grafische Objekte notwendig sind, um Inhalte zu verstehen oder eine Funktion zu erkennen, müssen auch sie sich ausreichend vom Hintergrund abheben. Dazu gehören etwa Status-Icons, Diagrammlinien, Balken, Schalterstellungen, Auswahlmarkierungen, Icons in Formularen oder sichtbare Fokusindikatoren.
Entscheidend ist, ob das Objekt eine inhaltliche oder funktionale Aufgabe hat. Ein rein dekoratives Ornament ist anders zu bewerten als ein Warnsymbol, das ohne Text einen Zustand erklärt. Wenn ein Icon nur Schmuck ist, ist geringer Kontrast weniger kritisch. Wenn ein Icon die einzige visuelle Information trägt, sollte es klar und stabil wahrnehmbar sein.
Für Charts und Visualisierungen gilt zusätzlich: Farbe allein reicht nicht. Linien, Segmente und Datenpunkte sollten genügend Kontrast haben, aber auch ergänzende Beschriftungen, Muster, Formen oder direkte Wertehilfen bekommen. Sonst sind Diagramme schnell nur für einen Teil der Nutzer interpretierbar.
Typische Fehler in der Praxis
- Hellgrau auf Weiß: beliebt in ruhigen Interfaces, aber oft zu schwach für normale Labels, Hilfetexte und Metadaten.
- Placeholder als einzige Information: wenn Feldzweck, Format oder Pflichtangabe nur im blassen Placeholder stehen, scheitern Lesbarkeit und Verständlichkeit zugleich.
- Fehlerzustände nur über Farbe: ein roter Rand oder ein grüner Punkt allein reicht nicht. Zustände brauchen zusätzliche Text- oder Symbolhinweise.
- Farbige Buttons mit schwacher Schrift: Brandingfarben funktionieren als Flächen oft schlechter als gedacht, vor allem mit weißer Schrift.
- Unlesbare sekundäre oder deaktivierte Zustände: Sekundäre Buttons, Tabs oder deaktivierte Controls werden oft so blass, dass sie kaum noch als Interface erkennbar sind.
- Zu dünne Fokusindikatoren: ein kaum sichtbarer Outline-Schatten oder eine leicht geänderte Hintergrundfarbe reicht für Tastaturnutzer häufig nicht aus.
- Links nur über Farbe unterscheiden: wenn laufender Text und Linktext fast gleich aussehen, fehlt vielen Nutzern ein verlässliches Erkennungsmerkmal.
- Kontrast nur im Designfile prüfen: echte Oberflächen mit Hover, Fokus, Transparenz, Browserdarstellung und responsiven Varianten verhalten sich oft anders als statische Entwürfe.
Wie man Kontraste sinnvoll prüft
Eine sinnvolle Prüfung beginnt nicht auf einzelnen Seiten, sondern auf Komponenten- und Token-Ebene. Wenn Farben, Textstile und States im Designsystem sauber definiert sind, lassen sich viele Probleme früh abfangen. Wer erst die fertige Seite prüft, flickt meist nur Symptome.
1. Reale Farbkombinationen prüfen
Nicht mit abstrakten Markenfarben rechnen, sondern mit den tatsächlich verwendeten Vorder- und Hintergrundfarben in der Oberfläche.
2. Alle States durchgehen
Default, Hover, Fokus, Aktiv, Fehler, Erfolg und Disabled gesondert prüfen. Kontrastprobleme sitzen oft nur in einzelnen Zuständen.
3. Text und Nicht-Text getrennt bewerten
Textkontrast und Nicht-Text-Kontrast sind nicht dasselbe. Ein Button kann beim Text bestehen und bei seiner Umrandung oder Fokusmarkierung trotzdem scheitern.
4. Zoom und reale Nutzung testen
Prüfe auf mobilen Ansichten, bei Vergrößerung und in realen Bildschirm- und Lichtverhältnissen. Kontrast ist kein rein mathematisches Laborthema.
5. Automatisch plus manuell
Automatische Checks finden viele Kontrastprobleme schnell, aber sie bewerten nicht jede reale Nutzungssituation. Manuelle Sichtprüfung bleibt wichtig.
6. Nicht schönrechnen
Grenzwerte sollten nicht als grobe Empfehlung behandelt werden. Wenn ein Wert knapp darunter liegt, ist das kein „fast bestanden“, sondern ein Problem.
Wenn du prüfen willst, ob deine Website insgesamt barrierefrei sein muss und welche weiteren Anforderungen neben Kontrasten relevant sind, hilft dir auch der umfassendere Leitfaden Was eine barrierefreie Website leisten muss.
Wie Betreiber Kontrastprobleme vermeiden
Kontrastprobleme lassen sich am besten vermeiden, wenn sie nicht erst am Ende der Entwicklung geprüft werden. Gute Teams verankern Lesbarkeit und Zustandslogik direkt in Designsystem, Redaktion und Qualitätssicherung.
- 1. Farbpalette absichern: Definiere nicht nur Markenfarben, sondern einsatzfähige Kombinationen für Text, Flächen, Umrandungen und Zustände.
- 2. Komponenten standardisieren: Buttons, Formulare, Tabs, Badges und Fokuszustände sollten als wiederverwendbare Muster mit geprüften Kontrasten vorliegen.
- 3. Farbe nie allein sprechen lassen: Ergänze Farben durch Text, Icons, Unterstreichungen, Muster oder klare Labels.
- 4. Sekundäre Texte ernst nehmen: Hilfetexte, Datumsangaben, Meta-Informationen und Hinweise sind keine reine Deko. Sie müssen lesbar bleiben.
- 5. Redesigns und Brand-Updates prüfen: Neue Farben, neue Typografie oder modernere UI-Stile verschlechtern Kontraste oft unbemerkt, wenn sie nicht systematisch gegengeprüft werden.
- 6. Vor Veröffentlichung testen: Prüfe die wichtigsten Seiten und Nutzerwege manuell, statt nur auf generelle Komponentenfreigaben zu vertrauen.