Ein Kontrastmodus ist keine Einstellung, um die eine Seite höflich gebeten wird. Er ist eine Übernahme: Der Browser verwirft die Farbangaben des Dokuments und ersetzt sie durch eine kleine, vom Nutzer gewählte Palette. Was danach auf dem Bildschirm steht, teilt mit dem Designsystem nur noch die Struktur. Für Oberflächen, die Zustände über Flächenfarbe ausdrücken, Rahmen über Schatten andeuten und Hierarchie über Farbverläufe herstellen, ist das der Moment der Wahrheit. Dieser Beitrag zeigt, was der Modus technisch auslöst, welche Eigenschaften dabei geräuschlos verschwinden, wie das Medienmerkmal forced-colors korrekt eingesetzt wird und an welcher Stelle die europäische Norm daraus eine Anforderung macht, die in einer Prüfung auftaucht.
Das Wichtigste in Kürze
- Im Kontrastmodus zwingt der Browser die Farbanteile aller Eigenschaften auf die Nutzerpalette, nicht nur die Textfarbe. Abschnitt 3.1 (W3C) des CSS Color Adjustment Module hält fest, dass box-shadow und text-shadow zu none rechnen - Kanten aus reinem Schatten sind weg.
- 19 Prozent (Web Almanac 2025) der Seiten tragen inzwischen eine forced-colors-Regel, aber 20 Prozent (Web Almanac 2025) hängen weiter an der abgelösten Herstellerabfrage, die Edge seit Version 138 (Microsoft Edge Blog) überhaupt nicht mehr auswertet.
- 67 Prozent (Web Almanac 2025) der Seiten entfernen den Standard-Fokusrahmen des Browsers. Genau diesen Rahmen gäbe der Kontrastmodus in Systemfarbe zurück; das Vorgehen dazu steht im Beitrag zum Fokus-Management.
- Abschnitt 11.7 (EN 301 549) verlangt, dass eine Oberfläche die Plattformeinstellungen für Farbe, Kontrast und Fokuszeiger übernimmt. Der Kontrastmodus gehört damit in den Prüfumfang eines WCAG-Audits und nicht in die Kategorie der freiwilligen Zugaben.
Was der Kontrastmodus technisch auslöst
Der Ausgangspunkt steht in der Spezifikation für Farbanpassung. Ist der erzwungene Kontrastmodus aktiv und steht forced-color-adjust auf dem Standardwert auto, werden die Farbanteile sämtlicher Eigenschaften eines Elements auf die bevorzugte Palette des Nutzers gezwungen; so beschreibt es Abschnitt 3.1 (W3C) des CSS Color Adjustment Module Level 1. Betroffen ist dabei nicht nur color und background-color, sondern eine ganze Reihe weiterer Eigenschaften, von der Akzentfarbe eines Formularelements bis zur Hervorhebung beim Antippen auf mobilen Geräten. Zwei Folgen desselben Abschnitts richten in der Praxis den meisten Schaden an: box-shadow und text-shadow rechnen zu none, und background-image rechnet ebenfalls zu none, solange der ursprüngliche Wert keine url()-Funktion enthält.
Abfragen lässt sich dieser Zustand über ein eigenes Medienmerkmal. Media Queries Level 5 führt es in Abschnitt 12.4 (W3C) unter dem Namen forced-colors mit genau zwei Werten: none und active. Der Wert active bedeutet, dass der Browser eine vom Nutzer gewählte, begrenzte Farbpalette auf der Seite durchsetzt. Mehr verrät die Abfrage nicht. Sie sagt nichts darüber, welche Farben gewählt wurden, sie nennt keine Helligkeit und sie unterscheidet nicht zwischen einem hellen und einem dunklen Design. Wer aus dem aktiven Zustand auf eine bestimmte Palette schließt, baut auf einer Annahme, die das Betriebssystem jederzeit umwerfen darf - denn die Farben sind dort einzeln einstellbar.
Zwei Signale, die regelmäßig verwechselt werden
Wer den Kontrastmodus tatsächlich benutzt
Die Frage nach der Reichweite kommt in Projekten zuverlässig, und sie ist berechtigt. Belastbare Zahlen sind rar, weil sich ein Systemmodus aus dem Browser heraus kaum zählen lässt, ohne die Nutzer identifizierbar zu machen. Die beste verfügbare Fundstelle ist eine Befragung von WebAIM aus dem September 2018 mit 248 (WebAIM 2018) gültigen Antworten von Menschen mit Sehbeeinträchtigung. Dort geben 51,4 Prozent (WebAIM 2018) an, irgendeine Form von Kontrastmodus zu nutzen, und 30,6 Prozent (WebAIM 2018) nennen den Kontrastmodus ausdrücklich unter den regelmäßig genutzten Hilfsmitteln. Die Erhebung ist klein und selbstselektiv, sie ist bis heute die letzte Ausgabe dieser Reihe, und sie zeigt Größenordnungen statt einer amtlichen Verteilung. Für eine Aufwandsentscheidung reicht das trotzdem, weil die Größenordnung eindeutig ist.
Eine zweite Zahl aus derselben Befragung verändert die Bauweise stärker als die erste. Unter den Befragten, die einen Kontrastmodus nutzen, arbeiten 71,2 Prozent (WebAIM 2018) mit heller Schrift auf dunklem Grund. Wer den Kontrastmodus im Kopf als schwarze Schrift auf weißem Grund führt und seine Regeln entsprechend schreibt, trifft die Mehrheit dieser Gruppe an der Sache vorbei. Ergänzend nennen 46,8 Prozent (WebAIM 2018) aller Befragten eine eingeschränkte Kontrastempfindlichkeit als Teil ihrer Sehbeeinträchtigung - also genau die Eigenschaft, gegen die eine erhöhte Trennschärfe zwischen Vordergrund und Hintergrund hilft. Der Modus ist damit kein Sonderwunsch einer kleinen Gruppe, sondern eine Bedienhilfe mit einem klar umrissenen Zweck.
Weltweite Größenordnung
Mindestens 2,2 Milliarden (WHO) Menschen leben mit einer Seheinschränkung in der Nähe oder in der Ferne. Den jährlichen weltweiten Produktivitätsverlust beziffert dieselbe Quelle auf 411 Milliarden US-Dollar (WHO).
Lage in Deutschland
Zum Jahresende 2023 lebten rund 7,9 Millionen (Statistisches Bundesamt) Menschen mit anerkannter Schwerbehinderung in Deutschland. Bei 4 Prozent (Statistisches Bundesamt) der Fälle war die schwerste Behinderung Blindheit oder eine Sehbehinderung.
Am Arbeitsplatz
Windows liefert vier (Microsoft Learn) eingebaute Kontrastdesigns, nämlich Aquatic, Desert, Dusk und Night sky. Nutzer können sie zusätzlich Farbe für Farbe anpassen, weshalb eine feste Annahme über hell oder dunkel nicht trägt.
Diese Zahlen ersetzen keine Messung an der eigenen Oberfläche, aber sie ordnen den Aufwand ein. Und sie treffen auf einen Bestand, der bereits im Normalzustand schwach ist: Zu geringer Textkontrast fand sich auf 83,9 Prozent (WebAIM Million 2026) der eine Million meistbesuchten Startseiten, im Schnitt 34 (WebAIM Million 2026) einzelne Vorkommen je Seite. Insgesamt wies dieselbe Auswertung im Mittel 56,1 (WebAIM Million 2026) automatisch erkennbare Fehler je Startseite nach, und 95,9 Prozent (WebAIM Million 2026) der Startseiten fielen schon bei den maschinell prüfbaren WCAG-Anforderungen durch. Nur 31 Prozent (Web Almanac 2025) der mobilen Seiten erfüllen derzeit die Mindestanforderungen an den Farbkontrast. Wie sich der Grundkontrast systematisch absichern lässt, beschreibt der Beitrag zu Farbkontrasten in der Praxis.
Die Palette gehört dem System, nicht dem Design
Im Kontrastmodus stammen die Farben aus einer kleinen Menge von Systemfarben, die CSS als Schlüsselwörter bereitstellt. Canvas und CanvasText stehen für Fläche und Text, ButtonFace und ButtonText für Bedienelemente, LinkText und VisitedText für Verweise, Highlight und HighlightText für Auswahl und Fokus, GrayText für deaktivierte Zustände, Field und FieldText für Eingabefelder. Diese Schlüsselwörter sind im Kontrastmodus der einzige sinnvolle Weg, überhaupt noch Farbe zu setzen: Jede feste Farbangabe wird ohnehin ersetzt, solange die Zwangsanpassung nicht ausdrücklich abgeschaltet ist. Der Gewinn dieser Beschränkung liegt in der Verlässlichkeit. Ein Element, das ButtonFace und ButtonText verwendet, sieht in jedem Kontrastdesign so aus wie die übrigen Bedienelemente des Systems, ohne dass die Seite die Farbwerte kennen müsste.
Warum diese Paletten so hart wirken, erklärt die Herstellerdokumentation selbst: Kontrastdesigns arbeiten mit Kontrastverhältnissen typischerweise ab 7:1 (Microsoft Learn), um die Lesbarkeit zu verbessern, visuelle Ermüdung zu verringern und eine deutliche Trennung zwischen Vorder- und Hintergrund zu erreichen. Das liegt spürbar über dem Mindestwert von 4,5:1 (W3C), den das Erfolgskriterium Kontrast (Minimum) der WCAG 2.2 für normalen Text auf Stufe AA verlangt. Solange eigene Farbangaben die Systempalette nicht wieder aushebeln, liefert der Modus den Kontrast also von sich aus - und eine Seite, die im Kontrastmodus schlechter lesbar wird als im Standardzustand, hat fast sicher irgendwo eine feste Farbe stehen, die dort nicht hingehört.
/* Der Block greift nur, wenn der Modus aktiv ist */
@media (forced-colors: active) {
.karte {
/* Systemfarben statt Markenfarben */
background-color: Canvas;
color: CanvasText;
/* Der Schatten faellt weg, die Kante muss bleiben */
border: 1px solid CanvasText;
}
.aktion {
background-color: ButtonFace;
color: ButtonText;
border: 1px solid ButtonText;
}
.aktion:focus-visible {
outline: 3px solid Highlight;
outline-offset: 2px;
}
.status-fehler {
/* Farbe allein traegt hier nichts mehr */
border-left: 4px solid CanvasText;
forced-color-adjust: auto;
}
}| Gestaltungsmittel | Standard | Dunkelmodus | Kontrastmodus |
|---|---|---|---|
| Flächenfarbe einer Karte | Markenfarbe aus dem Token | dunkle Variante desselben Tokens | Canvas, vom Nutzer gewählt |
| Kante aus box-shadow | sichtbar | sichtbar | rechnet zu none, Abschnitt 3.1 (W3C) |
| Hintergrund als Farbverlauf | sichtbar | sichtbar | rechnet zu none, außer bei url() |
| Fokusring in Markenfarbe | sichtbar | sichtbar | wird zur Systemfarbe Highlight |
| Zustand allein über Farbe | erkennbar | erkennbar | nicht mehr unterscheidbar |
| Text auf farbiger Fläche | gemessener Kontrast | gemessener Kontrast | Systemkontrast, ab etwa 7:1 (Microsoft Learn) |
Der teuerste Befund entsteht nicht im Kontrastmodus
Was geräuschlos verschwindet
Die gefährlichen Wirkungen des Modus sind die, die keine Fehlermeldung erzeugen. Nichts bricht, nichts überlappt, die Seite wirkt auf den ersten Blick sogar aufgeräumter als vorher. Es fehlen lediglich ein paar Kanten - und mit ihnen die Information, die diese Kanten getragen haben. In Prüfungen fallen fünf Muster besonders regelmäßig auf, und alle fünf lassen sich im Designsystem an einer Stelle beheben statt in jedem Bauteil einzeln.
- Kanten aus Schatten. Karten, Ausklappmenüs und Dialoge, deren Begrenzung nur aus box-shadow besteht, verlieren sie ersatzlos. Für schwebende Flächen empfiehlt die Herstellerdokumentation ausdrücklich einen 2 Pixel (Microsoft Learn) breiten Rahmen, weil sonst der Übergang zwischen Fläche und Untergrund verschwindet.
- Verläufe als Hintergrund. Ein background-image mit linear-gradient rechnet zu none, solange der Wert keine url()-Funktion enthält. Steht Text auf dem Verlauf statt auf einer eigenen Fläche, steht er danach auf der Systemfläche - meist lesbar, aber die beabsichtigte Gliederung ist weg.
- Symbole als Hintergrundbild. Ein Icon, das per background-image mit einer Data-URL gesetzt wird, überlebt die Zwangsanpassung, behält aber seine ursprüngliche Farbe. Auf dunklem Systemgrund wird ein dunkles Symbol dadurch praktisch unsichtbar.
- Inline-SVG mit fester Füllung. Eine Grafik mit fest gesetztem fill folgt der Systempalette nicht. Wer stattdessen currentColor verwendet, bekommt die passende Farbe ohne zusätzliche Regel und ohne zweite Grafikdatei.
- Transparenz als Trennung. Halbtransparente Überlagerungen, ausgegraute Bereiche und weiche Schattenkanten verlieren ihre Wirkung, sobald jede Fläche dieselbe Systemfarbe trägt. Für deaktivierte Zustände steht dafür GrayText bereit.
Auffällig ist, dass keines dieser Muster ein Fehler im engeren Sinn ist. Jedes davon ist eine Abkürzung, die im Standardzustand funktioniert und deren Kosten erst sichtbar werden, wenn die Farbhoheit wechselt. Genau deshalb lohnt der Blick in die Komponentenbibliothek mehr als der Blick in die einzelne Seite: Wer eine Karte, ein Eingabefeld und einen Dialog sauber baut, hat den größten Teil des Bestands mitbehandelt. Wie sich das in wiederverwendbaren Bausteinen festhalten lässt, beschreibt der Beitrag zum barrierefreien Designsystem.
Der Fokusrahmen ist der empfindlichste Punkt
Kein anderes Gestaltungselement wird so oft entfernt und so selten ersetzt. 67 Prozent (Web Almanac 2025) der Seiten löschen den Standard-Fokusrahmen des Browsers, deutlich mehr als im Vorjahr; die zeitgemäße Alternative :focus-visible steht dagegen erst auf 25 Prozent (Web Almanac 2025) der Desktop-Seiten. Diese Werte stammen nicht aus einer Stichprobe, sondern aus dem monatlichen Crawl des HTTP Archive über 17 Millionen (Web Almanac 2025) Seiten mit Start- und Unterseiten. Im Kontrastmodus wiegt der Verlust doppelt: Der Browser gäbe den Rahmen in der Systemfarbe Highlight zurück, aber nur, wenn die Seite ihn nicht vorher weggeräumt hat. Ein outline: none bleibt auch dort ein outline: none.
WCAG 2.2 hat für diesen Punkt erstmals eine messbare Untergrenze formuliert. Der Fokusanzeiger muss mindestens so groß sein wie die Fläche eines 2 CSS-Pixel (W3C) breiten Umrisses der unfokussierten Komponente und zwischen fokussiertem und unfokussiertem Zustand einen deutlichen Kontrastunterschied aufweisen. Das Kriterium liegt auf Stufe AAA und ist damit nicht Teil des üblichen Prüfumfangs, aber es liefert eine brauchbare Zahl für die Gestaltung. Praktisch heißt das: ein durchgehender Umriss statt eines angedeuteten Schattens, ein Abstand zum Element, damit der Rahmen nicht mit dem Rand verschmilzt, und im Block für forced-colors eine outline-color aus der Systempalette. Für Anwendungen, in denen der Fokus programmgesteuert wandert, lohnt zusätzlich der Beitrag zum Fokus-Management.
/* Sichtbarer Fokus in allen drei Zustaenden */
.aktion:focus-visible {
outline: 3px solid var(--fokus);
outline-offset: 2px;
}
@media (forced-colors: active) {
.aktion:focus-visible {
/* Systemfarbe statt Markenfarbe */
outline-color: Highlight;
}
}
/* Kante tragend, Schatten nur als Zugabe */
.eingabe {
border: 1px solid var(--rand);
box-shadow: 0 1px 2px rgb(0 0 0 / 0.08);
}Der zweite Punkt betrifft die Ränder selbst. Das Erfolgskriterium Nichttext-Kontrast verlangt für Bedienelemente und ihre Zustände ein Kontrastverhältnis von mindestens 3:1 (W3C) gegenüber angrenzenden Farben. Ein Eingabefeld, dessen Begrenzung im Normalzustand aus einem weichen Schatten besteht, erfüllt das im Kontrastmodus nicht mehr, weil dort schlicht keine Begrenzung übrig bleibt. Wer von vornherein mit border arbeitet und den Schatten nur als Zugabe einsetzt, bekommt in allen drei Zuständen dasselbe Ergebnis und spart sich die Sonderregel. Dieselbe Überlegung gilt für Trennlinien in Tabellen, für die Umrandung von Karten und für die Kante aktiver Reiter in einer Navigation.
forced-color-adjust: Notausgang mit Preisschild
Es gibt Fälle, in denen die Zwangsanpassung schadet statt zu helfen: eine Farbtafel im Konfigurator, ein Diagramm mit farbcodierten Reihen, die Vorschau eines gewählten Lacktons, eine Ampel in einem Bericht, deren Farbe die Aussage selbst ist. Für sie kennt die Spezifikation forced-color-adjust: none. Die Eigenschaft schaltet die Zwangsanpassung für ein Element und seine Nachkommen ab; die Farben bleiben dann so, wie das Dokument sie gesetzt hat. Das ist eine Ausnahme mit Preisschild, denn ab diesem Punkt trägt wieder die Seite die Verantwortung für den Kontrast, und niemand weiß, welchen Untergrund das gewählte Kontrastdesign gerade liefert.
/* Ausnahme nur dort, wo Farbe die Information IST */
.farbprobe {
forced-color-adjust: none;
/* eigener Rahmen, weil das System hier nicht mehr traegt */
border: 2px solid CanvasText;
}
.farbprobe__name {
/* Zweite Kodierung: der Name steht daneben */
forced-color-adjust: auto;
}Drei Regeln für die Ausnahme
Die abgelöste Abfrage und ihr stiller Schaden
Vor dem Standard gab es einen Herstellerweg, und er ist inzwischen Geschichte. Das Edge-Team hat das nicht standardisierte Medienmerkmal -ms-high-contrast und die zugehörige Eigenschaft vollständig entfernt, beginnend mit Version 138 (Microsoft Edge Blog). Wer noch darauf setzt, hat im heutigen Edge überhaupt keine Kontrastmodus-Regel mehr: Der Block wird nicht ausgewertet, es entsteht kein Fehler, und weil kein Fehler entsteht, fällt es niemandem auf. Im Bestand ist das kein Randfall. Die abgelöste Abfrage steckt mit 20 Prozent (Web Almanac 2025) in mehr Seiten als der Standard, der sie ersetzt hat, mit 19 Prozent (Web Almanac 2025) - ein Verhältnis, das sich nur durch alte Vorlagen und mitgeschleppte Bibliotheken erklären lässt.
Der Standard ist dabei alles andere als neu. Das Medienmerkmal forced-colors gilt als gut etabliert und ist nach der Baseline-Einstufung seit September 2022 (MDN Web Docs) über die Browser hinweg verfügbar. Für ein Projekt, das heute entsteht, gibt es also keinen technischen Grund mehr für den Herstellerweg; für ein älteres Projekt lohnt eine gezielte Suche nach der alten Zeichenfolge im Stylesheet, weil sie sich meist auf wenige Stellen konzentriert. Der Umbau ist in der Regel mechanisch: Die Bedingung wechselt, die Farbwerte innerhalb des Blocks werden durch Systemfarben ersetzt, und die Sonderfälle für einzelne Werte der alten Abfrage entfallen ersatzlos.
Eine Feinheit mit großer Wirkung steckt in der Kopplung an den Dunkelmodus. Ob ein Kontrastdesign als hell oder dunkel gilt, entscheidet der Browser an der Helligkeit der erzwungenen Hintergrundfarbe: In Chromium trifft ein erzwungener Hintergrund mit einer Leuchtdichte unter 0,33 (Microsoft Edge Blog 2020) auf prefers-color-scheme: dark. Kontrastmodus und Dunkelmodus können also gleichzeitig gelten, ohne dasselbe zu sein. Eine Regel, die nur den Dunkelmodus behandelt, liegt im Kontrastmodus dann zufällig richtig oder zufällig falsch - und wer beide Blöcke schreibt, sollte die Reihenfolge im Stylesheet bewusst festlegen, weil sonst der spätere Block gewinnt, ohne dass jemand diese Entscheidung getroffen hätte. Wer Nutzervorlieben insgesamt sauber behandeln möchte, findet die Systematik im Beitrag zu prefers-reduced-motion.
Prüfen: drei Zustände, ein Durchgang
Der Kontrastmodus lässt sich nicht aus dem Kopf beurteilen. Er braucht einen eigenen Durchgang, und dieser Durchgang bleibt kurz, wenn er systematisch abläuft. Am schnellsten geht es im Browser: Die Entwicklerwerkzeuge der Chromium-Browser können den Zustand forced-colors: active erzwingen, ohne dass das Betriebssystem umgestellt werden muss. Für eine Abnahme reicht das nicht, weil der emulierte Zustand mit einer Standardpalette arbeitet, während echte Nutzer eigene Farben setzen. Für die tägliche Arbeit an einer Komponente ist es der kürzeste Weg, und für die Abnahme kommt ein Durchgang auf einem echten System mit einem eingeschalteten Kontrastdesign hinzu.
- Die Seite im erzwungenen Kontrastmodus öffnen und mit der Tabulatortaste einmal vollständig durchlaufen. Jede Station muss sichtbar sein; verschwindet der Fokus, ist die Ursache fast durchgängig ein outline: none ohne Ersatz.
- Alle Kanten zählen, die im Standardzustand vorhanden sind und im Kontrastmodus fehlen: Karten, Eingabefelder, Ausklappmenüs, Dialoge, Tabellenlinien, Trennstriche, aktive Reiter.
- Jeden Zustand einer Komponente durchschalten - Standard, überfahren, fokussiert, gedrückt, ausgewählt, deaktiviert, fehlerhaft - und prüfen, ob er sich noch von den übrigen unterscheidet.
- Symbole und Grafiken ansehen: Bleibt ein Symbol in seiner alten Farbe stehen, ist es entweder ein Hintergrundbild oder ein SVG mit fest gesetztem fill.
- Denselben Durchgang in einem hellen und in einem dunklen Kontrastdesign wiederholen, weil 71,2 Prozent (WebAIM 2018) der Nutzer eines Kontrastmodus helle Schrift auf dunklem Grund einstellen.
- Am Ende den Standardzustand gegen den Kontrastmodus halten: Was im Kontrastmodus besser lesbar ist als im Original, verweist auf ein Kontrastproblem im Design selbst.
Diese Reihenfolge findet in der Praxis mehr als eine Werkzeugausgabe, weil sie an Zuständen entlanggeht statt an Regeln. Automatische Prüfungen sehen den Kontrastmodus ohnehin kaum: Sie messen berechnete Farben im Normalzustand und melden dort Verstöße gegen Kontrastschwellen - eine Kante, die im Kontrastmodus wegfällt, taucht in keinem dieser Berichte auf. Welches Werkzeug welchen Teil abdeckt und wo die maschinelle Prüfung endet, ordnet der Überblick zu Prüfwerkzeugen ein. Sinnvoll ist außerdem, den Kontrastmodus in die Prüfung von Schrift und Zeilenführung einzubeziehen, weil dünne Schriftschnitte auf harten Systemfarben anders wirken; dazu passt der Beitrag zur barrierefreien Typografie.
Warum das keine freiwillige Zugabe ist
Die europäische Norm, an der in Deutschland gemessen wird, hat für diesen Fall einen eigenen Abschnitt. Abschnitt 11.7 (EN 301 549) verlangt, dass eine Software, die nicht von ihrer Plattform isoliert ist und eine Benutzerschnittstelle bereitstellt, den Werten der Nutzereinstellungen für Plattformoptionen folgt - ausdrücklich genannt sind Maßeinheiten, Farbe, Kontrast, Schriftart, Schriftgröße und Fokuszeiger, soweit der Nutzer sie nicht selbst überschreibt. Eine Anmerkung im selben Abschnitt stellt klar, dass für Webinhalte der Browser die zugrunde liegende Plattform ist. Damit ist der Kontrastmodus des Betriebssystems, den der Browser an die Seite durchreicht, genau die Einstellung, der eine Oberfläche zu folgen hat.
Zwei weitere Verweise derselben Norm schließen den Kreis zur Messung. Für Webseiten verlangt Abschnitt 9.1.4.3 die Erfüllung des WCAG-Erfolgskriteriums 1.4.3 (EN 301 549) Kontrast (Minimum), Abschnitt 9.2.4.7 die Erfüllung des Kriteriums 2.4.7 (EN 301 549) Fokus sichtbar. Die Norm schreibt an dieser Stelle also keine eigenen Zahlen vor, sondern übernimmt die WCAG-Anforderungen unverändert. Der zugehörige Messwert steht dann dort: mindestens 4,5:1 (W3C) für normalen Text auf Stufe AA. Wer die Systematik im Zusammenhang lesen möchte, findet sie im Beitrag zur EN 301 549 und in der Übersicht der neuen Kriterien aus WCAG 2.2.
Der Kontrastmodus prüft nicht die Farbwahl einer Oberfläche, sondern ihre Bauweise. Was ohne die eigene Palette zusammenfällt, hat vorher Farbe arbeiten lassen, wo Struktur hätte stehen müssen.
Vorgehen im Projekt
Die Arbeit bleibt überschaubar, wenn sie an der richtigen Stelle beginnt. Der Kontrastmodus deckt selten ein Problem auf, das nur ihn betrifft; er macht Abkürzungen sichtbar, die im Designsystem stecken. Deshalb lohnt es sich, ihn früh in die Komponentenbibliothek zu holen statt spät in die Abnahme. Ein Durchgang durch die zwanzig meistgenutzten Bausteine deckt in den meisten Projekten den überwiegenden Teil der Oberfläche ab, weil sich Karten, Schaltflächen, Eingabefelder und Dialoge über die ganze Anwendung wiederholen.
- Im Designsystem jede Kante prüfen, die aus box-shadow entsteht, und eine border als tragende Variante ergänzen; der Schatten bleibt Zugabe.
- Jeden Zustand mit einem zweiten Merkmal versehen, das nicht Farbe ist - Symbol, Rahmenstärke oder Beschriftung.
- Fokusstile auf :focus-visible umstellen und im Block für forced-colors auf Highlight setzen; ergänzend dazu der Beitrag zur Tastaturnavigation.
- Inline-SVG auf currentColor umstellen und Symbole ersetzen, die als Hintergrundbild eingebunden sind.
- forced-color-adjust: none ausschließlich dort setzen, wo Farbe die Information selbst ist, und jede solche Fläche mit einem Systemrahmen versehen.
- Alte -ms-high-contrast-Blöcke suchen und durch forced-colors ersetzen, damit die Regeln überhaupt wieder greifen.
- Den Kontrastmodus in die Abnahmeliste aufnehmen, gemeinsam mit Dunkelmodus und Standardzustand: drei Zustände, ein Durchgang.
Was dabei entsteht, wirkt weit über den Kontrastmodus hinaus. Eine Komponente, die ihre Zustände nicht allein über Farbe zeigt, bleibt auch für Menschen mit Farbfehlsichtigkeit eindeutig. Ein Fokusring, der die Systemfarbe übernimmt, funktioniert auch bei einem selbst zusammengestellten Kontrastdesign. Und ein Designsystem, das seine Kanten trägt statt sie anzudeuten, wird an einer Stelle stabiler, an der es sonst regelmäßig bricht. Wer den eigenen Bestand einordnen möchte, findet die passenden Schritte in unseren Leistungen zur digitalen Barrierefreiheit und in der barrierefreien Webentwicklung; wo Karten und Standortsuchen dieselbe Frage aufwerfen, hilft der Beitrag zu barrierefreien Karten und Filialfindern, und für Anwendungen hinter der Anmeldung der Beitrag zum barrierefreien Intranet.
Quellen und Studien
Verwandte Artikel
Tooltips barrierefrei: eingeblendete Inhalte nach 1.4.13
Erfolgskriterium 1.4.13 verlangt drei Dinge zugleich: ausblendbar, überfahrbar, beständig. Der Beitrag zerlegt den Wortlaut, zeigt den Prüfweg des BITV-Tests.
Barrierefreie Karten: Filialfinder ohne Sackgasse
Kartenmodule fallen im Audit regelmäßig durch. Wie eine Standortsuche ohne Maus, ohne Farbunterscheidung und mit Screenreader ans Ziel führt: Liste.
Barrierefreie Lernplattformen: E-Learning nach BFSG
Kostenpflichtige Onlinekurse fallen unter das BFSG, Hochschulen unter die BITV 2.0. So wird die Lernstrecke von der Buchung bis zum Zertifikat barrierefrei.