Website-Barrierefreiheit: Ein praktischer Leitfaden zu WCAG 2.2 und barrierefreiem Design

Einleitung

Etwa jeder vierte Erwachsene in der EU lebt mit einer Form von Behinderung. Für viele von ihnen ist die Frage, ob sie Ihre Website nutzen können, keine geringfügige Unannehmlichkeit – es ist der Unterschied zwischen einer eigenständig erledigten Aufgabe und gar keiner.

Barrierefreiheit ist auch zur gesetzlichen Grundlage geworden. Der European Accessibility Act (EAA) gilt ab Juni 2025 für eine breite Palette digitaler Produkte und Dienste. Doch selbst für Teams, die noch nicht von Regulierung betroffen sind, ist der praktische Fall kaum zu widerlegen: bessere Struktur, besseres SEO, größere Reichweite und weniger frustrierte Nutzer.

Dieser Leitfaden erklärt, was Website-Barrierefreiheit in der Praxis bedeutet – fünf konkrete Barrieren, die Ihre Website möglicherweise bereits aufweist, wie das WCAG-2.2-Framework auf reale Entscheidungen einwirkt und eine Checkliste, mit der Sie die Arbeit priorisieren können.

Fünf Barrieren, die Ihre Website möglicherweise bereits aufweist

Die meisten Barrierefreiheitsprobleme im Web lassen sich auf eine kurze Liste wiederkehrender Muster reduzieren. Das sind die fünf Barrieren, die die größte Anzahl von Nutzern ausschließen.

1. Text, der schwer oder gar nicht lesbar ist

Geringer Kontrast, kleine Schriftgrößen und zu komplexe Sprache verstärken sich gegenseitig. Ein Nutzer mit mittelschwerer Sehbeeinträchtigung kann mit einem dieser Probleme umgehen – selten mit allen dreien.

Die praktische Grundlage: Fließtext sollte mindestens 15–16 px gerendert werden, mit einem Kontrastverhältnis von mindestens 4,5:1 gegenüber dem Hintergrund (der WCAG-AA-Schwellenwert). Für großen Text (18 px oder fett 14 px und größer) sinkt der Schwellenwert auf 3:1. Tools wie der WebAIM Contrast Checker ermöglichen die Prüfung jedes Farbpaars in Sekunden.

Einfache Sprache ist schwerer automatisch zu testen, spielt aber für Nutzer mit kognitiven Einschränkungen oder geringerer Lesekompetenz eine wesentliche Rolle. Kurze Sätze, Aktivformulierungen und das Vermeiden von ungeklärtem Fachjargon helfen dabei.

2. Bilder ohne Textalternative

Ein Nutzer, der einen Screen-Reader verwendet, stößt auf ein Bild und hört nichts – oder schlimmer, einen rohen Dateinamen wie img_20240312_banner_v3.jpg vorgelesen.

Die Lösung ist alt-Text: eine kurze, genaue Beschreibung dessen, was das Bild zeigt und, wo relevant, was es kommuniziert. Dekorative Bilder ohne inhaltliche Bedeutung sollten ein leeres alt=""-Attribut tragen, damit Screen-Reader sie überspringen. Bilder mit eingebettetem Text sind besonders problematisch – der Textinhalt sollte im Dokument selbst erscheinen statt in einer Grafik eingebettet sein.

Das ist eine der schnellsten Korrekturen in der Barrierefreiheit und eine der am häufigsten übersehenen. Jedes Bild auf Ihrer Website sollte entweder beschreibenden alt-Text haben oder explizit als dekorativ markiert sein.

3. Videos und Audio ohne Untertitel oder Transkripte

Ein gehörloser oder schwerhöriger Nutzer kann nicht auf reine Audio-Inhalte zugreifen. Ein Nutzer mit kognitiven oder Aufmerksamkeitsschwierigkeiten kann ein schriftliches Transkript möglicherweise weit effektiver verarbeiten als gesprochene Kommentare. Untertitel – synchronisierter Text, der während der Videowiedergabe erscheint – helfen der ersten Gruppe. Vollständige, separat verfügbare Transkripte helfen beiden.

Für Marketing-Inhalte, Produkt-Demos und Webinare sind Untertitel inzwischen breit erwartet. Automatische Untertitelung ist in den meisten Video-Hosting-Plattformen verfügbar, aber automatisch generierte Untertitel für Fachbegriffe und Produktnamen müssen vor der Veröffentlichung geprüft werden.

4. Tastaturbarrieren und unzugängliche Navigation

Nicht alle Nutzer interagieren mit einer Website über eine Maus. Nutzer mit motorischen Einschränkungen, Screen-Reader-Nutzer und Tastaturnutzer navigieren alle über Tab, Enter und Pfeiltasten. Eine Website, die nur mit einem Zeigegerät bedienbar ist, schließt einen erheblichen Teil dieser Gruppe aus.

