WCAG-Kontrastverhältnis: AA, AAA und APCA — der vollständige Guide für 2026

Sie shippen einen Button. Markenorange, weißer Text, sieht auf Ihrem 4K-Monitor gestochen scharf aus. Dann kommt das Accessibility-Audit rot zurück: Das WCAG-Kontrastverhältnis liegt bei 1.97:1, weit unter dem AA-Schwellenwert von 4.5:1 für Fließtext. Der Button, der für Sie tadellos aussah, ist für rund 220 Millionen Menschen mit Sehbeeinträchtigung weltweit unlesbar. Dieser Guide deckt jede Zahl ab, die Sie zur Korrektur brauchen: WCAG-2-Verhältnisse, die AAA-Stufe, den neuen APCA-Lc-Algorithmus, acht Kategorien der Farbfehlsichtigkeit und eine funktionierende JavaScript-Implementierung, die Sie direkt in Ihren Build einbauen können.

Schnellübersicht: WCAG- und APCA-Schwellenwerte auf einen Blick

Standard	Normaler Text	Großer Text	UI / Icons	Anmerkungen
WCAG AA	≥ 4.5:1	≥ 3:1	≥ 3:1	Rechtliche Basis
WCAG AAA	≥ 7:1	≥ 4.5:1	≥ 3:1	Verstärktes Ziel
APCA Fließtext	Lc 75+	Lc 60+	Lc 45+ (Icons)	Entwurf, perzeptiv

„Großer Text” bedeutet ≥ 18pt regular oder ≥ 14pt fett (≈ 24px und ≈ 18.66px in CSS). „UI” umfasst Formularränder, Fokusringe und jedes grafische Objekt, das ein Nutzer wahrnehmen muss, um die Seite zu bedienen. Logos und rein dekorative Grafiken sind von den Kontrastanforderungen ausgenommen.

Was ist WCAG-Farbkontrast?

Das WCAG-Kontrastverhältnis ist ein numerisches Maß von 1:1 (kein Kontrast) bis 21:1 (Maximum), das die relative Leuchtdichte von Text gegen seinen Hintergrund vergleicht. Die Web Content Accessibility Guidelines verlangen ≥ 4.5:1 (AA) für Fließtext oder ≥ 7:1 (AAA) für die verstärkte Konformität.

Diese eine Zahl treibt weltweit den Großteil aller Accessibility-Audits an. Das W3C veröffentlichte sie 2008 in WCAG 2.0, verfeinerte sie 2018 in 2.1 und 2023 in 2.2, und jede größere Aufsichtsbehörde verweist heute darauf. Die ADA in den USA, der European Accessibility Act (seit Juni 2025 durchsetzbar), Section 508 für US-Bundesbehörden und Kanadas AODA nutzen alle WCAG 2.x AA als ihre faktische Untergrenze.

Warum ist das jenseits der rechtlichen Seite überhaupt relevant? Rund 220 Millionen Menschen weltweit haben eine Sehbeeinträchtigung, sind aber nicht blind. Sie lesen Bildschirme, jedoch nur, wenn der Kontrast zwischen Schrift und Hintergrund hoch genug ist. Etwa 8 % der Männer und 0.5 % der Frauen haben eine Farbsehschwäche. Ältere Leser erleben eine Gelbfärbung der Augenlinse und eine verkleinerte Pupille, was den wahrgenommenen Kontrast nach dem 60. Lebensjahr funktional um 20–30 % senkt. Die Smartphone-Nutzung im Freien verliert weitere 20–40 % durch Blendung. Eine Seite, die auf Ihrem Schreibtisch 4.5:1 erreicht, ist die Untergrenze, ab der all diese Nutzer sie noch lesen können.

Die Menschen, die sich am dringendsten darum kümmern müssen, sind Frontend-Entwickler, die Produktions-UI shippen, Designer, die Markenpaletten festlegen, Accessibility-Spezialisten, die Audits durchführen, und Compliance-Teams, die für die rechtliche Haftung verantwortlich sind. Die Mathematik ist kurz, die Entscheidungen sind es nicht.

WCAG-2.x-Kontrastverhältnis: Mathematik und Schwellenwerte

Das W3C definiert Kontrast in drei kurzen Schritten. Zur Berechnung des WCAG-Kontrastverhältnisses: (1) Wandeln Sie jede Farbe von gammakodiertem sRGB in linear-light-Werte um, (2) berechnen Sie die relative Leuchtdichte mit festen Koeffizienten für die Empfindlichkeit des menschlichen Auges gegenüber Rot, Grün und Blau, und (3) dividieren Sie die beiden Leuchtdichten mit einem kleinen konstanten Offset, um Werte nahe Schwarz abzufangen.

Die Formel für die relative Leuchtdichte aus WCAG 2.1 §1.4.3 lautet:

L = 0.2126 × R_lin + 0.7152 × G_lin + 0.0722 × B_lin

