Farbkontrast für Barrierefreiheit: WCAG 2.1, APCA und was man wirklich einsetzen sollte

WCAG 2.1 verlangt ein Kontrastverhältnis von 4.5:1 für normalen Fließtext und 3:1 für großen Text (ab 18 pt regulär oder ab 14 pt fett). Die Formel ist der faktische gesetzliche Standard in den USA (ADA-relevant), in der EU (EAA) und im Großteil der Welt. Sie hat zugleich gut dokumentierte Schwächen, die einen Nachfolger (APCA) hervorbrachten, der es nicht in WCAG 2.2 schaffte. Dieser Ratgeber erklärt das praktische Gesamtbild von heute.

Die WCAG-2.x-Kontrastformel

Definiert in WCAG 2.0 (2008) und unverändert bis 2.2:

contrast = (L_light + 0.05) / (L_dark + 0.05)
where L = relative luminance (0-1) of each colour, computed in linear-light sRGB

Die Ergebnisse reichen von 1:1 (identische Farben) bis 21:1 (reines Weiß auf reinem Schwarz).

WCAG-Schwellen (für AA-Konformität, das Standardziel):

• 4.5:1 — Fließtext, Icons, Formularelemente.
• 3:1 — großer Text (≥ 18 pt oder ≥ 14 pt fett), UI-Komponenten (Button-Ränder, Fokusindikatoren).
• AAA-Ziele sind strenger: 7:1 Fließtext, 4.5:1 großer Text. Nur in bestimmten Kontexten erforderlich (juristische Texte, Behörden).

Wo die Formel falsch liegt

Drei dokumentierte Probleme:

1. Unempfindlichkeit bei Mitteltönen. Die Formel vergibt gleiche Kontrastwerte an Mittelton-Paare (z. B. Grau auf Grau), die in der tatsächlichen Wahrnehmung sehr unterschiedlich aussehen. Ein 4.5:1-Paar mittlerer Grautöne kann visuell schwächer sein als ein 3:1-Paar aus Schwarz auf hellem Grau.
2. Farbtonblind. Farbtöne gleicher Luminanz (Rot und Grün bei gleicher Helligkeit) ergeben einen Kontrast von 1:1, doch dichromatische Nutzer können sie womöglich ohnehin schlecht unterscheiden. Die Formel kann Farbenblindheitsprobleme nicht erkennen.
3. Schriftstärke ignoriert. Dünne Schriften brauchen mehr Kontrast als fette Schriften bei gleicher Größe; WCAG rechnet die Stärke über die binäre Schwelle für „großen Text“ hinaus nicht an.

APCA: der Nachfolger, der es nicht in WCAG 2.2 schaffte

APCA (Accessible Perceptual Contrast Algorithm) ist die vorgeschlagene und abgelehnte Kontrastmetrik der nächsten Generation. Entwickelt von Andrew Somers für den WCAG-3.0-Arbeitsentwurf. Sie berücksichtigt die oben genannten Probleme und ist gegenüber echten Nutzerstudiendaten deutlich genauer.

APCA-Werte reichen von −108 bis +106. Positiv bedeutet dunkler Text auf hellem Hintergrund; negativ bedeutet das Gegenteil. Schwellen:

• Lc 75 — Fließtext (ersetzt die 4.5:1 von WCAG).
• Lc 60 — großer Text oder Überschriften (ersetzt 3:1).
• Lc 45 — Nicht-Inhaltstext (dekorativ, Copyright-Zeilen).

APCA vergibt je nach Richtung (hell auf dunkel vs. dunkel auf hell) unterschiedliche Schwellen, weil das menschliche Auge die beiden Fälle unterschiedlich verarbeitet. Die symmetrische Formel von WCAG übersieht dies.

Was man 2026 verwenden sollte

Zweigleisiger Ansatz:

1. Mindestens WCAG 2.1 AA bestehen. Das ist der gesetzliche Standard. Verwenden Sie die Standard-Verhältnisformel und zielen Sie auf 4.5:1 Fließtext / 3:1 großer Text. Werkzeuge: npm i wcag-contrast für programmatischen Einsatz, Browser-DevTools (Chrome und Firefox melden beide den Kontrast beim Überfahren) für Ad-hoc-Prüfungen.
2. APCA als Plausibilitätsprüfung nutzen. Wenn WCAG besteht, das Ergebnis aber subjektiv schwach wirkt, schlägt APCA meist Alarm. APCA ist als apca-w3 (npm) und in speziellen Werkzeugen (Atmos, Stark-Plugins) verfügbar.

Beide Metriken sind sich in den offensichtlichen Fällen einig (schwarzer Text auf Weiß ist in Ordnung; blasses Grau auf Weiß nicht). Sie weichen bei den Mittelton- und Großtext-Grenzfällen voneinander ab — genau dort, wo moderne Designtrends gern angesiedelt sind.

Konkrete Empfehlungen

• Fließtext: #1a1a1a (dunkles Grau) auf Weiß anzustreben ergibt ~17:1 — angenehm, klar lesbar. Reines Schwarz auf Weiß (21:1) kann hart wirken; bewusst gewähltes Fast-Schwarz ist in Ordnung.
• Deaktivierter Text / Platzhaltertext: WCAG nimmt „inaktive UI-Komponenten“ von der 4.5:1-Regel aus, doch Nutzer müssen Platzhalter dennoch lesen können. Zielen Sie auf mindestens 3:1.
• Buttons: Button-Text gegenüber Button-Hintergrund muss 4.5:1 erreichen. Button-Rand gegenüber Seitenhintergrund muss 3:1 erreichen (für die „Nicht-Text-Kontrast“-Regel).
• Fokusindikatoren: Die Fokusumrandung muss 3:1 gegen den angrenzenden Hintergrund erreichen. Das ist die Regel, die am häufigsten bricht, wenn Designer die standardmäßigen Browser-Fokusumrandungen entfernen.
• Dark Mode: Die WCAG-Formel ist symmetrisch; die Zahlen übertragen sich. Doch APCA ist asymmetrisch — der Dark Mode braucht für die gleiche wahrgenommene Qualität tendenziell etwas andere Design-Tokens als der Light Mode. Kehren Sie Farben nicht einfach um.

