WCAG 1.4.11: Nicht-Text-Kontrast

WCAG 1.4.11 verlangt, dass Benutzeroberflächenkomponenten und grafische Objekte ein Kontrastverhältnis von mindestens 3:1 zu angrenzenden Farben aufweisen, damit Menschen mit Sehbeeinträchtigungen interaktive Steuerelemente, Fokusindikatoren und bedeutungsvolle Grafiken ohne unterstützende Technologien wahrnehmen können.

Was diese Regel bedeutet

WCAG 1.4.11 Non-text Contrast ist ein Kriterium der Stufe AA, das in WCAG 2.1 eingeführt und in WCAG 2.2 fortgeführt wurde. Es schreibt ein minimales Kontrastverhältnis von 3:1 zwischen der visuellen Darstellung der folgenden zwei Inhaltskategorien und ihren angrenzenden Farben vor:

Benutzeroberflächen‑ (UI‑) Komponenten: Die visuellen Begrenzungen oder Indikatoren, die interaktive Steuerelemente wie Texteingabefelder, Kontrollkästchen, Optionsfelder, Kippschalter, Dropdown‑Menüs und Schaltflächen kennzeichnen. Dies umfasst sowohl die Komponente selbst als auch alle visuellen Zustandsänderungen (z. B. Hover, Fokus, ausgewählt, Fehler).
Grafische Objekte: Teile von Symbolen, Diagrammen, Schaubildern und anderen bedeutungstragenden Bildern, die zum Verständnis des Inhalts erforderlich sind. Jeder Teil der Grafik, der Informationen vermittelt, muss die 3:1‑Schwelle gegenüber seiner umgebenden Farbe erfüllen.

Das Kontrastverhältnis wird zwischen dem Vordergrundelement und der unmittelbar angrenzenden Farbe gemessen – typischerweise seiner Hintergrundfarbe, Rahmenfarbe oder einem benachbarten Segment eines Diagramms. Die Berechnung verwendet dieselbe Formel für relative Leuchtdichte, die in WCAG 1.4.3 definiert ist, aber die Schwelle liegt bei 3:1 statt 4,5:1, weil nicht‑textliche Elemente mit etwas geringerem Kontrast dennoch erkennbar bleiben können.

Ein Pass bedeutet, dass jeder visuelle Indikator, der eine UI‑Komponente identifiziert oder Informationen in einer Grafik vermittelt, mindestens ein Verhältnis von 3:1 erreicht. Ein Fail tritt auf, wenn ein Rahmen, eine Symbolkontur, ein Diagrammsegment oder ein Zustandsindikator unter dieses Verhältnis fällt und die Komponente oder Grafik ohne diese visuellen Informationen nicht identifiziert oder verstanden werden kann.

Die WCAG‑Spezifikation definiert mehrere wichtige Ausnahmen:

Inaktive Komponenten: UI‑Komponenten, die deaktiviert und nicht für Interaktion verfügbar sind, sind ausgenommen. Eine ausgegraute Schaltfläche, die nicht angeklickt werden kann, muss die Kontrastanforderung nicht erfüllen.
Darstellung, die vom User Agent gesteuert wird: Komponenten, deren visuelle Darstellung vollständig durch das Standard‑Styling des Browsers (nicht durch Autor‑CSS überschrieben) gesteuert wird, sind ausgenommen, da die Verantwortung beim Browser‑Hersteller liegt.
Wesentliche oder dekorative Grafiken: Grafische Objekte, bei denen die konkrete Darstellung für die zu vermittelnde Information wesentlich ist (z. B. Nationalflaggen, die Länder repräsentieren) oder die rein dekorativ sind, sind ausgenommen. Logos sind im Allgemeinen ebenfalls unter diese Klausel fallend ausgenommen.
Text: Text und Bilder von Text werden bereits durch 1.4.3 und 1.4.6 abgedeckt und fallen nicht unter 1.4.11.

