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

Schematische Darstellung von Buttons, Links und sichtbaren Fokusindikatoren mit kontrastreichen Zuständen
Schematische Darstellung von Buttons, Links und sichtbaren Fokusindikatoren mit kontrastreichen Zuständen

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.

  1. Button-Text prüfen: Hat der Text auf dem Button mindestens ausreichend Kontrast zur Button-Fläche?
  2. Button als Komponente prüfen: Hebt sich der Button selbst mit mindestens 3:1 vom angrenzenden Hintergrund ab?
  3. Links im Fließtext prüfen: Sind Links nicht nur farblich, sondern zusätzlich z. B. durch Unterstreichung erkennbar?
  4. Fokus per Tastatur testen: Drücken Sie Tab. Ist auf jedem interaktiven Element sofort klar sichtbar, wo Sie gerade sind?
  5. Fokus-Kontrast prüfen: Hat der Fokusindikator oder Zustandswechsel mindestens 3:1 Kontrast zu den angrenzenden Farben?
  6. Hover vs. Focus vergleichen: Hat der Fokus mindestens die gleiche gestalterische Sorgfalt wie Hover?
  7. 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:

  1. Text gegen Button-Hintergrund
  2. 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 1px auf 2px erhö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:

  1. Jeder interaktive Zustand wird separat geprüft: normal, hover, focus, active, disabled
  2. Buttons werden doppelt geprüft: Textkontrast und Komponentenkontrast
  3. 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

BFSG Check
Schnell prüfen, ob Ihre Website typische Barrieren hat – und was zuerst zu fixen ist (technisch, keine Rechtsberatung).