Website barrierefrei gestalten — WCAG 2.1 Anforderungen und technische Umsetzung

Die vier WCAG-Grundprinzipien und ihre technischen Konsequenzen

WCAG 2.1 (Web Content Accessibility Guidelines) strukturiert Barrierefreiheitsanforderungen nach vier Grundprinzipien: wahrnehmbar, bedienbar, verständlich, robust. Jedes Prinzip hat konkrete technische Kriterien auf Konformitätsstufe AA — die Stufe, die das BFSG für private Dienstleister fordert.

In der Praxis erfüllen Websites diese Kriterien in vielen Fällen nicht — auch wenn sie optisch professionell wirken. Die Ursache ist nicht mangelndes Bewusstsein für Barrierefreiheit als Konzept, sondern das Fehlen von Barrierefreiheit als explizitem Anforderungskriterium im Entwicklungs- und QA-Prozess. Was nicht explizit getestet wird, wird typischerweise nicht korrekt umgesetzt.

Optisch klare Darstellung ≠ für Screenreader wahrnehmbar

Interaktive Elemente sichtbar ≠ per Tastatur bedienbar

Formularfelder beschriftet ≠ programmatisch mit Labels verknüpft

Ob diese Konfiguration auf Ihrer Website tatsächlich so umgesetzt ist, lässt sich ohne technische Analyse nicht feststellen. Eine visuelle Prüfung der Website reicht dafür nicht aus.

Wenn diese Prüfung nie durchgeführt wurde, gibt es keine verlässliche Grundlage für die Annahme, dass die Website die Anforderungen erfüllt.

Die Analyse bildet genau diese technische Prüfung ab — tatsächliche Erreichbarkeit, technische Einbindung und reale Lade- und Verarbeitungsprozesse.

Website prüfen

Wahrnehmbar — was das technisch bedeutet

Inhalte müssen für Nutzer wahrnehmbar sein, auch wenn sie bestimmte Sinne nicht nutzen können. Die technischen Anforderungen:

Alternativtexte für Bilder: Jedes <img>-Element muss ein alt-Attribut haben. Dekorative Bilder erhalten alt="". Informative Bilder benötigen einen beschreibenden Text, der die visuell vermittelte Information ersetzt — nicht Dateinamen oder „Bild von".
Farbkontrastwerte: WCAG 2.1 AA fordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (ab 18px fett oder 24px normal) sowie für UI-Komponenten. Diese Werte müssen numerisch gemessen werden — optische Einschätzung ist nicht verlässlich.
Textalternativen für nicht-text-basierte Inhalte: Videos benötigen Untertitel, Audio-Inhalte Transkripte, komplexe Grafiken textliche Beschreibungen.
Keine Informationen nur durch Farbe: Wenn Pflichtfelder in Formularen nur durch rote Farbe markiert sind, ohne zusätzliches Zeichen oder Text, ist das ein WCAG-Verstoß.

Diese Punkte lassen sich nicht zuverlässig manuell prüfen, da sie von technischen Zuständen und Template-Strukturen abhängen.

Bedienbar — was das technisch bedeutet

Die gesamte Website muss ohne Maus nutzbar sein. Das betrifft:

Tastaturnavigation: Alle interaktiven Elemente — Links, Buttons, Formulare, Dropdown-Menüs, Tabs, Modals — müssen per Tab-Taste erreichbar und mit Enter/Space aktivierbar sein. Die Tab-Reihenfolge muss der visuellen und semantischen Reihenfolge der Seite entsprechen.
Sichtbare Fokusmarkierung: Die CSS-Deklaration outline: none oder outline: 0 auf fokussierbaren Elementen ohne Alternativ-Fokusindikator ist ein direkter WCAG-Verstoß. Der Fokuszustand muss für jeden interaktiven Bestandteil visuell erkennbar sein.
Fokus-Management bei Modals: Wenn ein modaler Dialog geöffnet wird, muss der Tastaturfokus in das Modal verschoben werden. Der Fokus darf das Modal nicht verlassen können (Fokus-Trap), bis das Modal geschlossen wird. Beim Schließen muss der Fokus zum auslösenden Element zurückkehren.
Skip-Links: Seiten mit wiederholten Navigationsbereichen müssen einen Skip-Link anbieten, der direkt zum Hauptinhalt springt — relevant für Tastaturnutzer, die nicht jeden Navigationspunkt durchklicken möchten.

Verständlich — was das technisch bedeutet