Was man weglassen kann

• Verlassen Sie sich nicht allein auf Kontrast als Signal für Zustände. Fehlerzustände brauchen Kontrast und einen weiteren Hinweis (ein Icon, Text). Farbenblinde Nutzer unterscheiden rote Fehler womöglich auch bei hohem Kontrast nicht von grünen Erfolgen.
• Streben Sie AAA nicht reflexartig an. Der eigene WCAG-Leitfaden sagt, AAA sei „nicht als generelle Richtlinie für ganze Websites empfohlen“ — es ist für bestimmte Kontexte gedacht. AA ist für die meisten Produkte die Design-Obergrenze.
• Vertrauen Sie automatisch generierten Farbverläufen nicht unkritisch. Ein OKLCH-Verlauf mit gleichmäßigen wahrnehmungsbezogenen Schritten besteht WCAG nicht automatisch. Verifizieren Sie jedes benachbarte Paar.

Der pragmatische Arbeitsablauf

Zur Designzeit: Nutzen Sie den WCAG-Kontrastprüfer in Ihrem Designwerkzeug (Figma, Sketch, Adobe XD haben alle Plugins). Erreichen Sie die Minima von 4.5:1 / 3:1.

Zur Code-Zeit: Linten Sie Ihre Design-Tokens mit wcag-contrast oder Ähnlichem gegen WCAG. Lassen Sie die CI bei Regressionen fehlschlagen.

Zur QA-Zeit: echtes Testen mit Screenreader und Tastaturnavigation. Kontrast ist nur ein kleiner Ausschnitt der Barrierefreiheit; die Tastatur- und Screenreader-Pfade sind dort, wo die meisten A11y-Fehler tatsächlich wohnen.

Durchgerechnetes Beispiel: eine Markenfarbe, die „besteht“

Marken-Türkis #3aa6a0 auf weißem Hintergrund. WCAG- Kontrast: 2.99:1 — besteht AA für Fließtext nicht (benötigt 4.5:1) und verfehlt die 3:1-Schwelle für großen Text um Haaresbreite. APCA-Wert: Lc 52, was APCA als „nur für Nicht-Inhaltstext oder ab 24 px verwenden“ einstuft. Beide Metriken sind sich einig: Dieses Türkis besteht nicht als Fließtext auf Weiß.

Verdunkelt man das Türkis um eine Stufe auf #2f8682: WCAG 4.52:1 (besteht AA-Fließtext), APCA Lc 67 (besteht APCA für großen Text, grenzwertig für Fließtext). Eine Änderung um eine Hex-Ziffer bewegt die Komponente vom Durchfallen zum Bestehen — und der zugrunde liegende wahrgenommene Farbton bleibt erkennbar dasselbe Türkis. Markenfarben überstehen den Kontakt mit Barrierefreiheit selten ohne eine Dark-Mode-Variante; bauen Sie die Variante zugleich mit der Markenpalette, nicht nachträglich.

Häufige Fehler

• Nur gegen Weiß testen. Fließtext auf einem farbigen Panel, Button-Text auf einem farbigen Button, Linktext in einer Fußzeile mit dunklem Hintergrund — jedes Paar braucht seine eigene Prüfung. Ein Token-System, das eine paarweise Kontrastprüfung vorschreibt, fängt das ab, was das bloße Auge übersieht.
• Text über Bildern ignorieren. Hero- Überschriften über Fotos versagen fast immer irgendwo auf dem Bild. Lösungen: ein halbtransparentes dunkles Overlay unter dem Text (Deckkraft auf 0,4–0,6 senken), ein Textschatten, der am Glyphenrand Kontrast erzeugt, oder das Verschieben des Textes auf ein deckendes Panel.
• Sich für die Lesbarkeit auf Hover-Zustände verlassen. Hover-Stile verbessern oft den Kontrast (dunkler beim Überfahren) — aber der Ruhezustand ist das, was der Nutzer liest. Wenn der Ruhezustand versagt, rettet ihn der Hover nicht.
• rgba() mit niedrigem Alpha für Text verwenden.Durchscheinender Text erbt das, was dahinterliegt. Der berechnete Kontrast hängt vom Hintergrund ab; auf einem farbigen Hintergrund versagt Alpha < 0,8 fast immer. Verwenden Sie deckende Hex-Werte für Text und reservieren Sie Alpha für dekoratives Beiwerk.
• Farbenblind-Simulation als Barrierefreiheitstest behandeln. Simulationswerkzeuge (Chrome DevTools, Stark) zeigen näherungsweise, was ein farbenblinder Nutzer sieht. Sie testen nicht, ob der Kontrast ausreichend ist; sie testen, ob Farben unterscheidbar sind. Beide Prüfungen sind nötig.

Für die zugrunde liegenden Farbraum-Mechanismen, die die Formel linearisiert, siehe unseren Ratgeber zu CSS-Farbformaten.

Quellen: W3C WCAG 2.1 (2018) und WCAG 2.2 (2023); WCAG-3.0- Arbeitsentwurf (2024); Andrew Somers, APCA-W3-Dokumentation und begleitende Nutzerstudien; US DOJ ADA Title III Web- Barrierefreiheitsregel (2024); EU-Rechtsakt zur Barrierefreiheit (Richtlinie 2019/882).