Tastaturbedienbarkeit hat konkrete Anforderungen: Jedes interaktive Element – Links, Buttons, Formularfelder, Dropdowns, Dialoge – muss per Tab erreichbar sein; die aktuelle Fokusposition muss jederzeit visuell angezeigt werden; Modals dürfen keine Tastaturfallen erzeugen; und die Tab-Reihenfolge muss einer logischen Abfolge folgen, die dem visuellen Layout entspricht.

Dieser Test erfordert fünf Minuten und keine Werkzeuge: Legen Sie die Maus beiseite und navigieren Sie Ihre Website ausschließlich mit Tab, Shift+Tab, Enter und Pfeiltasten. Wenn Sie stecken bleiben, Ihren Fokus nicht sehen oder Elemente nicht aktivieren können, haben Sie Probleme mit der Tastaturbedienbarkeit.

5. Formulare und CAPTCHAs, die unüberwindbare Barrieren schaffen

Formulare sind der Bereich, in dem die Einsätze der Barrierefreiheit am höchsten sind. Kontaktseiten, Login-Flows, Registrierungsmasken und Checkout-Seiten sind funktional – ein Nutzer, der ein Formular nicht ausfüllen kann, kann sein Ziel nicht erreichen.

Traditionelle bildbasierte CAPTCHAs gehören zu den am besten dokumentierten Barrierefreiheitsproblemen im Webdesign. Das Identifizieren verzerrter Buchstaben oder das Auswählen von Bildern mit bestimmten Objekten ist explizit problematisch für Nutzer mit Sehbeeinträchtigungen, kognitiven Einschränkungen und Screen-Reader-Nutzer. Audio-Alternativen helfen – bringen aber eigene Schwierigkeiten für Nutzer mit Hörbeeinträchtigungen mit sich.

WCAG 2.2 adressiert dies direkt. Erfolgskriterium 3.3.8 (Barrierefreie Authentifizierung) fordert ausdrücklich, dass Authentifizierungsprozesse nicht ausschließlich auf kognitiven Funktionstests basieren – eine Kategorie, die Rätsel-CAPTCHAs vollständig umfasst.

Die praktische Lösung besteht darin, challenge-basierte CAPTCHAs vollständig abzulösen. TrustCaptcha führt die Bot-Erkennung unsichtbar im Hintergrund durch, während ein Nutzer ein Formular ausfüllt – kein Rätsel zu lösen, kein Bild zu interpretieren, nichts anzuklicken. Die Verifikation läuft während der normalen Interaktion ab und unterbricht den Formular-Flow für keinen Nutzer. Dieser Ansatz entspricht WCAG 2.2 SC 3.3.8 und beseitigt eine der häufigsten aktiven Barrieren genau dort, wo Nutzer am meisten auf Erfolg angewiesen sind.

Was WCAG 2.2 tatsächlich erfordert

Die Web Content Accessibility Guidelines (WCAG) sind der internationale Standard für die Barrierefreiheit von Web-Inhalten. Vom W3C veröffentlicht, bilden sie die Grundlage für die meisten nationalen und EU-weiten gesetzlichen Barrierefreiheitsanforderungen. Die aktuelle Version ist WCAG 2.2, veröffentlicht im Oktober 2023.

WCAG ist um vier Prinzipien organisiert: Inhalte müssen Wahrnehmbar, Bedienbar, Verständlich und Robust sein – oft als POUR abgekürzt. Jedes Prinzip gliedert sich in Richtlinien, die sich in testbare Erfolgskriterien aufgliedern.

Die Konformitätsstufen legen fest, was „konform” in der Praxis bedeutet:

• Stufe A — das Minimum. Das Nicht-Erfüllen von Stufe-A-Kriterien schafft ernsthafte Barrieren für Nutzer assistiver Technologien.
• Stufe AA — das gesetzliche Ziel in den meisten Ländern, einschließlich der EU-Barrierefreiheitsanforderungen. Das ist das, was „WCAG-konform” typischerweise bedeutet.
• Stufe AAA — die höchste Stufe, gesetzlich nicht vorgeschrieben und für ganze Websites oft nicht praktikabel, aber für spezifische Komponenten erreichbar.

WCAG 2.2 fügte neun neue Erfolgskriterien gegenüber WCAG 2.1 hinzu. Die bedeutendsten Neuerungen für die meisten Teams betreffen die Fokusdarstellung (bessere Sichtbarkeit von Tastaturfokus-Zuständen), barrierefreie Authentifizierung (direkt relevant für CAPTCHA- und Login-Flow-Design) und Alternativen zu Drag-and-Drop. WCAG 2.2 ist rückwärtskompatibel – die Erfüllung von 2.2 AA erfüllt automatisch alle 2.1-AA-Kriterien, mit einer entfernten Ausnahme (4.1.1 Parsing, in 2.2 veraltet).

Für die meisten Business-Websites ist WCAG 2.2 Level AA das angemessene und gesetzlich relevante Ziel.

Eine Barrierefreiheits-Checkliste für heute

Dies ist kein vollständiges Audit – es ist ein praktischer Ausgangspunkt, gegliedert nach Bereichen. Arbeiten Sie ihn von oben durch.