Sprache im HTML-Tag: Das lang-Attribut im <html>-Element muss die korrekte Sprache angeben (z.B. lang="de"). Screenreader nutzen diesen Wert für die korrekte Aussprache.
Formular-Labels: Jedes Formularfeld muss ein programmatisch verknüpftes Label haben. Das for-Attribut des <label>-Elements muss mit dem id-Attribut des Eingabefelds übereinstimmen. Platzhaltertexte (placeholder) sind kein Ersatz für Labels — sie verschwinden beim Eintippen.
Fehlermeldungen: Wenn ein Formular einen Eingabefehler erkennt, muss die fehlerhafte Eingabe per Text beschrieben werden — nicht nur durch Farbe oder Icon.

Robust — was das technisch bedeutet

Valides HTML: Start- und End-Tags korrekt gesetzt, keine doppelten id-Attribute, keine unerlaubten Verschachtelungen. Screenreader und assistive Technologien basieren auf einem korrekten DOM.
ARIA-Attribute: Wenn native HTML-Elemente nicht verwendbar sind und ARIA-Attribute (role, aria-label, aria-expanded, aria-controls) eingesetzt werden, müssen diese korrekt implementiert sein. ARIA-Attribute auf falschen Elementen oder mit falschen Werten können die Zugänglichkeit verschlechtern, nicht verbessern.
Status-Kommunikation: Dynamische Inhaltsänderungen — Fehlermeldungen, Erfolgshinweise, geladene Inhalte — müssen per aria-live-Region oder verwandten ARIA-Eigenschaften an Screenreader kommuniziert werden.

Warum sich Barrierefreiheitsmängel von außen erkennen lassen

Das HTML-Dokument einer Website ist beim Seitenaufruf öffentlich zugänglich. Automatisierte Testtools können systematisch prüfen: ob img-Elemente alt-Attribute haben, ob label-Elemente korrekt mit Formularelementen verknüpft sind, ob das lang-Attribut gesetzt ist, ob Überschriftenhierarchien vollständig sind. Farbkontrastwerte können durch CSS-Analyse und Renderings gemessen werden.

Diese Prüfungen sind reproduzierbar und dokumentierbar — ohne Zugang zur internen Entwicklungsumgebung. Zuständige Überwachungsbehörden und Beschwerdeführer können genau diese Analyse durchführen, bevor der Betreiber von der Prüfung weiß.

Typische Fehlannahme

Annahme: „Ich verwende ein bekanntes Theme und habe es professionell einrichten lassen — Barrierefreiheit sollte damit kein Problem sein."

Tatsächlich: Barrierefreiheit wird bei Theme-Entwicklung und Website-Projekten in der Regel nicht explizit als Anforderung adressiert — sie entsteht nicht automatisch aus gutem Design. Die meisten Standard-Themes enthalten outline: none für fokussierte Elemente, haben Bilder ohne alt-Attribute, verknüpfen Formularfelder nicht korrekt mit Labels und setzen kein korrektes Fokus-Management in Dropdown-Menüs um. Ohne explizite Barrierefreiheitsprüfung und -anpassung sind WCAG-Verstöße bei Theme-basierten Websites die Regel — nicht die Ausnahme. Und diese Mängel sind von außen durch automatisierte HTML-Analyse erkennbar.

Warum Barrierefreiheit technische Prüfung erfordert

Ob Farbkontraste den WCAG-Schwellenwert erreichen, lässt sich nur durch Messung feststellen. Ob Tastaturnavigation vollständig funktioniert, erfordert einen manuellen Test mit Tab-Navigation durch alle interaktiven Bereiche. Ob ARIA-Attribute korrekt implementiert sind, zeigt sich erst im Accessibility-Tree des Browsers — nicht im sichtbaren Rendering.

Auch automatisierte Tools können nicht alle WCAG-Anforderungen prüfen — schätzungsweise 30–40% der WCAG-Kriterien erfordern manuelle Prüfung. Aber grundlegende Indikatoren — fehlende Alternativtexte, unzureichende Kontraste, fehlende Labels — lassen sich automatisiert erkennen. Wer diese Prüfung nicht vorgenommen hat, kann die Frage „Ist meine Website barrierefrei?" nicht verlässlich beantworten — auch nicht die Person, die das Theme oder die Website entwickelt hat.

Der entscheidende Zustand ist nicht das, was auf der Website sichtbar ist, sondern das, was im Hintergrund technisch passiert. Dieser Zustand ist ohne Analyse nicht zugänglich.