R_lin, G_lin, B_lin sind die linear-light-Kanalwerte, nachdem die sRGB-Gammakurve rückgängig gemacht wurde. Die Gewichtung von 0.7152 auf Grün spiegelt die starke Grünempfindlichkeit des menschlichen Auges wider. Grün ist pro Einheit Lichtenergie rund 7× visuell lauter als Blau.

Die Verhältnisformel lautet:

ratio = (L_lighter + 0.05) / (L_darker + 0.05)

Die +0.05 verhindern eine Division durch null für reines Schwarz (L = 0) und ergeben ein Maximum von (1 + 0.05) / (0 + 0.05) = 21:1 für reines Weiß auf reinem Schwarz. Das Minimum ist 1:1 (identische Farben).

Hier die vollständige Implementierung in rund dreißig Zeilen Vanilla-JavaScript. Keine Abhängigkeiten, läuft überall:

// sRGB-Hex → linear-light-Kanal
function srgbToLinear(channel8bit) {
  const v = channel8bit / 255;
  return v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
}

// "#RRGGBB" → relative Leuchtdichte [0, 1]
function relativeLuminance(hex) {
  const h = hex.replace("#", "");
  const r = parseInt(h.slice(0, 2), 16);
  const g = parseInt(h.slice(2, 4), 16);
  const b = parseInt(h.slice(4, 6), 16);
  return (
    0.2126 * srgbToLinear(r) +
    0.7152 * srgbToLinear(g) +
    0.0722 * srgbToLinear(b)
  );
}

// WCAG-2.x-Kontrastverhältnis zwischen zwei Hex-Farben
function contrastRatio(hexA, hexB) {
  const lA = relativeLuminance(hexA);
  const lB = relativeLuminance(hexB);
  const [lighter, darker] = lA > lB ? [lA, lB] : [lB, lA];
  return (lighter + 0.05) / (darker + 0.05);
}

// Beispiel: dunkles Slate als Fließtext auf Weiß
console.log(contrastRatio("#475569", "#ffffff").toFixed(2));
// → "7.58" — komfortabel über AA 4.5:1 und knapp über AAA 7:1

Setzen Sie zwei Hex-Codes in den Farbkonverter ein und Sie erhalten dieselben Zahlen zurück, gerendert neben einem APCA-Lc-Wert, einer Gamut-Klassifikation und einer Acht-Kanal-CVD-Vorschau. Die Schwellenwerte selbst sind konkret:

Element	AA min	AAA min	Anmerkungen
Normaler Fließtext	4.5:1	7:1	Unter 18pt regular / unter 14pt fett
Großer Text	3:1	4.5:1	≥ 18pt regular ODER ≥ 14pt fett
UI-Komponenten / Icons	3:1	—	WCAG 2.1 §1.4.11, 2018 ergänzt
Logos & Dekoration	befreit	befreit	Keine Kontrastanforderung

Die CSS-Einheitenumrechnung bringt viele Teams durcheinander. 18pt = 24px bei der Browser-Standardeinstellung, 14pt = 18.66px. Ein 16px-Fließtext (der moderne Standard) liegt unter der Schwelle für „großen Text” und fällt damit unter die strengere 4.5:1-AA-Regel. Eine 20px-Überschrift mit font-weight: 700 qualifiziert als groß und bekommt die lockere 3:1.

Eine Feinheit, die Teams oft kalt erwischt: WCAGs Ausnahme für „großen Text” bezieht sich auf die Lesbarkeit in der gerenderten Größe, nicht auf Heading-Semantik. Ein 14px-<h2> ist kein großer Text und braucht weiterhin 4.5:1. Ein 24px-Absatz Marketingtext ist großer Text und erhält die 3:1-Untergrenze. Die Regel hängt an der gerenderten Pixelgröße und Schriftstärke, niemals am Tag-Namen. Auditoren markieren solche Mismatches; Ihr CSS ist die Quelle der Wahrheit, nicht Ihre HTML-Semantik.

Die Konstante +0.05 in der Verhältnisformel hat einen konkreten Ursprung: Sie steht für den Flare-Term, das von der Bildschirmoberfläche reflektierte Umgebungslicht, das die scheinbare Leuchtdichte von reinem Schwarz auf eine minimale Untergrenze anhebt. Ohne ihn würde ein OLED-Pixel mit echtem Schwarz gegen reines Weiß eine Division durch null ergeben. Mit ihm liegt das maximal erreichbare Verhältnis bei 21:1, eine Zahl, die in jedem Accessibility-Tool auftaucht. Es gibt keinen physischen Bildschirm, der bei Berücksichtigung des Flares mehr als 21:1 liefern kann, weshalb die WCAG-Skala dort endet.

AA gegen AAA: Welches Ziel sollten Sie ansetzen?

