Was ist ein guter Kontrast? WCAG 2.2, AA, AAA und warum hellgrau auf weiß nicht reicht

Designer lieben elegantes Hellgrau auf Weiß. Nutzer mit Sehschwäche, ältere Menschen oder einfach jeder im Sommer in der Sonne auf dem Handy hassen es. Die Web Content Accessibility Guidelines (WCAG) liefern seit Jahren konkrete Zahlen, ab wann Text wirklich lesbar ist — und seit dem BFSG ist Kontrast in Deutschland für viele Anbieter nicht mehr nice-to-have, sondern Gesetz.

Warum Kontrast überhaupt zählt

Etwa 8 % aller Männer und 0,5 % aller Frauen haben eine Form von Farbsehschwäche. Hinzu kommen Menschen mit Katarakt, Makuladegeneration oder einfach nachlassender Sehschärfe im Alter — laut WHO weltweit mehr als 2,2 Milliarden Personen mit einer Sehbeeinträchtigung. Schlechter Kontrast schließt diese Gruppe systematisch aus, oft ohne dass es jemandem im Designprozess auffällt.

Selbst Nutzer ohne Einschränkung lesen schwachen Text deutlich langsamer und ermüden schneller. Studien zur Lesegeschwindigkeit zeigen, dass die Wortverarbeitung bei einem Kontrast unter 4:1 messbar einbricht. Wer denkt, dass Kontrast nur eine Accessibility-Nische sei, übersieht: bessere Lesbarkeit verbessert Conversion-Raten, weil Nutzer länger und konzentrierter bleiben.

Die WCAG-Stufen im Überblick

WCAG kennt drei Konformitätsstufen: A (minimal), AA (Standard für die meisten Websites) und AAA (höchstes Niveau, in der Praxis selten flächendeckend erreichbar). Für Text-Kontrast gelten konkret folgende Mindestverhältnisse zwischen Vorder- und Hintergrundfarbe:

• Level AA, normaler Text: mindestens 4,5:1 — das ist der Standard, an dem du dich orientieren solltest.
• Level AA, großer Text (ab 18 pt regulär oder 14 pt fett): mindestens 3:1 — Überschriften und große Buttons dürfen heller sein.
• Level AAA, normaler Text: mindestens 7:1 — empfohlen für lange Lesetexte, Behördenportale, Banking.
• Level AAA, großer Text: mindestens 4,5:1 — also genau das, was AA für normalen Text fordert.
• Nicht-textuelle Elemente (Icons, Bedienelemente, Grafiken, Diagramme): mindestens 3:1 zur direkten Umgebung (WCAG 1.4.11).

Wie das Kontrastverhältnis berechnet wird

Das Kontrastverhältnis ist (L1 + 0,05) / (L2 + 0,05), wobei L1 die hellere und L2 die dunklere relative Luminanz ist. Die Luminanz selbst wird aus den sRGB-Komponenten gewichtet — Grün hat den größten Einfluss, Rot mittelmäßig, Blau am wenigsten. Deshalb sieht reines Blau auf Schwarz selbst bei mathematisch passablem Kontrast oft schlechter aus, als das Verhältnis vermuten lässt.

Die Werte reichen theoretisch von 1:1 (gleiche Farbe) bis 21:1 (Schwarz auf Weiß). 4,5:1 entspricht ungefähr Dunkelgrau (#595959) auf Weiß — viele Designs landen darunter, vor allem bei Platzhaltertexten, deaktivierten Buttons oder grauen Untertiteln. Eine Sekunde im Kontrast-Checker rettet hier oft Stunden in der späteren Audit.

APCA — der Nachfolger für WCAG 3.0

Die WCAG-2-Formel hat ein bekanntes Problem: bei sehr hellen oder sehr dunklen Kombinationen liefert sie irreführende Werte. Schwarzer Text auf knallgelb bekommt fast 20:1, sieht aber im Dark-Mode-Vergleich oft schlechter aus als ein milderer Kontrast. APCA (Advanced Perceptual Contrast Algorithm) modelliert wahrnehmungsgerechter, berücksichtigt Schriftgröße und -gewicht direkt und liefert einen Wert in Prozentpunkten Helligkeitsdifferenz (Lc).

APCA ist als Kandidat für WCAG 3.0 vorgesehen, aber noch nicht offiziell verabschiedet. In der Praxis gilt: für rechtsverbindliche Konformität heute WCAG 2.2 nehmen, für Dark-Mode-Designs und sehr feines Tuning APCA als zweite Meinung dazuziehen. Beide Werte können in einem guten Kontrast-Tool nebeneinander angezeigt werden.

Rechtlicher Rahmen 2026

Seit 28. Juni 2025 ist in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG) wirksam. Es zwingt zahlreiche Anbieter — Online-Shops, Banking-Apps, Reise- und Transportanbieter, E-Book-Reader, viele B2C-Dienste — zur Einhaltung des EN-301-549-Standards, der WCAG 2.1/2.2 AA fordert. Verstöße können mit Bußgeldern bis 100.000 € sanktioniert werden, in extremen Fällen droht die Marktrücknahme.

