Button- und Fokus-Kontraste prüfen: WCAG-Werte für Buttons, Links und Fokusindikatoren praxisnah

Button- und Fokus-Kontraste prüfen: WCAG-Werte für Buttons, Links und Fokusindikatoren praxisnah
Kontrastprobleme sitzen selten im Fließtext allein. In der Praxis fallen vor allem Buttons, Links, Formularrahmen und Fokusindikatoren durch: Primär-Buttons wirken auf dem Styleguide sauber, sind auf echter Seite aber zu hell. Links heben sich nur über Farbe ab. Der Fokus ist technisch vorhanden, visuell aber kaum zu erkennen.
Wenn Sie BFSG- und WCAG-Risiken schnell reduzieren wollen, ist das ein guter 80/20-Startpunkt. Denn genau diese Elemente entscheiden darüber, ob Nutzerinnen und Nutzer Aktionen finden, verstehen und per Tastatur sicher ausführen können.
Wenn Sie die Grundlagen zu allgemeinen Kontrastwerten zuerst kompakt einordnen möchten, lesen Sie ergänzend unseren Überblick zu WCAG-Kontrastwerten.
Quick-Test: 7 Minuten für Buttons, Links und Fokus
Gehen Sie auf drei reale Seitentypen: Startseite, Formular oder Login, sowie Produkt- oder Leistungsseite.
- Button-Text prüfen: Hat der Text auf dem Button mindestens ausreichend Kontrast zur Button-Fläche?
- Button als Komponente prüfen: Hebt sich der Button selbst mit mindestens 3:1 vom angrenzenden Hintergrund ab?
- Links im Fließtext prüfen: Sind Links nicht nur farblich, sondern zusätzlich z. B. durch Unterstreichung erkennbar?
- Fokus per Tastatur testen: Drücken Sie
Tab. Ist auf jedem interaktiven Element sofort klar sichtbar, wo Sie gerade sind? - Fokus-Kontrast prüfen: Hat der Fokusindikator oder Zustandswechsel mindestens 3:1 Kontrast zu den angrenzenden Farben?
- Hover vs. Focus vergleichen: Hat der Fokus mindestens die gleiche gestalterische Sorgfalt wie Hover?
- Fehlerstatus mitdenken: Werden Pflichtfelder, Fehler und aktive Zustände nicht nur über Rot oder eine einzelne Farbe signalisiert?
Wenn Sie bei zwei oder mehr Punkten stocken, sollten Sie die betroffenen Komponenten priorisiert überarbeiten. Für den Gesamtprozess hilft der Leitfaden Website auf BFSG-Konformität prüfen: automatisch und manuell.
Welche WCAG-Werte Sie hier wirklich brauchen
Für die Praxis reichen meist vier Schwellenwerte, die Teams sauber unterscheiden sollten:
- Normaler Text: mindestens 4,5:1 Kontrast zur Hintergrundfarbe
- Großer Text: mindestens 3:1; als groß gilt laut WCAG etwa 18 pt oder 14 pt fett
- UI-Komponenten und grafische Zustände: mindestens 3:1 zu angrenzenden Farben
- Fokusindikatoren: mindestens 3:1 Kontrast; nach WCAG 2.2 zusätzlich mit einer klar wahrnehmbaren Mindestfläche
Das bedeutet konkret:
- Bei einem Button müssen Sie den Text im Button separat prüfen.
- Zusätzlich prüfen Sie die Button-Fläche oder Kontur gegen den umgebenden Hintergrund.
- Beim Fokus reicht ein zarter Farbwechsel oft nicht. Der Fokus muss erkennbar genug sein, nicht nur „technisch vorhanden“.
Warum relevant (BFSG/WCAG)
Das BFSG nennt die WCAG nicht immer direkt in Alltagssprache, die praktische Umsetzung für digitale Oberflächen läuft jedoch faktisch über die etablierten Accessibility-Standards. Genau deshalb landen Kontrast- und Fokusfragen in fast jedem Audit, jeder BITV-Prüfung und jedem belastbaren BFSG-Check.
Für Buttons, Links und Fokus sind insbesondere diese WCAG-Erfolgskriterien relevant:
- 1.4.3 Kontrast (Minimum): 4,5:1 für normalen Text, 3:1 für großen Text
- 1.4.11 Nicht-Text-Kontrast: 3:1 für notwendige visuelle Informationen von UI-Komponenten und Zuständen
- 2.4.7 Fokus sichtbar: Fokus muss überhaupt sichtbar sein
- 2.4.13 Fokusdarstellung (WCAG 2.2): Fokus braucht zusätzlich ausreichende Fläche und 3:1 Kontrast zwischen fokussiertem und unfokussiertem Zustand
Für deutsche Teams ist wichtig: Das ist nicht nur Design-Feinschliff. Wenn Nutzer Buttons nicht erkennen, Links nicht unterscheiden oder den Tastaturfokus verlieren, betrifft das Wahrnehmbarkeit und Bedienbarkeit unmittelbar.
Buttons richtig prüfen: Text, Fläche, Rand, Zustand
Bei Buttons passieren vier typische Fehler gleichzeitig:
- Weißer Text auf zu hellem Markenblau
- Hellgrauer Secondary-Button auf weißem Hintergrund
- Outline-Button mit zu schwachem Rand
- Aktive oder deaktivierte Zustände ohne klare Unterscheidung
Praxisregel für Primär-Buttons
Prüfen Sie immer beide Ebenen:
- Text gegen Button-Hintergrund
- Button-Komponente gegen Seitenhintergrund
Beispiel:
.btn-primary {
background: #2563eb;
color: #ffffff;
}
Das kann für den Text gut funktionieren. Wenn der Button aber auf einem ähnlich blauen oder sehr hellen Bereich sitzt und kaum noch als Komponente erkennbar ist, haben Sie trotzdem ein Problem. Bei Outline-Buttons ist das noch häufiger der Fall:
.btn-secondary {
background: #ffffff;
color: #1f2937;
border: 1px solid #cbd5e1;
}
Hier ist oft nicht der Text das Problem, sondern der zu schwache Rand. Ein Rand mit zu wenig Kontrast macht den Button visuell instabil, gerade für Menschen mit Sehschwäche.
Schnelle Fixes für Buttons
- Randstärke von
1pxauf2pxerhöhen, wenn die Farbe knapp ist - Statt Markenblau 500 lieber 700 oder 800 nutzen
- Ghost-Buttons nur dort einsetzen, wo wirklich genug Fläche und Kontrast vorhanden sind
- Deaktivierte Zustände nicht zu stark ausgrauen; sie müssen weiterhin erkennbar bleiben
Wenn Ihre Teams Fokus systematisch standardisieren wollen, kombinieren Sie die hier genannten Kontrastregeln mit einer festen Tastatur- und Release-Routine, wie wir sie in Tastaturbedienung testen: Fokus und Tab-Reihenfolge beschreiben.
Links im Text: Farbe allein reicht nicht
Links in Fließtexten sind ein Klassiker. Optisch „clean“, praktisch aber oft schwach.
Problematisch sind vor allem Muster wie diese:
- normaler Text in Dunkelgrau
- Link ebenfalls in Dunkelgrau oder leichtem Blau
- Unterscheidung nur über Farbe
- Unterstreichung erst bei Hover
Für viele Nutzer ist das zu wenig. Links sollten im Fließtext in der Regel zusätzlich unterstrichen sein oder zumindest eine deutlich wahrnehmbare, nicht nur farbliche Unterscheidung haben.
Schwach ist zum Beispiel:
a {
color: #2563eb;
text-decoration: none;
}
a:hover {
text-decoration: underline;
}
Robuster ist:
a {
color: #1d4ed8;
text-decoration: underline;
text-underline-offset: 0.15em;
}
a:hover,
a:focus-visible {
text-decoration-thickness: 2px;
}
So ist der Link nicht nur beim Hover, sondern auch im Normalzustand als Link erkennbar.
Fokusindikatoren praxisnah fixen
Der häufigste echte Fehler lautet immer noch: outline: none; ohne Ersatz. Der zweithäufigste: Fokus ist zwar da, aber auf hellen Flächen, Bildern oder bunten Buttons nicht stabil sichtbar.
Für einen robusten Fokusstil haben sich diese Regeln bewährt:
- mindestens 2 bis 3 px Stärke
- klarer Offset, damit Ring und Komponente nicht verschmelzen
- eigene Fokusfarbe, nicht bloß leicht dunkler als Hover
- bei schwierigen Hintergründen zweifarbiger Fokus oder Ring plus Außenkante
Beispiel für einen belastbaren Standard:
:root {
--focus-ring: #111827;
--focus-accent: #ffffff;
}
:where(a, button, input, select, textarea, summary, [tabindex="0"]):focus-visible {
outline: 2px solid var(--focus-accent);
box-shadow: 0 0 0 4px var(--focus-ring);
outline-offset: 2px;
}
Der Vorteil: Einer der beiden Ringe hebt sich fast immer ausreichend von Komponente und Umgebung ab. Gerade auf farbigen Buttons, grauen Formularfeldern oder Bildhintergründen ist das deutlich robuster als ein einzelner blauer Ring.
Wenn Sie den kompletten Tastaturpfad prüfen möchten, gehen Sie danach direkt in unsere Anleitung zur Tastaturbedienung mit Fokus und Tab-Reihenfolge.
Typische Problemstellen in echten Projekten
Diese Stellen sollten Sie zuerst prüfen, weil dort Kontrast- und Fokusfehler besonders häufig auftreten:
- Header-Navigation mit kleinen Textlinks
- CTA-Buttons im Hero auf Farb- oder Bildflächen
- Cookie-Banner mit schwachen Outline-Buttons
- Formularfelder mit dünnem Rahmen und kaum sichtbarem Fokus
- Checkboxen und Radio-Buttons in Custom-Designs
- Fehlermeldungen, die nur rot markieren
Gerade Cookie- und Consent-Layer sind oft auffällig, weil Fokus, Kontrast und Tastaturverhalten dort zusammenbrechen. Dafür haben wir einen eigenen Leitfaden zu barrierefreien Cookie-Bannern.
Umsetzungsbeispiele für Design- und Dev-Teams
Beispiel 1: Markenbutton ist zu hell
Ist-Zustand
- Hintergrund
#4f8cff - Text
#ffffff - Fokus nur als leicht dunkler Schatten
Fix
- Button-Blau abdunkeln
- Fokusring in kontrastreicher Farbe ergänzen
- Sekundärzustände separat testen
Beispiel 2: Linklisten im Footer sind kaum erkennbar
Ist-Zustand
- Text und Links fast gleiche Farbe
- kein Unterstrich
- Hover vorhanden, Fokus kaum sichtbar
Fix
- Linkfarbe klar absetzen
- Unterstreichung standardmäßig aktivieren
- Fokusstil auf allen Footer-Links angleichen
Beispiel 3: Formularfeld mit „sauberem“ Minimalstil
Ist-Zustand
border: 1px solid #e5e7eb- Fokus nur durch leichtes Blau im Rand
- Fehler nur in Rot
Fix
- Standardrand dunkler und stabiler
- Fokus mit Ring plus Offset
- Fehler mit Text, Icon oder Hinweis ergänzen, nicht nur farblich
Empfehlung: Eine kleine Kontrast-Definition of Done
Damit das Thema nicht bei jeder Komponente neu diskutiert wird, definieren Sie intern drei einfache Regeln:
- Jeder interaktive Zustand wird separat geprüft: normal, hover, focus, active, disabled
- Buttons werden doppelt geprüft: Textkontrast und Komponentenkontrast
- Links im Fließtext sind nicht nur über Farbe unterscheidbar
Das spart Diskussionen zwischen Design, Entwicklung und QA und verhindert, dass kontrastarme Komponenten immer wieder zurückkommen.
Fazit
Wenn Sie nur einen kleinen Accessibility-Blocker pro Sprint anfassen können, nehmen Sie Buttons, Links und Fokus. Der Aufwand ist überschaubar, die Wirkung hoch, und Sie verbessern gleichzeitig Bedienbarkeit, Conversion und Prüfstand gegen WCAG/BFSG.
Starten Sie am besten mit Ihren wichtigsten Seitentypen und den Komponenten aus Ihrem Design-System. Danach prüfen Sie, welche Risiken bereits automatisiert auffallen und wo manuelle Nachtests nötig sind.
CTA: Wenn Sie schnell sehen möchten, welche Barrieren auf Ihren wichtigsten Seiten schon heute auffallen, starten Sie hier den strukturierten Erstcheck: BFSG-Scan starten
Quellen
- W3C WAI: Understanding Success Criterion 1.4.3: Contrast (Minimum)
- W3C WAI: Understanding Success Criterion 1.4.11: Non-text Contrast
- W3C WAI: Understanding Success Criterion 2.4.13: Focus Appearance
- Gesetze im Internet: BFSG
- Gesetze im Internet: BFSGV
- Bundesfachstelle Barrierefreiheit: Gestaltung und Kontraste