WCAG 2.1 AA — Kontrast, Fokus, Tastatur, ARIA

Würdigung — WCAG 2.1 AA ist die Messlatte hinter dem BFSG#

Das BFSG sagt, dass bestimmte Websites barrierefrei sein müssen — aber nicht im Detail wie. Den Wie-Maßstab liefert die WCAG 2.1 (Web Content Accessibility Guidelines) des W3C, in der mittleren Stufe AA. Sie ist 2026 der etablierte Standard, auf den sich Prüfungen und harmonisierte Normen beziehen.

Der gute Teil: WCAG AA ist nicht schwammig, sondern in weiten Teilen messbar oder testbar. Man muss nicht „ein Gefühl für Barrierefreiheit" haben — man kann Kontrast in einer Zahl prüfen, Tastatur-Bedienung durchklicken und Fokus-Rahmen sehen. Für eine Kanzlei-Website mit überschaubarem Funktionsumfang ist das Ziel realistisch, wenn man es von Anfang an mitdenkt, statt es nachträglich aufzusetzen.

Kontrast 4,5:1 — Lesbarkeit als Zahl#

Das am häufigsten verletzte Kriterium ist der Kontrast (Erfolgskriterium 1.4.3). Normaler Text muss zum Hintergrund ein Kontrastverhältnis von mindestens 4,5:1 haben, großer Text mindestens 3:1. Das Verhältnis ist berechenbar — es gibt kostenlose Kontrast-Prüfer, in die man Vorder- und Hintergrundfarbe einträgt.

In der Praxis scheitern daran modische Designs: hellgraue Schrift auf weißem Grund, dünne Schrift in einem zarten Akzentton, Text über einem Foto ohne ausreichende Abdunklung. Das sieht auf dem Designer-Monitor elegant aus und ist für Menschen mit eingeschränktem Sehvermögen — und für jeden bei Sonnenlicht auf dem Handy — schwer lesbar. Die Lösung ist unspektakulär: Farben so wählen, dass die Zahl stimmt. Das ist keine ästhetische Einschränkung, sondern eine Randbedingung wie die Schriftgröße.

Tastatur-Bedienung und sichtbare Fokus-Indikatoren#

Zwei Kriterien gehören zusammen. Tastatur-Bedienbarkeit (2.1.1) verlangt, dass sich die ganze Seite ohne Maus bedienen lässt — jeder Link, jeder Button, jedes Formularfeld per Tab-Taste erreichbar und per Enter/Leertaste auslösbar. Das betrifft Menschen mit motorischen Einschränkungen, Screenreader-Nutzer und auch Power-User, die ohnehin lieber tippen.

Sichtbarer Fokus (2.4.7) ergänzt das: Das Element, auf dem die Tastatur gerade steht, muss erkennbar markiert sein — ein deutlicher Rahmen. Der häufigste Fehler ist, diesen Fokus-Rahmen aus ästhetischen Gründen per CSS zu entfernen (outline: none), ohne Ersatz. Dann tabbt man blind durch die Seite und weiß nie, wo man ist. Die saubere Lösung ist, den Fokus nicht zu entfernen, sondern sichtbar und markenkonform zu gestalten — etwa über :focus-visible, das den Rahmen nur bei Tastatur-Bedienung zeigt, nicht beim Maus-Klick.

ARIA-Live — was Screenreader hören müssen#

Das vierte Kriterium ist das unsichtbarste. Status-Meldungen (4.1.3) verlangen, dass dynamische Rückmeldungen auch für Screenreader-Nutzer wahrnehmbar sind. Beispiel: Ein Besucher sendet das Kontaktformular ab, und es erscheint „Ihre Nachricht wurde versendet". Ein sehender Nutzer sieht das. Ein blinder Nutzer hört es nur, wenn die Meldung in einer ARIA-Live-Region steht — einem Bereich, den der Screenreader bei Änderung automatisch vorliest, ohne dass der Fokus dorthin springt.

Das gilt für jede Rückmeldung, die nicht durch einen Seitenwechsel kommt: Erfolg- und Fehlermeldungen bei Formularen, Lade-Hinweise, Validierungs-Texte. Ohne ARIA-Live bleibt der blinde Nutzer im Ungewissen, ob seine Aktion geklappt hat.

Fallstudie — unser A11y-Durchlauf#

Barrierefreiheit ist kein Zustand, den man einmal herstellt, sondern einer, den man halten muss — sonst schleicht sich mit dem nächsten Design-Update wieder ein zu blasser Grauton ein. Deshalb sichern wir sie auf fahoch2.de an mehreren Stellen ab:

• Automatisierte Prüfung im Commit: Unser Pre-Commit-Hook führt neben dem Voice-Linter auch eine jsx-a11y-Prüfung aus. Wer einen Button ohne zugängliche Beschriftung oder ein Bild ohne Alternativtext einbaut, kommt nicht durch den Commit. Das fängt die häufigen Fehler ab, bevor sie überhaupt entstehen.
• Sichtbarer Fokus per :focus-visible: Interaktive Elemente — etwa der „Nach oben"-Knopf auf diesen Insight-Seiten — zeigen bei Tastatur-Bedienung einen deutlichen Fokus-Rahmen in der Akzentfarbe.
• Saubere Semantik: Icons sind als dekorativ markiert (aria-hidden), Buttons tragen eine aria-label-Beschreibung, Hinweis-Boxen eine passende Rolle. Das ist die unsichtbare Hälfte, die ein Screenreader liest.

Das ist kein Perfektions-Anspruch — eine vollständige WCAG-AA-Konformität verlangt zusätzlich manuelle Tests mit echten Screenreadern. Aber die Kombination aus automatischer Prüfung und bewusster Bauweise verhindert, dass die offensichtlichen Fehler überhaupt live gehen. Die Verbindung zur mobilen Bedienbarkeit ist dabei eng: Große Tap-Ziele und klare Fokus-Rahmen helfen denselben Menschen.

Für eine strukturierte Barrierefreiheits-Bestandsaufnahme entlang der WCAG-AA-Kriterien empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

WCAG 2.1 AA ist der praktische Maßstab hinter dem BFSG — und konkreter, als viele denken. Vier Kriterien tragen den größten Teil der Wirkung: Kontrast von mindestens 4,5:1 (messbar), vollständige Bedienbarkeit per Tastatur, ein sichtbarer Fokus-Indikator (nicht per CSS entfernen, sondern gestalten) und ARIA-Live-Regionen, damit Screenreader-Nutzer Status-Meldungen hören. Barrierefreiheit ist kein einmaliger Zustand, sondern muss gehalten werden — am besten über eine automatische Prüfung im Entwicklungs-Prozess plus bewusste Semantik, ergänzt um manuelle Screenreader-Tests für die volle Konformität. Der erste Schritt ist, die offensichtlichen Lücken — Kontrast und Fokus — überhaupt zu messen.

Quellen#

• W3C — WCAG 2.1 Understanding 1.4.3 Contrast (Minimum) — abgerufen 2026-05-29
• W3C — WCAG 2.1 Understanding 2.1.1 Keyboard — abgerufen 2026-05-29
• W3C — WCAG 2.1 Understanding 2.4.7 Focus Visible — abgerufen 2026-05-29
• W3C — Web Content Accessibility Guidelines (WCAG) — abgerufen 2026-05-29
• Barrierefreiheitsstärkungsgesetz (BFSG) — abgerufen 2026-05-29

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung. Eine verbindliche WCAG-Konformitäts-Bewertung verlangt manuelle Prüfung; die konkrete BFSG-Pflicht einer Kanzlei ist im Einzelfall zu klären.