In den USA gibt es seit Jahrzehnten Section 508 für Behörden und den Americans with Disabilities Act, der in der Rechtsprechung zunehmend auf Websites angewendet wird. Wer eine internationale Zielgruppe bedient, kann Accessibility heute nicht mehr als optional einstufen — und Kontrast ist die niedrig hängende Frucht, die in jeder Audit zuerst auffällt.

Typische Stolperfallen

Folgende Elemente werden in 90 % aller Designs übersehen — prüfe sie gezielt:

• Placeholder-Text in Formularen: per Default oft viel zu hellgrau (z. B. #999) — sobald er Information transportiert, gilt 4,5:1.
• Fokus-Indikatoren: Browser-Default-Outline wird häufig per CSS entfernt — der Ersatz muss mindestens 3:1 zum Hintergrund haben (WCAG 2.4.11, neu in 2.2).
• Deaktivierte Buttons: WCAG nimmt sie formal aus, aber wenn Nutzer nicht erkennen können, dass etwas deaktiviert ist, ist das ein Usability-Bug. Pragmatisch: mindestens 3:1.
• Markenfarben auf Markenfarben: Logo-Farben werden gern auch für Buttons oder Text auf farbigem Hintergrund verwendet — fast immer eine Kontrastfalle.

Was mich ein Brand-Redesign über Kontraste gelehrt hat

2023 habe ich ein Brand-Redesign für ein Kundenprojekt begleitet. Das neue Corporate-Türkis war wunderschön — und hatte gegen Weiß einen Kontrast-Ratio von 2,1:1. WCAG AA verlangt 4,5:1 für normalen Text. Die Marketingabteilung argumentierte: »unser Türkis ist Marke, das ist nicht verhandelbar«. Wir landeten bei einem Kompromiss: das Marken-Türkis nur für große Headlines (≥18 pt / ≥24 px), für Body-Text eine 22 % dunklere Variante. Beide nutzen aus Sicht des Kunden »dasselbe Türkis«, der A11y-Check ist trotzdem grün.

Was ich daraus mitgenommen habe: WCAG-Compliance ist meistens kein technisches Problem, sondern ein politisches. Designer und Marketing wollen das »reine« Brand-Element. Entwickler wollen schnellen Code. Niemand will der Spielverderber sein, der »wir können das nicht so machen« sagt. Die Lösung ist fast nie »Brand-Farbe ändern« — sondern »Brand-Farbe in kontextspezifischen Varianten denken«. Eine Marke kann zwei oder drei Teal-Töne haben, die alle erkennbar dieselbe Familie sind, aber unterschiedliche Kontrast-Eigenschaften haben.

Praktisch nutze ich seit 2024 ein dreiteiliges Brand-Token-System: --brand-primary (die Marken-Farbe für große Elemente), --brand-text (dunklere Variante für Body-Text auf Weiß), --brand-text-inverse (hellere Variante für Body-Text auf Dunkel). Alle drei werden aus dem »Hero-Wert« generiert, sodass das Markenbild stimmig bleibt — aber jeder Anwendungsfall hat seinen kontrastsicheren Token.

WCAG 2.2: was sich 2024 geändert hat

WCAG 2.2 wurde im Oktober 2023 zur W3C Recommendation und ist seit 2024 die maßgebliche Version. Beim Thema Kontrast hat sich strukturell wenig geändert — die 4,5:1 / 3:1 / 7:1 Schwellen bleiben gleich. Aber 2.2 fügt 9 neue Erfolgskriterien hinzu, die sich auf andere Bereiche der Barrierefreiheit konzentrieren: Focus-Visibility, Target-Size, Drag-Movements, Consistent-Help, Redundant-Entry, Accessible-Authentication.

Besonders relevant für UI-Designer: 2.5.8 Target Size (Minimum) — interaktive Elemente müssen mindestens 24×24 CSS-Pixel groß sein. 2.4.11 Focus Not Obscured — beim Tab-Navigation darf der fokussierte Element nicht durch andere UI-Elemente überdeckt werden. 3.3.7 Redundant Entry — gleiche Daten dürfen nicht im selben Prozess mehrfach abgefragt werden (z. B. Rechnungs- und Lieferadresse muss kopierbar sein).

Für deutsche Anbieter wichtig: das BFSG (Barrierefreiheitsstärkungsgesetz) seit 28.06.2025 verpflichtet praktisch alle B2C-Online-Anbieter (Shops, Banken, Reisedienste) zu WCAG 2.2 AA. Bußgelder bis 100.000 EUR sind möglich. Behörden waren schon über die BITV 2.0 betroffen — jetzt sind auch privatwirtschaftliche Anbieter im Pflicht-Modus. Wer 2026 eine Website betreibt und noch nicht WCAG-2.2-konform ist, sollte priorisieren.

Mein Audit-Workflow für Accessibility-Compliance

Eine Mischung aus automatischen Tools und manuellen Checks, die ich für jedes Projekt durchgehe:

• Browser Devtools. Chrome und Edge haben in Lighthouse einen guten Accessibility-Audit eingebaut, der die häufigsten Probleme (fehlende ARIA-Labels, Kontrast-Issues, falsche heading-Hierarchie) automatisch findet. F12 → Lighthouse → Accessibility checken. Dauer: 60 Sekunden pro Seite.
• axe DevTools Browser-Extension. Detaillierter als Lighthouse, mit konkreten Code-Empfehlungen pro Treffer. Gratis-Tier reicht für die meisten Projekte. Bei größeren Audits zahlt sich die Pro-Variante (399 USD/Jahr) aus.
• CI-Integration via axe-core. Wer Accessibility nicht nur als Wartungs-Posten haben will, baut axe-core in die CI-Pipeline ein. Bei jedem Commit werden die Seiten automatisch gegen WCAG-Kriterien geprüft, Issues werden im PR als Comment angezeigt. Setup: ca. 2 Stunden, danach läuft es vergessen.
• Echte Screenreader-Tests. NVDA (Windows, gratis), VoiceOver (Mac, eingebaut), TalkBack (Android, eingebaut). Mindestens einmal pro Quartal die wichtigsten Flows mit echtem Screenreader durchlaufen. Automatische Tools übersehen subtile Probleme wie verwirrende Reihenfolge oder unnütze Decorations.
• Graustufen-Test. Lass die Seite testweise im Graustufen-Modus rendern (im Browser: Devtools → Rendering → Emulate Vision Deficiencies → Achromatopsia). Was bleibt verständlich, was fällt zusammen? Wenn Buttons ohne Farbe nicht mehr als Buttons erkennbar sind, brauchst du zusätzliche visuelle Differenzierung (Border, Icon, Untertitel).

Mein Standard-Cadenz für laufende Projekte: 1x pro Monat Lighthouse-Run, 1x pro Quartal vollständiger axe-Audit, 2x pro Jahr Screenreader-Test mit echtem Nutzer (oder zumindest selbst durchgespielt). Plus CI-Integration für automatische Regression-Erkennung. Das ist nicht trivial, aber wenn es einmal läuft, ist es fast Wartungsfrei.

Farbenblindheit: was du wissen solltest

Etwa 8 % aller Männer und 0,5 % aller Frauen haben eine Form von Farbsehschwäche. Die häufigste ist die Rot-Grün-Schwäche (Deuteranopie/Protanopie), bei der Rot und Grün ähnlich aussehen. Die zweithäufigste ist Tritanopie (Blau-Gelb-Schwäche). Vollständige Farbenblindheit (Achromatopsie) ist sehr selten (1:30.000), aber existiert.

Praktische Konsequenz für UI-Design: niemals Farbe ALLEIN als Information nutzen. Eine rote »ungültig«-Box braucht zusätzlich ein Icon (X) oder Text (»Error«). Eine grüne »OK«-Box braucht zusätzlich ein Häkchen. Status-Indikatoren mit »rot/grün-Ampel«-Logik sind für Rotgrün-Blinde unbrauchbar — füge Form (Kreis/Dreieck/Quadrat) oder Symbol hinzu. WCAG 1.4.1 (»Use of Color«) ist genau dafür. Browser-Simulationen (siehe oben) geben dir innerhalb von Sekunden ein Gefühl, wie dein UI für betroffene Nutzer aussieht.

Häufige Fragen

Reicht es, wenn ich überall AA habe?

Für die meisten kommerziellen Websites ja. AA ist der gesetzlich geforderte Standard nach BFSG, ADA und EN 301 549. AAA strebt man freiwillig an, wenn lange Lesetexte (Magazin, Blog, Wissensbasis) oder sicherheitskritische Zielgruppen (Banking, Gesundheit) im Vordergrund stehen.

Was mache ich, wenn die Markenfarbe das Verhältnis sprengt?

Dann wird die Markenfarbe zur dekorativen Akzentfarbe und nicht für Text genutzt. Praxisbeispiel: das knallige Orange als Button-Hintergrund mit weißem Text funktioniert, als Textfarbe auf weißem Hintergrund nicht. Viele Brand-Guides definieren deshalb eine zweite, dunklere Version explizit für Text — das sollte standardmäßig im Designsystem stehen.

Wie wirken sich Dark-Mode und Bildhintergründe aus?

Dark Mode verändert das Spiel: helle Schrift auf sehr dunklem Grund kann bei zu dünner Schrift unscharf wirken (Halation). Hier hilft etwas mehr Font-Weight oder eine minimal hellere Variante des Dunkelgraus. Bildhintergründe brauchen Text-Schatten oder eine halbtransparente Overlay-Box — den Kontrast misst man dann an der dunkelsten Stelle hinter dem Text.

Was ist der Unterschied zwischen WCAG AA und AAA?

WCAG hat drei Stufen: A (Minimum), AA (Standard für die meisten gesetzlichen Anforderungen), AAA (Premium). Praktisch zielen über 95 % aller Sites auf AA — das ist die rechtliche Schwelle für deutsche BFSG, US-ADA-Lawsuits und EU-Webrichtlinie. AAA ist für hochspezialisierte Anwendungen (Behindertenorganisationen, Schulungsplattformen für Sehbehinderte) sinnvoll, aber für die meisten kommerziellen Anwendungen overkill und teils visuell einschränkend (7:1 Kontrast bedeutet praktisch Schwarz auf Weiß).

Wie misst man Kontrast bei animierten oder transparenten Elementen?

Bei Animationen gilt der schlechteste Frame — wenn ein Element für 200 ms in einer kontrastarmen Phase ist, gilt diese Phase. Praktisch heißt das: Hover-Übergänge sollten am Endzustand getestet werden (der Default und der Hover-Zustand müssen beide WCAG-konform sein). Bei transparenten Elementen (z. B. semitransparente Overlay-Boxen) musst du den finalen, gerenderten Farbwert messen — also das, was der Browser tatsächlich anzeigt. Browser-Devtools liefern den »Computed Color«-Wert, gegen den du dann prüfen kannst.

Gibt es Tools, die meine WCAG-Compliance kontinuierlich überwachen?

Ja, mehrere: Deque axe Monitor (Enterprise, teuer), Pa11y (Open Source, gratis, CI-tauglich), WAVE API (kostenlos für gelegentliche Scans, kostenpflichtig für API-Volumen), Tenon.io (freemium). Für 90 % der kleineren Projekte reicht Pa11y in der CI-Pipeline. Für Enterprise-Projekte mit Compliance-Anforderungen lohnt sich der Enterprise-Stack — er liefert Dashboards, Trend-Analysen und juristisch verwertbare Reports.