Text und visuelle Darstellung

• Fließtext wird mit mindestens 15 px dargestellt
• Kontrastverhältnis beträgt mindestens 4,5:1 für Fließtext, 3:1 für großen Text
• Text kann im Browser auf 200 % vergrößert werden, ohne Inhalte oder Funktionen zu verlieren
• Kein Inhalt wird als Text in einem Bild dargestellt (außer Logos und dekorativen Grafiken)
• Sprache und Leseniveau sind für die Zielgruppe angemessen

Bilder und Medien

• Jedes bedeutungstragende Bild hat genauen alt-Text
• Dekorative Bilder tragen alt=""
• Videos haben genaue, synchronisierte Untertitel
• Reine Audio-Inhalte haben ein schriftliches Transkript

Tastatur und Navigation

• Alle interaktiven Elemente sind ausschließlich per Tastatur erreichbar und bedienbar
• Fokus-Indikator ist jederzeit klar sichtbar
• Keine Tastaturfallen in Modals, Dialogen oder benutzerdefinierten Komponenten
• Ein „Zur Hauptnavigation springen”-Link erscheint oben auf jeder Seite
• Tab-Reihenfolge entspricht der visuellen Lesereihenfolge

Formulare und Authentifizierung

• Formular-Labels sind über for/id oder aria-labelledby programmatisch mit ihren Eingabefeldern verknüpft
• Fehlermeldungen benennen das fehlerhafte Feld und erklären die Korrektur
• Keine erzwungenen Zeitlimits bei der Formularausfüllung, außer einstellbar
• Kein CAPTCHA, das das Lösen eines Bildrätsels oder einer Audio-Challenge erfordert
• Authentifizierungsflows erfordern keine kognitiven Funktionstests (WCAG 2.2 SC 3.3.8)

Struktur und Semantik

• Überschriften folgen einer logischen Hierarchie ohne übersprungene Ebenen
• Landmark-Regionen werden verwendet (header, nav, main, footer)
• Jede Seite hat ein beschreibendes und eindeutiges <title>-Element
• Links verwenden beschreibenden Ankertext, nicht „hier klicken” oder „mehr lesen”
• Tabellen definieren Kopfzeilen mit <th> und entsprechenden scope-Attributen

Wie man priorisiert, wenn man bei null anfängt

Ein vollständiges Barrierefreiheits-Audit einer ausgereiften Website kann Hunderte von Problemen aufdecken. Der effektivste Ansatz beim Start ohne vorherige Barrierefreiheitsarbeit ist, die Bemühungen nach Wirkung und Aufwand zu sequenzieren statt alles auf einmal lösen zu wollen.

Erste zwei Wochen: Beheben Sie die wirkungsstärksten, aufwandsärmsten Punkte. Das sind fast immer fehlender Bild-alt-Text, Kontrastfehler und fehlende Formular-Label-Verknüpfungen. Führen Sie Ihre Website durch Lighthouse (in Chrome DevTools eingebaut) oder die WAVE-Browser-Erweiterung und beheben Sie alles, was als Fehler markiert ist – nicht als Warnung, als Fehler. Das sind automatisierte Treffer, die schwerwiegende Mängel darstellen.

Nächster Monat: Beheben Sie Tastaturnavigation und Fokus-Management. Das erfordert manuelle Tests und häufig die Zusammenarbeit mit einem Entwickler an interaktiven Komponenten – Modals, Dropdowns, benutzerdefinierte Formularsteuerungen – die automatisierte Tools unvollständig bewerten. Ersetzen Sie in dieser Phase alle rätselbasierten CAPTCHAs – eine wirkungsstarke Änderung mit unkomplizierter technischer Umsetzung.

Laufend: Strukturelle und inhaltliche Barrierefreiheit – Überschriftenhierarchie, Leseniveau, Untertitel für neue Video-Inhalte – wird Teil Ihres Produktionsprozesses statt einer einmaligen Nachbesserung.

Das Erreichen einer WCAG-2.2-AA-Grundlage für eine typische Business-Website erfordert zwei bis vier Wochen fokussierter Entwicklungsarbeit, mehr für Websites mit komplexen interaktiven Komponenten oder großen Inhaltsarchiven.

Fazit

Barrierefreiheit ist kein einmaliges Audit und kein Compliance-Häkchen. Es ist ein kontinuierlicher Qualitätsstandard – und die von WCAG 2.2 Level AA gesetzte Messlatte ist sowohl erreichbar als auch zunehmend erwartet. Die fünf hier beschriebenen Barrieren machen den Großteil der Probleme aus, die Nutzer von funktionierenden Websites ausschließen. Die meisten davon sind schneller zu beheben, als Teams erwarten.

Eine der schnellsten Verbesserungen bei der Formular-Barrierefreiheit ist der Ersatz eines rätselbasierten CAPTCHAs durch eine Lösung für unsichtbare, barrierfreie Verifikation. 👉 TrustCaptcha kostenlos testen — WCAG 2.2 konform, EU-Hosting bei jedem Plan inklusive.