Fokusindikatoren verdienen in WCAG 2.2 besondere Aufmerksamkeit. Kriterium 2.4.11 (Focus Appearance) fügt strengere Anforderungen an die Sichtbarkeit des Fokus hinzu, aber 1.4.11 gilt weiterhin für den Kontrast eines benutzerdefinierten Fokusrings gegenüber seinem Hintergrund. Ein benutzerdefiniertes outline oder ein Box‑Shadow, der als Fokusindikator verwendet wird, muss gegenüber der angrenzenden Farbe ein Verhältnis von 3:1 erreichen, um dieses Kriterium unabhängig zu erfüllen.

Warum es wichtig ist

Laut Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen irgendeine Form von Sehbeeinträchtigung. Ein erheblicher Anteil dieser Personen – einschließlich der geschätzten 253 Millionen Menschen mit moderatem bis schwerem Sehverlust – ist auf ausreichenden Kontrast angewiesen, um digitale Oberflächen wahrzunehmen und mit ihnen zu interagieren, ohne zwingend einen Screenreader zu verwenden. Nutzer mit Sehbehinderung, die mit Vergrößerungssoftware, Hochkontrastmodi oder einfach unter schwierigen Lichtverhältnissen surfen, gehören zu denjenigen, die von Verstößen gegen 1.4.11 am unmittelbarsten betroffen sind.