AA ist die rechtliche Untergrenze; AAA ist die anspruchsvolle Stufe. Die meisten kommerziellen Sites zielen auf AA, weil AAA Markenfarben Richtung Graustufen zwingt, was die meisten Marketing-Teams ablehnen. Die Entscheidung lautet nicht „mehr ist besser”, sondern ist ein Tradeoff zwischen Nutzerreichweite und Markenausdruck.

Kontext	Empfohlene Stufe	Warum
Allgemeine kommerzielle Site	AA	ADA-/EAA-Compliance-Basis; Gerichte zitieren WCAG 2 AA
Behörden / öffentliche Dienste	AAA	Section 508 und EU-Pendants empfehlen AAA
Gesundheitswesen / Bildung	AAA	Zielgruppe mit höherem Accessibility-Bedarf
Internes Dashboard	AA	Bekanntes Publikum, ROI-Tradeoff vertretbar
Marketing-Landingpage	AA + Marken-Ausnahme	Markenfarben in Hero/CTAs erlaubt, Body bleibt AA

Die versteckten Kosten von AAA zeigen sich, sobald Sie versuchen, ein gesättigtes Markenorange gegen Weiß 7:1 erreichen zu lassen. Geht nicht. Entweder dunkeln Sie das Orange so weit ab, bis es nicht mehr Ihre Marke ist, oder Sie akzeptieren AA und setzen das Orange auf dunkle Hintergründe, wo es AAA mühelos schafft. Viele Unternehmen, auch solche mit hohem Accessibility-Bewusstsein, zielen explizit auf AA bei Body-Inhalten und schieben nur kritische Texte wie Fehlermeldungen oder rechtliche Hinweise auf AAA.

Die Regulierer haben nicht auf die Verbreitung von AAA gewartet. Die Web-Accessibility-Verordnung der ADA von 2024 nennt WCAG 2.1 AA. Der European Accessibility Act, seit Juni 2025 durchsetzbar, fordert WCAG 2.1 AA für die abgedeckten digitalen Dienste. Section 508 in der US-Bundesregierung nutzt WCAG 2.0 AA als Basis (AAA wird empfohlen, wo machbar). Kanadas AODA, das Accessibility-Gesetz von Ontario, verweist auf WCAG 2.0 AA. Das Muster ist konsistent: AA ist die Untergrenze, AAA das Ziel.

APCA: der neue perzeptive Algorithmus

APCA (der Advanced Perceptual Contrast Algorithm, entwickelt von Andrew Somers unter dem Myndex-Label) ist ein Kandidatenalgorithmus für WCAG 3. Er ersetzt WCAG 2s symmetrisches Verhältnis durch einen polaritäts-signierten Lc-Wert von -108 bis +108, bei dem das Vorzeichen die Kontrastrichtung angibt (dunkler Text auf hell vs. heller Text auf dunkel) und der Betrag den wahrgenommenen Kontrast auf einem realen emissiven Display widerspiegelt.

APCA ist relevant, weil WCAG 2s symmetrische Formel zwei Effekte aus der realen Welt verfehlt:

• Polaritäts-Asymmetrie. Heller Text auf dunklem Hintergrund liest sich anders als dunkler Text auf hellem Hintergrund, selbst beim gleichen WCAG-Verhältnis. WCAG 2 liefert für beide Richtungen dieselbe Zahl; APCA nicht.
• Display-Modellierung. WCAG 2s Formel wurde aus Leuchtdichtemodellen für Druckpapier abgeleitet. APCA wurde gegen sRGB-Displays in typischer Bürobeleuchtung kalibriert, was näher an dem liegt, was Ihre Nutzer tatsächlich sehen.

Der Tradeoff: APCA ist komplexer (mit polaritätsbewussten Exponenten und Schriftgewicht-Anpassungen) und noch kein regulatorischer Standard. Adrian Rosellis Analyse vom April 2026 bleibt die klarste Übersicht zum Status von APCA: technisch vielversprechend, aber WCAG 3 selbst steckt noch in der frühen Entwurfsphase des Silver-Tracks, und APCA ist noch nicht als offizieller Algorithmus ratifiziert.

Die APCA-Bronze-Schwellenwerte (die praktische Untergrenze, die die meisten Teams anvisieren) sehen so aus:

Anwendungsfall	Empfohlener Lc	Mindest-Lc
Fließtext (16px, weight 400)	90+	75
Großer Text (24px, weight 400)	75+	60
UI-Elemente & Nicht-Text-Icons	60+	45
Akzenttext / Platzhalter	30+	30

Der Grund, warum APCA spannend ist (und warum der Farbkonverter beide Metriken nebeneinander anzeigt), sind die Fälle, in denen er WCAG 2 widerspricht:

• #FFA500 (Orange) auf #FFFFFF: WCAG 2 liefert 1.97:1, ein klares AA-Fail. APCA stimmt zu mit ungefähr Lc 38, ebenfalls fail. So weit sagen beide Algorithmen Nein, aber die meisten Designer, die ich beobachtet habe, shippen diese Kombination trotzdem, weil „es sieht gut aus”.
• #767676 (Mittelgrau) auf #FFFFFF: WCAG 2 liefert 4.54:1, knapp über AA 4.5:1, technisch ein Pass. APCA bewertet das Paar bei rund Lc 60, unter APCA-Bronzes Schwellenwert von 75 für Fließtext. WCAG passt; APCA fällt durch. Die gelebte Nutzererfahrung liegt näher an APCAs Urteil: Dieses Grau auf Weiß ist bei Fließtextgrößen schwieriger zu lesen, als das Verhältnis vermuten lässt.
• #3b82f6 (Tailwind blue-500) auf #000000: WCAG 2 liefert 5.71:1, ein bequemer AA-Pass. APCA bewertet das mit rund Lc 65, unter dem Lc-75-Minimum für Fließtext. Helles Blau auf dunklem Hintergrund, ein beliebtes Dark-Mode-Muster, ist der kanonische „WCAG passt, APCA meldet”-Fall.

Sie müssen sich nicht für eine Seite entscheiden. Die pragmatische Haltung, auf die sich die meisten Produktionsteams geeinigt haben: Behalten Sie WCAG 2 AA als regulatorische Basis, weil Compliance-Audits danach prüfen, und lassen Sie APCA parallel als „Ist das tatsächlich lesbar?”-Bauchgefühl-Check mitlaufen, besonders bei Dark-Mode-Designs und gesättigten Markenfarben. Der Farbkonverter zeigt beide Zahlen in einer Zeile, damit Sie nicht zwischen Checkern hin- und herwechseln müssen.

Farbenblindheit und mehr als Kontrast

Kontrastverhältnisse sind nur die halbe Miete der Farbzugänglichkeit. Rund 8 % der Männer und 0.5 % der Frauen sehen Farben anders als der lehrbuchhafte Trichromat, und die häufigste Variante, Deuteranomalie, sitzt mitten im Rot-Grün-Paar, das wir überall für Success/Error-States verwenden. WCAG 1.4.1 („Verwendung von Farbe”) verbietet ausdrücklich, dass Farbe alleiniger Träger von Information ist; das ist die Regel, die diese Realität durchsetzen soll.

Die vollständige Taxonomie der Farbsehunterschiede teilt sich in drei Gruppen: Dichromasie (ein Zapfen fehlt), anomale Trichromasie (ein Zapfen verschoben) und die seltenen Monochromasien.

Typ	Geläufige Bezeichnung	Betroffener Kanal	Häufigkeit (M / F)
Protanopie	Rot-blind	L-Zapfen fehlt	1.0% / 0.01%
Deuteranopie	Grün-blind	M-Zapfen fehlt	1.1% / 0.01%
Tritanopie	Blau-blind	S-Zapfen fehlt	0.003% / 0.003%
Protanomalie	Rot-schwach	L-Zapfen verschoben	1.3% / 0.02%
Deuteranomalie	Grün-schwach	M-Zapfen verschoben	5.0% / 0.4%
Tritanomalie	Blau-schwach	S-Zapfen verschoben	0.01% / 0.01%
Achromatopsie	Keine Farbe	Alle Zapfen fehlen	0.003% (sehr selten)
Zapfen-Monochromasie	Teil-Grau	Nur ein Zapfen	0.001%

Deuteranomalie allein betrifft 5 % der Männer, also jeden Zwanzigsten. Das ist die Bevölkerung, die einen roten Fehler-Indikator und einen grünen Erfolgs-Indikator als nahezu denselben olivbraunen Ton wahrnimmt. Die Lösung besteht nicht darin, Ihr Farbsystem zu überarbeiten; sie besteht darin, einen zweiten Kanal hinzuzufügen. Ein rotes Fehler-Icon, gepaart mit einer „ד-Form und dem Wort „Fehler”, überlebt jede Variante in der Tabelle. Ein nackter roter Punkt nicht.

CVD-Simulation im Code nutzt zwei Standardmatrix-Sets: Brettel–Viénot–Mollon (1997) für Dichromasien und Machado–Oliveira–Fernandes (2009) für anomale Trichromasien. Der Brettel-Ansatz projiziert die Eingabefarbe auf eine Ebene, die von den beiden verbleibenden Zapfenantworten aufgespannt wird; Machado parametrisiert die Zapfenverschiebung über die Schwere. Beide lassen sich als SVG-Filter oder CSS-Matrizen umsetzen. Der Farbkonverter liefert alle acht Varianten als Ein-Klick-Vorschauen, sodass Sie eine Markenfarbe über das gesamte Spektrum scannen können, ohne die Seite zu verlassen.

Ein kurzer SVG-Filter (auf die Seite legen und per ID referenzieren) gibt Ihnen eine In-Browser-Protanopie-Simulation für Ad-hoc-Tests:

<svg style="display: none">
  <filter id="protanopia">
    <feColorMatrix type="matrix" values="
      0.567 0.433 0.000 0 0
      0.558 0.442 0.000 0 0
      0.000 0.242 0.758 0 0
      0.000 0.000 0.000 1 0"/>
  </filter>
</svg>

<style>
  .preview-protanopia { filter: url(#protanopia); }
</style>

Wenden Sie .preview-protanopia auf Ihren Seiten-Wrapper an, um zu sehen, was ein Protanope sieht. Wiederholen Sie das mit den Matrizen für Deuteranopie und Tritanopie (deren Koeffizienten sind im Brettel-Paper dokumentiert und in den meisten CVD-Simulator-Bibliotheken enthalten). Das Rendering-Panel der Chrome DevTools hat dieselben Simulatoren unter „Emulate vision deficiencies” eingebaut: nützlich für schnelle Checks, weniger nützlich für Screenshots in CI.

Die tiefere Regel jenseits der Simulation: Lassen Sie Farbe nie der einzige Unterschied zwischen zwei Zuständen sein. Icons sollten sich in der Form unterscheiden (× vs. ✓), Zustände in der Textbeschriftung („Fehler” vs. „Erfolg”), Kategorien im Muster (durchgehend vs. schraffiert). Farbe verstärkt diese anderen Signale, ersetzt sie aber nicht.

Es gibt eine Klasse von Fehlern, die Kontrast-Checker nicht erkennen, CVD-Simulatoren hingegen schon. Tortendiagramm-Segmente, die nur durch Farbton unterschieden werden, Karten-Legenden, die Länder farblich codieren, Status-Pills, die auf einem Grün-Gelb-Rot-Gradient beruhen: sie alle können WCAG-2-Kontrast gegen den Hintergrund schaffen, sind aber für einen Deuteranopen, der sie gegeneinander liest, unleserlich. Die Regel: Prüfen Sie die Lesbarkeit zwischen angrenzenden Farben im Design, nicht nur gegen die umgebende Leinwand. Zwei Slate-500-Segmente nebeneinander mit derselben Helligkeit sind unabhängig von der Farbtonrotation nicht unterscheidbar. Setzen Sie einen Helligkeitsschritt zwischen angrenzende Bereiche, und die Grafik übersteht jede CVD-Variante.

Achromatopsie und Zapfen-Monochromasie sind selten, aber es lohnt sich, explizit für sie zu designen, weil sie alle Farbton-Unterscheidungen kollabieren lassen. Ein Nutzer mit Achromatopsie nimmt nur Leuchtdichte wahr; Ihr farbcodiertes UI sieht für ihn aus wie ein Schwarz-Weiß-Foto. Wenn Ihr Design auch dann hält, wenn Sie filter: grayscale(1) über die gesamte Seite legen (probieren Sie es in den DevTools), haben Sie die strengste Version der Regel „Farbe ist nicht das einzige Signal” bestanden. Es ist der billigste Accessibility-Test, den Sie fahren können, und er deckt eine überraschende Zahl von Fehlern auf, sobald Sie ihn aktivieren.

Tailwind- und Material-Paletten auditieren

Der Großteil der Frontend-Arbeit nutzt eine vorgefertigte Palette: Tailwind v4, Material 3, Radix oder shadcn. Die Accessibility-Frage wird zu „Ab welcher Stufe dieser Rampe wird der Text lesbar?”, und die Antwort ist eher Daumenregel, als die Dokumentation zugibt.

Für Tailwind v4s Slate-Rampe gegen reines Weiß fallen die WCAG- und APCA-Zahlen so aus:

Tailwind-Klasse	Ungefährer Hex	WCAG vs. Weiß	AA Body	AAA Body	APCA Lc (ca.)
slate-400	#94a3b8	2.56:1	✗	✗	~38 ✗
slate-500	#64748b	4.76:1	✓	✗	~60 ✗ Fließtext
slate-600	#475569	7.58:1	✓	✓	~78 ✓ Fließtext
slate-700	#334155	10.35:1	✓	✓	~90 ✓ Fließtext

Die praktischen Regeln, die daraus folgen:

• Fließtext braucht slate-600 oder dunkler. Slate-500 schafft WCAG AA, fällt aber durch APCAs Fließtext-Schwelle: also konform, aber unangenehm. Slate-600 ist die sichere Untergrenze.
• UI-Labels und Sekundärtext können slate-500 nutzen. UI-Komponenten brauchen nur 3:1; die 4.76:1 von slate-500 sind komfortabel, und der Text trägt meist stützenden visuellen Kontext.
• Platzhalter sollten slate-400 oder heller nutzen. Platzhaltertext ist nach WCAG 1.4.3 als dekorativ ausgenommen, aber nur, wenn Sie ein sichtbares Label über dem Feld stehen lassen. Inline-Label-als-Platzhalter-Muster müssen die Fließtext-Schwelle treffen.
• Reines Schwarz auf slate-100 / slate-200 ist verschwendete Tinte. Sie liegen bei 17:1+; ziehen Sie slate-700 oder slate-800 als Textfarbe in Betracht, für ein weicheres Gefühl ohne Verlust an Lesbarkeit.

Material 3 nutzt eine ähnliche tonale Palettenstruktur. Sein surface-container-high liegt bei etwa Ton 92 (sehr hell); sein on-surface bei etwa Ton 10 (fast schwarz). Der Kontrast zwischen einem beliebigen on-surface und einem beliebigen surface-*-Token derselben Familie ist nach Material-Spezifikation garantiert AA-konform. Paaren Sie on-surface-variant (Ton 30) nicht ungeprüft mit surface-container (Ton 94); das ist ein realer Fehler, den ich schon shippen sehen habe.

Wenn Sie eine bestehende Palette haben, die Kontrast verfehlt, gibt Ihnen OKLCH den saubersten Reparaturpfad. Statt Hex-Codes blind zu schubsen, konvertieren Sie Ihre Farbe nach OKLCH, halten C (Chroma) und H (Farbton) fix und reduzieren L (Helligkeit), bis der Kontrast passt. Weil OKLCHs L-Kanal echt perzeptiv ist, bleibt die Markenwiedererkennung intakt, während sich der Kontrast verschärft. Das HEX-zu-OKLCH-Tool erledigt diese Konvertierung in einem Schritt; der Schwesterartikel OKLCH erklärt behandelt die Mathematik in der Tiefe.

Der Dark Mode verdient einen eigenen Absatz. WCAG 2s symmetrisches Verhältnis bewertet dieselben Kombinationen im Light- und Dark-Mode definitionsgemäß gleich. APCA, polaritätsbewusst, meldet Dark-Mode-Fließtext häufig als schwerer lesbar als das gleiche Hex-Paar im Light-Mode. Hell-auf-Dunkel verliert beim gleichen numerischen Verhältnis stets etwas wahrgenommenen Kontrast gegenüber Dunkel-auf-Hell, ein bekannter Effekt der Augenadaption. Lassen Sie APCA über jedes Dark-Mode-Paar laufen, bevor Sie shippen.

Kontrast-Checker und CI-Workflows

Designer und Entwickler haben jeweils ihren Lieblings-Checker; die praktische Frage ist, welche Tool-Kombination Sie in einen echten Workflow nähen. So sieht das Feld 2026 aus:

Tool	WCAG 2	APCA	CVD-Sim	Paletten-Audit
WebAIM Contrast Checker	✓	✗	✗	✗
Adobe Color	✓	✗	✓	✓
Stark (Figma-Plugin)	✓	✓	✓	✓
Polypane (Browser)	✓	✓	✓	✓
Chrome DevTools Farbpicker	✓	✓ (exp.)	✗	✗
axe DevTools	✓	✗	✗	✓ (seitenweit)
Go Tools Farbkonverter	✓	✓	✓ (8 Typen)	✓ (Tints/Shades)

Ein Workflow, der unter realem Produktdruck hält, sieht so aus:

1. In Figma lassen Designer Stark über jeden Frame laufen, um fehlende Paare früh aufzudecken. Stark fängt die offensichtlichen Übeltäter ab, bevor irgendein Hex-Code in den Code gelangt.
2. Bei der Hex-Code-Übergabe kopieren Entwickler den Wert in den Farbkonverter und erhalten WCAG-Verhältnis + APCA Lc + Gamut-Klassifikation + CVD-Vorschau in einer Zeile. Handelt es sich um Dark-Mode oder eine gesättigte Markenfarbe, fängt die Doppelmetrik die WCAG-passt-APCA-fällt-durch-Fälle ab, die Stark übersehen könnte.
3. Beim PR scannt axe-core/playwright die gebauten Seiten auf jeden Kontrastverstoß im gerenderten DOM, inklusive dynamischer Zustände. Das fängt Fokusringe, Hover-Zustände und Disabled-Affordances ab, die statische Designdateien übersehen.
4. In der QA simuliert das Rendering-Tab der Chrome DevTools Protanopie/Deuteranopie/Tritanopie für Stichproben auf kritischen Flows. Der Color Picker in den DevTools liefert beim Hover über ein Element zusätzlich ein inline WCAG-Verhältnis.

Pa11y, Lighthouse CI und @axe-core/playwright bieten Kontrast-Assertions als Teil ihrer breiteren Accessibility-Audits an. Keiner prüft heute APCA; alle prüfen WCAG 2. Der realistische Kompromiss lautet „WCAG 2 AA in CI durchsetzen, APCA Lc für Markenfarben und Dark Mode manuell als Sanity-Check fahren”.

Ein Muster, das es sich von größeren Design-System-Teams abzuschauen lohnt: Bauen Sie den Kontrast-Check in Ihren Token-Validierungsschritt ein, nicht nur in seitenweite QA. Wenn Ihre Design-Tokens aus einer Quelldatei kompilieren (JSON, YAML oder ein TypeScript-Modul), fügen Sie ein Skript hinzu, das jede vom System erlaubte --text-* × --surface-*-Paarung enumeriert und ein WCAG-Mindestverhältnis assertet. Das Skript läuft in Millisekunden, fängt Regressionen ab, wenn jemand einen Token-Wert anpasst, und erzeugt eine Kontrastmatrix, die zugleich als Dokumentation für das Designteam dient. Der Check ist unabhängig von jeder gerenderten Seite; er arbeitet rein auf den Tokens, fängt den Fehler also ab, bevor irgendein UI shippt.

Für Ad-hoc-Konvertierungen in diesem Workflow (Umrechnungen zwischen Hex, RGB, HSL und OKLCH beim Debuggen) decken die Spokes HEX zu RGB, HEX zu HSL, HEX zu OKLCH und RGB zu HEX die Hin- und Rückwege in jedes Farbformat ab, das Ihre Toolchain erwartet.

Häufige Fehler und wie man sie repariert

Nach Jahren von Accessibility-Audits tauchen dieselben sechs Fehler immer wieder auf. Jeder hat einen sauberen Fix:

1. Platzhaltertext in Hellgrau. #999999 auf Weiß ist 2.85:1 (AA-Fail). Entweder dunkler bis #666666 (5.74:1, AA-konform) oder, besser, Platzhalter-als-Label-Muster durch ein dauerhaft sichtbares Label über dem Feld ersetzen. Platzhalter dürfen keine Information tragen.

2. Markenorange-Button mit weißem Text. #FFA500 auf Weiß ist 1.97:1 (heftiger AA-Fail). Der markenwahrende Fix kehrt die Kontrastrichtung um: dunkler Text (z. B. #451a03) auf orangenem Hintergrund, oder weißen Text behalten und den Button auf ein tiefes, gesättigtes Braunorange abdunkeln. Vor dem Shippen im Farbkonverter prüfen.

3. Helles blaues Link im Dark Mode. #3b82f6 auf #000000 ist 5.71:1 (WCAG-AA-Pass), aber APCA Lc ~65, unter der Lc-75-Fließtext-Schwelle. Greifen Sie zu OKLCH und schieben Sie L von ≈ 0.63 auf 0.75 bei festem C und H; Sie landen nahe #7aa5f8 mit einem komfortablen APCA Lc 80+ und demselben Farbton.

4. Deaktivierter Text in #CCCCCC. 1.61:1 gegen Weiß. WCAG 1.4.3 nimmt rein dekorativen Text von der Verhältnis-Regel aus, aber deaktivierte UI-Controls sind nicht dekorativ; sie kommunizieren „derzeit nicht verfügbar”. Koppeln Sie den gedämpften Ton an einen Nicht-Farb-Hinweis (Durchstreichung, Schloss-Icon, „Deaktiviert”-Tooltip), damit auch ein CVD- oder Sehbeeinträchtigter-Nutzer den Zustand versteht.

5. Status-Icons, die sich nur im Farbton unterscheiden. Ein rotes × und ein grünes ✓ sind okay, weil die Form sie schon unterscheidet. Ein roter Punkt gegen einen grünen Punkt nicht. Form und Farbe zusammen nutzen; die CVD-Vorschau im Farbkonverter macht den Fehlerfall in einer Sekunde sichtbar.

6. Text über Gradient-Hintergrund. Ein Gradient von #3b82f6 zu #a78bfa schafft den Kontrast gegen weißen Text in der Mitte und fällt am Lavendel-Ende durch. Der Fix: Kontrast gegen den schlechtesten Punkt des Gradients erzwingen oder einen halbtransparenten dunklen Scrim drüberlegen, damit die effektive Hintergrundleuchtdichte stets unter einer bekannten Schwelle bleibt.

Jeder Fix dauert Minuten. Der Audit-Zyklus, den er vermeidet, dauert Wochen.

FAQ

Was ist das WCAG-AA-Kontrastverhältnis?

WCAG AA fordert ≥ 4.5:1 zwischen Fließtext und Hintergrund oder ≥ 3:1 für großen Text (≥ 18pt regular oder ≥ 14pt fett) und UI-Komponenten wie Formularränder. AA ist die rechtliche Basis unter ADA, EAA und Section 508. Die meisten kommerziellen Sites zielen auf AA, weil es die regulatorische Hürde nimmt, ohne Markenfarben Richtung Graustufen zu zwingen.

Welches Kontrastverhältnis brauche ich für AAA?

WCAG AAA fordert ≥ 7:1 für normalen Fließtext und ≥ 4.5:1 für großen Text. AAA wird für medizinische, Bildungs- und Behörden-Sites empfohlen, deren Zielgruppe einen höheren Accessibility-Bedarf hat. Markenfarben müssen oft Richtung graustufennaher Werte abgeflacht werden, um AAA zu passieren; das ist der Grund, warum viele kommerzielle Produkte bei AA stehen bleiben.

Was ist APCA und ist es WCAG 3.0?

APCA (Advanced Perceptual Contrast Algorithm), entwickelt von Andrew Somers / Myndex, ist ein Kandidatenalgorithmus im WCAG-3-Silver-Projekt. Er verwendet polaritäts-sensitive Lc-Werte von -108 bis +108 statt symmetrischer Verhältnisse. Stand 2026 ist WCAG 3 noch im frühen Entwurf und APCA wurde nicht formell ratifiziert; WCAG 2.1 / 2.2 AA bleibt der regulatorische Standard, den Sie heute treffen müssen.

Hilft Dark Mode der Kontrast-Accessibility?

Manchmal, aber nicht automatisch. WCAG 2s symmetrisches Verhältnis bewertet dieselben Kombinationen im Light- und Dark-Mode gleich, aber APCA (polaritäts-sensitiv) meldet Dark-Mode-Fließtext oft als schwerer lesbar als dasselbe Hex-Paar im Light-Mode. Testen Sie Dark Mode immer gegen beide, WCAG und APCA, bevor Sie shippen; Hell-auf-Dunkel verliert wahrgenommenen Kontrast auf Weisen, die das symmetrische Verhältnis nicht sehen kann.

Warum schafft meine Markenfarbe WCAG AA nicht?

Gesättigte Farben mit mittlerer Leuchtdichte (die meisten Orangetöne, Gelbtöne, Limonengrüns, Hellblaus) haben relative Leuchtdichten zu nah an Weiß, um 4.5:1 zu schaffen. Der Fix: Markenton für Akzente und große Überschriften behalten, aber Fließtext mit einem dunkleren Ton aus derselben Farbfamilie kombinieren. Nutzen Sie OKLCH, um den L-Kanal zu senken, ohne den Farbton zu verschieben; der Farbkonverter findet den nächstgelegenen bestehenden Ton in einem Schritt.

Sind WCAG-2-Verhältnisse und APCA-Werte kompatibel?

Nein. WCAG 2 liefert ein symmetrisches Verhältnis (1–21); APCA liefert einen polaritäts-signierten Lc-Wert (-108 bis +108). Die Beziehung ist nicht-linear: Ein Paar, das in WCAG 4.5:1 ergibt, kann in APCA Lc 60 oder Lc 75 erreichen, abhängig davon, welche Farbe oben liegt. Behandeln Sie sie als zwei unabhängige Checks, nicht als Übersetzungen voneinander.

Kann ich Farbkontrast für kleine UI-Icons nutzen?

Ja, mit Einschränkungen. WCAG 2.1 §1.4.11 fordert ≥ 3:1 für UI-Komponenten und grafische Objekte. Für dekorative Icons mit sichtbarem Textlabel lockern sich die Kontrastanforderungen, weil das Label die Bedeutung trägt. Für stand-alone-Icons (z. B. eine Such-Lupe ohne Label) setzen Sie die vollen 3:1 gegen den umgebenden Hintergrund durch.

Wie teste ich Farbenblindheit ohne Simulation?

Nutzen Sie Chrome DevTools → Rendering → „Emulate vision deficiencies” für Protanopie, Deuteranopie, Tritanopie und Achromatopsie. Kombinieren Sie das mit der Acht-Typen-CVD-Vorschau im Farbkonverter für die Varianten der anomalen Trichromasie (Deuteranomalie ist die häufigste mit 5 % der Männer). Für Audit-Berichte nehmen Sie Screenshots unter jeder Simulation auf, damit Reviewer die Fehlermodi inline sehen.

Fazit

Fünf Punkte tragen den gesamten Guide:

• AA 4.5:1 ist die rechtliche Untergrenze. Treffen Sie sie für jeden Fließtext oder rechnen Sie mit Compliance-Lärm.
• AAA 7:1 ist für Gesundheitswesen, Bildung und Behörden. Die meisten kommerziellen Marken stoppen bewusst bei AA.
• APCA Lc ist der echte Lesbarkeits-Sanity-Check. Lassen Sie es parallel zu WCAG 2 laufen, vor allem für Dark Mode und gesättigte Markenfarben.
• Farbe ist niemals das einzige Signal. Koppeln Sie jeden Farbhinweis an Form, Text oder Muster; Deuteranomalie allein betrifft 5 % der männlichen Nutzer.
• OKLCH L ist der richtige Hebel. Wenn eine Farbe den Kontrast verfehlt, senken Sie L (nicht S, nicht B), um sie zu reparieren, ohne den Farbton zu verschieben.

Setzen Sie zwei beliebige Hex-Codes in den Farbkonverter, um WCAG-Verhältnis, APCA Lc, Gamut-Klassifikation und die Acht-Typen-CVD-Vorschau nebeneinander zu sehen. Diese eine Ansicht ersetzt sechs separate Tools und ist der schnellste Weg, die Audits abzuschließen, die dieser Guide beschreibt.