Betrachten Sie ein praktisches Szenario: Eine Nutzerin mit Glaukom füllt ein Schadensformular auf der Website eines Krankenhauses aus. Die Formularfelder verwenden einen hellgrauen Rahmen (#cccccc) auf weißem Hintergrund (#ffffff), was ein Kontrastverhältnis von nur 1,6:1 ergibt – weit unter dem erforderlichen 3:1. Die Nutzerin kann nicht erkennen, wo die Eingabefelder beginnen und enden, sodass sie nicht zuverlässig hineinklicken oder die Struktur des Formulars verstehen kann. Sie bricht das Formular vollständig ab, was sowohl persönliche Kosten als auch eine rechtliche Haftung für die Institution nach sich zieht.

Über Sehbeeinträchtigungen hinaus können auch kognitive Beeinträchtigungen dazu führen, dass UI‑Komponenten mit geringem Kontrast schwerer zu interpretieren sind. Nutzer mit Aufmerksamkeitsstörungen oder Verarbeitungsproblemen sind auf eine starke visuelle Unterscheidung zwischen interaktiven und nicht interaktiven Elementen angewiesen, um die Seitenstruktur schnell zu erfassen. Ebenso müssen Nutzer mit Tremor oder motorischen Beeinträchtigungen, die große Zeigerziele verwenden, die Begrenzungen von Steuerelementen klar sehen können, um präzise zielen zu können.

Aus geschäftlicher Perspektive verbessert die Erfüllung von 1.4.11 die Nutzbarkeit für alle Nutzer unter suboptimalen Bedingungen – grelles Sonnenlicht auf einem Mobilbildschirm, minderwertige Monitore oder ältere Displays mit schlechter Farbgenauigkeit. Sie reduziert Supportkosten, erweitert die Reichweite des Publikums und stärkt die SEO indirekt, indem sie Absprungraten senkt, die mit schlechter Usability zusammenhängen. Für Organisationen, die gesetzlichen Barrierefreiheitsvorgaben unterliegen, stellt ein Verstoß gegen dieses Kriterium auf Stufe AA ein direktes Compliance‑Risiko dar.

Wie man testet

Automatisierten Scan mit axe DevTools oder Lighthouse ausführen: Installieren Sie die Browser‑Erweiterung axe DevTools und führen Sie einen Scan der gesamten Seite aus. Filtern Sie im Ergebnisbereich nach Problemen, die mit WCAG 1.4.11 gekennzeichnet sind, oder prüfen Sie alle color-contrast-Verstöße. Notieren Sie alle Einträge, die in der Kategorie Non‑Text‑Kontrast als Needs Review markiert sind – diese erfordern eine manuelle Nachprüfung. Führen Sie in Lighthouse (Chrome DevTools > Tab Lighthouse) ein Accessibility‑Audit durch und prüfen Sie die kontrastbezogenen Ergebnisse, wobei Sie berücksichtigen, dass die Abdeckung von Lighthouse für nicht‑textliche Elemente ebenfalls nur teilweise ist.
Manuelle Prüfung mit einem Farbkontrast‑Analysetool: Laden Sie die Desktop‑Anwendung TPGi Colour Contrast Analyser herunter und öffnen Sie sie. Verwenden Sie das Pipetten‑Werkzeug, um die Vordergrundfarbe jeder UI‑Komponentenbegrenzung zu entnehmen (z. B. den Rahmen eines Texteingabefelds, die Kontur eines Symbols, die Füllung eines Balkens in einem Diagramm) und entnehmen Sie anschließend die angrenzende Hintergrundfarbe. Das Tool zeigt das berechnete Kontrastverhältnis an. Jedes Verhältnis unter 3:1 ist ein Fehler. Arbeiten Sie systematisch alle interaktiven Formularelemente, Schaltflächen nur mit Symbol, Fokusindikatoren und Datenvisualisierungen durch.
Tastaturnavigation und Fokusindikator‑Test: Navigieren Sie mit der Tab‑Taste über die gesamte Seite, ausschließlich mit der Tastatur. Prüfen Sie bei jedem interaktiven Element, das den Fokus erhält, ob der Fokusindikator (Ring, Umrandung oder Hintergrundänderung) sichtbar ist. Verwenden Sie den Kontrast‑Analyser, um zu bestätigen, dass die Farbe des Fokusindikators gegenüber dem Hintergrund des Elements ein Verhältnis von 3:1 erreicht. Testen Sie mit NVDA + Firefox und JAWS + Chrome, um zu bestätigen, dass das Element den Fokus in der erwarteten Reihenfolge erhält und dass der visuelle Indikator nicht durch CSS outline: none ohne gleichwertigen Ersatz unterdrückt wird.
Test in Hochkontrast‑ und Forced‑Color‑Modi: Aktivieren Sie unter Windows den Hochkontrastmodus (Einstellungen > Erleichterte Bedienung > Hoher Kontrast) und laden Sie die Seite neu. Aktivieren Sie in Chromium‑basierten Browsern in den DevTools unter Rendering die Option Emulate CSS media feature forced-colors: active. Vergewissern Sie sich, dass die Begrenzungen der UI‑Komponenten sichtbar bleiben. Auch wenn die Einhaltung des Forced‑Color‑Modus nicht strikt von 1.4.11 gefordert wird, deckt das Testen in diesem Modus Elemente auf, die sich ausschließlich auf Hinweise mit geringem Farbkontrast stützen.
Grafische Objekte im Kontext prüfen: Identifizieren Sie für jedes Diagramm, Symbol, Schaubild oder Informationsbild jedes Segment oder jeden Pfad, der Bedeutung vermittelt. Verwenden Sie das Pipetten‑Werkzeug, um angrenzende Farben innerhalb der Grafik selbst zu entnehmen (z. B. zwei benachbarte Segmente eines Kreisdiagramms) und gegenüber dem umgebenden Seitenhintergrund. Jeder einzelne Teil, der Informationen vermittelt, muss für sich genommen 3:1 erreichen.
Alle Komponenten‑Zustände prüfen: Interaktive Elemente haben mehrere Zustände – Standard, Hover, Fokus, aktiv, ausgewählt, markiert, Fehler und Erfolg. Testen Sie jeden Zustand separat. Ein Schaltflächenrahmen, der im Standardzustand besteht, kann im Hover‑Zustand durch eine Farbänderung auf eine Variante mit geringem Kontrast durchfallen.

Wie man es behebt

Formulareingaberahmen – falsch

<!-- Fails: light grey border (#cccccc) on white (#ffffff) = 1.6:1 ratio -->
<style>
  .form-input {
    border: 1px solid #cccccc;
    background-color: #ffffff;
    padding: 8px 12px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

Formulareingaberahmen – korrekt

<!-- Passes: darker border (#767676) on white (#ffffff) = 4.54:1 ratio, exceeds 3:1 -->
<style>
  .form-input {
    border: 1px solid #767676; /* Darkened to achieve sufficient contrast */
    background-color: #ffffff;
    padding: 8px 12px;
  }
  .form-input:focus {
    outline: 3px solid #005fcc; /* Focus ring at 5.9:1 against white */
    outline-offset: 2px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

Schaltfläche nur mit Symbol – falsch

<!-- Fails: light grey icon (#aaaaaa) on white (#ffffff) = 2.32:1 ratio -->
<style>
  .icon-btn { background: none; border: none; color: #aaaaaa; }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

Schaltfläche nur mit Symbol – korrekt

<!-- Passes: dark icon (#595959) on white (#ffffff) = 7:1 ratio, well above 3:1 -->
<style>
  .icon-btn { background: none; border: none; color: #595959; cursor: pointer; }
  .icon-btn:focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
    border-radius: 4px;
  }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <!-- Darker stroke ensures the icon shape is perceivable -->
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

Benutzerdefiniertes Kontrollkästchen – falsch

<!-- Fails: custom checkbox uses a light border (#d0d0d0) on white background -->
<style>
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #d0d0d0; /* 1.3:1 ratio against white — fails */
    border-radius: 3px;
    display: inline-block;
  }
</style>
<label>
  <input type='checkbox' style='position:absolute;opacity:0;width:0;height:0' />
  <span class='custom-checkbox-box'></span>
  I agree to the terms
</label>

Benutzerdefiniertes Kontrollkästchen – korrekt

<!-- Passes: border (#5a5a5a) on white = 7.2:1. Checked state tick also uses sufficient contrast -->
<style>
  .custom-checkbox-input {
    position: absolute; opacity: 0; width: 0; height: 0;
  }
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #5a5a5a; /* Sufficient contrast against white background */
    border-radius: 3px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    background-color: #ffffff;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box {
    background-color: #005fcc; /* Blue fill on checked */
    border-color: #005fcc;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box::after {
    content: '';
    display: block;
    width: 10px; height: 6px;
    border-left: 2px solid #ffffff; /* White tick on blue = 5.9:1 */
    border-bottom: 2px solid #ffffff;
    transform: rotate(-45deg) translateY(-2px);
  }
  .custom-checkbox-input:focus-visible + .custom-checkbox-box {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>
<label class='custom-label'>
  <input type='checkbox' class='custom-checkbox-input' />
  <span class='custom-checkbox-box' aria-hidden='true'></span>
  I agree to the terms
</label>

Daten‑Diagramm – falsch

<!-- Fails: two adjacent pie chart segments use similar light hues with <3:1 contrast -->
<svg viewBox='0 0 200 200' aria-label='Market share chart' role='img'>
  <!-- Segment A: #f5c6cb (light pink) adjacent to Segment B: #ffeeba (light yellow) -->
  <!-- Contrast ratio between these two colors is approximately 1.1:1 — fails -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#f5c6cb' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#ffeeba' />
</svg>

Daten‑Diagramm – korrekt

<!-- Passes: use high-contrast segment fills OR add a visible border between segments -->
<svg viewBox='0 0 200 200' aria-label='Market share chart: Segment A 50%, Segment B 25%' role='img'>
  <!-- Option 1: Use a dark stroke between segments to separate them at 3:1 against both fills -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#d63384' stroke='#ffffff' stroke-width='2' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#0d6efd' stroke='#ffffff' stroke-width='2' />
  <!-- The white (#ffffff) stroke separates the two segments; each fill also has 3:1 against white bg -->
</svg>

Häufige Fehler

Verwendung eines einpixeligen Rahmens, der 3:1 erfüllt, aber bei niedriger DPI unsichtbar wird: Selbst eine konforme Farbe kann unmerklich werden, wenn der Rahmen auf einem Bildschirm mit niedriger Auflösung nur 1px breit ist. Verwenden Sie border: 2px solid oder einen sichtbaren Box‑Shadow zusammen mit einer konformen Farbe, um sicherzustellen, dass die Begrenzung physisch wahrnehmbar ist.
Die Annahme, dass der Hintergrund immer weiß ist: Wenn ein Formularfeld oder Symbol innerhalb einer Karte oder Seitenleiste mit einem hellgrauen Hintergrund (#f5f5f5) erscheint, muss der Kontrast gegen dieses Grau gemessen werden, nicht gegen Weiß. Ein Rahmen, der auf Weiß besteht, kann auf einem getönten Hintergrund durchfallen.
Entfernen der Standard‑Fokusumrandung mit outline: none ohne gleichwertigen Ersatz: Dies ist einer der häufigsten Verstöße gegen 1.4.11. Die globale Einstellung :focus { outline: none; } zerstört die Fokus‑Sichtbarkeit für Tastaturnutzer. Ersetzen Sie sie immer durch einen benutzerdefinierten Fokusstil, der mindestens 3:1 Kontrast gegenüber seinem Hintergrund erreicht.
Den deaktivierten Zustand als Ausrede nutzen, um alle Kontrastprüfungen zu überspringen: Deaktivierte Komponenten sind ausgenommen, aber Entwickler kennzeichnen Elemente manchmal visuell als deaktiviert durch Styling mit geringem Kontrast, ohne tatsächlich das Attribut disabled oder aria-disabled='true' zu setzen. Ein Element, das deaktiviert aussieht, aber weiterhin interaktiv ist, muss weiterhin 1.4.11 erfüllen.
Sich ausschließlich auf Farbe verlassen, um Diagrammsegmente ohne trennende Kontur zu unterscheiden: Zwei benachbarte Diagrammsegmente, bei denen der einzige Unterschied der Farbton ist (z. B. hellblau vs. hellgrün), können durchfallen, wenn ihr Kontrastverhältnis unter 3:1 liegt. Das Hinzufügen einer 2px breiten weißen oder dunklen Trennkontur zwischen den Segmenten ist eine zuverlässige Lösung.
Kontrastkorrekturen nur auf den Standardzustand anwenden und Hover‑, Fokus‑, Fehler‑ und Erfolgszustände vergessen: Jeder interaktive Zustand hat seine eigene visuelle Darstellung. Ein Schaltflächenrahmen, der im Standardzustand besteht, kann im Hover‑Zustand auf eine Farbe mit geringem Kontrast wechseln. Alle Zustände müssen unabhängig getestet werden.
Einbetten von Symbolen als Hintergrundbilder und Verlassen auf CSS‑Farbe für den Kontrast: Inline in HTML eingebettete SVG‑Symbole reagieren auf color und currentColor, aber als CSS‑background-image verwendete Symbole können nicht per CSS umgefärbt werden. Wenn die Symbolbilddatei selbst unzureichenden Kontrast aufweist, kann kein CSS‑Fix das Problem lösen, ohne das Asset zu ersetzen.
Zu übersehen, dass Platzhaltertext in Eingabefeldern nicht unter 1.4.11 fällt, aber dennoch reguliert ist: Platzhaltertext fällt unter 1.4.3 (Textkontrast von 4,5:1), nicht unter 1.4.11. Entwickler wenden manchmal fälschlicherweise die 3:1‑Schwelle auf Platzhaltertext an und erzeugen damit einen separaten, unbemerkten Verstoß gegen 1.4.3.
Verwendung von CSS‑Transitionen, die durch eine nicht konforme Zwischenfarbe animieren: Ein Element kann von einer konformen Farbe über eine nicht konforme Zwischenfarbe zu einer anderen konformen Farbe animieren. Selbst wenn Start‑ und Endzustand bestehen, ist die visuelle Komponente während der Transition technisch nicht konform. Verwenden Sie prefers-reduced-motion-Media‑Queries mit Bedacht und vermeiden Sie Transitionen über Zustände mit geringem Kontrast.
Fortschrittsbalken, Range‑Inputs und Kippschalter zu ignorieren: Diese benutzerdefinierten UI‑Komponenten werden häufig ohne Berücksichtigung von 1.4.11 gestaltet. Der gefüllte Teil eines Fortschrittsbalkens muss 3:1 Kontrast gegenüber seiner Spur haben; der Knopf eines Kippschalters muss sich gegenüber dem Hintergrund des Schalters abheben; der Thumb eines Range‑Inputs muss sich gegenüber der Spur abheben.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung Nr. 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web‑ und mobile Barrierefreiheit für eine breite Palette öffentlicher und privater Einrichtungen fest, die in der Türkei tätig sind. Die Verfügung übernimmt WCAG 2.2 als normative technische Norm, und Konformität auf Stufe AA ist die erforderliche Schwelle für die Einhaltung.

WCAG 1.4.11 Non-text Contrast ist als Kriterium der Stufe AA daher unmittelbar unter der Verfügung durchsetzbar. Organisationen, die der Regelung unterliegen, müssen sicherstellen, dass alle Begrenzungen von UI‑Komponenten, Zustände interaktiver Steuerelemente und bedeutungstragende grafische Objekte auf ihren digitalen Angeboten die Anforderung eines Non‑Text‑Kontrasts von 3:1 erfüllen.

Zu den von der Präsidialverfügung 2025/10 erfassten Einrichtungen gehören öffentliche Institutionen und Behörden auf allen Ebenen der Regierung, E‑Commerce‑Plattformen, Banken und Finanzinstitute, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsanbieter mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind. Für diese Organisationen ist das Versäumnis, 1.4.11 umzusetzen, nicht nur ein Mangel an Best Practice, sondern eine regulatorische Nichtkonformität.

Das Accessibility Logo (Erişilebilirlik Logosu), das vom Ministerium für Familie und Sozialdienste vergeben wird, dient als öffentlich sichtbares Zertifizierungszeichen für konforme digitale Dienste. Um dieses Logo zu erhalten und zu führen, muss eine Organisation vollständige Konformität auf Stufe AA über alle anwendbaren WCAG‑2.2‑Kriterien hinweg, einschließlich 1.4.11, nachweisen. Da viele türkische E‑Government‑Portale, Bankoberflächen und Gesundheitsformulare in großem Umfang benutzerdefinierte Formularsteuerelemente und Datenvisualisierungen verwenden, ist Non‑Text‑Kontrast ein Kriterium, das Auditoren bei der Zertifizierung besonders wahrscheinlich prüfen werden.

Organisationen, die das Accsible‑Overlay‑Widget verwenden, sollten sich bewusst sein, dass Overlay‑Technologie bei der Behebung bestimmter Kontrastanpassungen zur Laufzeit helfen kann – etwa indem Nutzer ein Hochkontrast‑Theme aktivieren können –, dass aber dauerhafte strukturelle Fehler, wie ein Formulareingabefeld mit einem Rahmenkontrast von 1,6:1, auf Quellcode‑Ebene korrigiert werden müssen, um echte Konformität zu erreichen und sich für das Erişilebilirlik Logosu zu qualifizieren. Die Kombination von Korrekturen auf Quellcode‑Ebene mit den nutzerorientierten Verbesserungsfunktionen eines Barrierefreiheits‑Widgets stellt die am besten vertretbare Compliance‑Strategie nach türkischem Recht dar.