Barrierefreie Website planen: praktische Checkliste zu BFSG und WCAG 2.2

Barrierefreiheit lässt sich nicht am Ende eines Website-Projekts mit einem Overlay oder einigen Alt-Texten ergänzen. Sie betrifft Informationsarchitektur, Design, Inhalte, Frontend-Code, Formulare, Dokumente und laufende Redaktion. Wer sie erst kurz vor dem Launch prüft, entdeckt Fehler an Stellen, die bereits teuer miteinander verbunden sind.

In Deutschland sind die Regelungen des Barrierefreiheitsstärkungsgesetzes grundsätzlich seit dem 28. Juni 2025 anzuwenden. Welche Produkte, Dienstleistungen, Ausnahmen und Übergangsregeln im konkreten Fall gelten, muss rechtlich geprüft werden. Dieser Artikel ist deshalb keine Rechtsberatung. Er zeigt, wie ein Webprojekt technisch und organisatorisch auf ein überprüfbares Barrierefreiheitsziel ausgerichtet wird.

BFSG und WCAG nicht gleichsetzen

Das BFSG beschreibt gesetzliche Anforderungen für bestimmte Produkte und Dienstleistungen. Die Web Content Accessibility Guidelines (WCAG) 2.2 des World Wide Web Consortium, kurz W3C, sind technische und inhaltliche Prüfkriterien für zugängliche Webinhalte. WCAG 2.2 ordnet Anforderungen vier Prinzipien zu: wahrnehmbar, bedienbar, verständlich und robust.

Für ein Projekt braucht es daher zwei getrennte Entscheidungen:

1. Welche rechtlichen Anforderungen gelten für das konkrete Angebot?
2. Welches technische Konformitätsziel und welcher Prüfumfang werden vertraglich vereinbart?

Die Aussage „Die Website wird barrierefrei“ ist ohne Ziel, Seitentypen, Erfolgskriterien und Testmethode zu ungenau.

1. Geltungsbereich vor dem Design festlegen

Erstellen Sie eine Liste aller digitalen Bestandteile, die Nutzer benötigen:

• öffentliche Seiten und Sprachversionen;
• Navigation, Suche und Filter;
• Formulare, Rechner und Terminbuchung;
• Registrierung, Login und Kundenkonto;
• Warenkorb, Checkout und Zahlung;
• Videos, Audio und Animationen;
• PDF-Dateien und andere Downloads;
• Consent-Banner, Chat und externe Widgets;
• E-Mails oder Dokumente, die zu einem Prozess gehören.

Externe Komponenten dürfen nicht automatisch aus dem Prüfbereich fallen. Wenn ein Zahlungsfenster, Buchungstool oder Consent-Dialog eine notwendige Handlung blockiert, ist die Nutzerreise trotz zugänglicher Inhaltsseiten unterbrochen.

2. Designsystem mit überprüfbaren Regeln aufbauen

Barrierefreiheit beginnt bei Komponenten, nicht bei einzelnen Screens. Farben, Fokuszustände, Fehlermeldungen und Abstände sollten als wiederverwendbare Regeln definiert werden.

Das Design muss unter anderem beantworten:

• Reicht der Farbkontrast für Text und wichtige Bedienelemente?
• Bleibt Information verständlich, wenn Farbe nicht wahrgenommen wird?
• Ist ein sichtbarer Tastaturfokus für jedes interaktive Element vorgesehen?
• Sind Ziele groß und mit ausreichendem Abstand bedienbar?
• Funktioniert das Layout bei Vergrößerung und schmalen Ansichten?
• Lassen sich Bewegung und automatisch wechselnde Inhalte anhalten?
• Sind Hover-Zustände auch per Tastatur und Touch erreichbar?

Ein Screenshot kann viele dieser Fragen nicht belegen. Zustände wie Fokus, Fehler, geöffnetes Menü oder deaktivierte Schaltfläche gehören ausdrücklich in die Designübergabe.

3. Inhalte für unterschiedliche Wahrnehmung strukturieren

Redaktionelle Zugänglichkeit ist mehr als Alt-Text. Überschriften müssen die Struktur abbilden, Linktexte das Ziel erklären und Formulierungen unnötige Mehrdeutigkeit vermeiden.

Prüfen Sie:

• eine logische Überschriftenhierarchie ohne optisch vorgetäuschte Ebenen;
• beschreibende Linktexte statt mehrfach „Mehr erfahren“;
• Alternativtexte, die Zweck und sichtbaren Inhalt eines relevanten Bildes erfassen;
• leere Alternativtexte für rein dekorative Bilder;
• Untertitel und gegebenenfalls weitere Alternativen für Medien;
• Tabellen nur für echte Datenbeziehungen;
• verständliche Anweisungen, Fehlermeldungen und Pflichtfeldhinweise;
• sprechende Dokumenttitel und zugängliche Downloadformate.

Ein Alt-Text sollte nicht jedes Schlüsselwort der Seite wiederholen. Er ersetzt die Information, die das Bild in seinem jeweiligen Kontext vermittelt.

4. Semantisches Frontend vor ARIA priorisieren

Native HTML-Elemente bringen Rollen und Tastaturverhalten mit. Ein echtes button-Element ist in der Regel belastbarer als ein visuell gestaltetes div, das mit zusätzlichen Skripten wie eine Schaltfläche wirken soll. ARIA, also zusätzliche Attribute zur Beschreibung zugänglicher Benutzeroberflächen, kann Semantik ergänzen, aber fehlerhaftes Verhalten nicht automatisch reparieren.

Die Entwicklung sollte kontrollieren:

• sinnvolle Landmarken für Header, Navigation, Hauptinhalt und Footer;
• korrekte Beschriftungen und Beziehungen von Formularfeldern;
• vollständige Tastaturbedienung in einer logischen Reihenfolge;
• Fokusführung bei Dialogen, Menüs und dynamischen Meldungen;
• verständliche Status- und Fehlermeldungen für assistive Technik;
• keine Tastaturfallen;
• korrekte Sprache des Dokuments und abweichender Textabschnitte;
• stabile Inhalte bei Zoom, Ausrichtung und responsiven Layouts.

5. Formulare als vollständigen Ablauf testen

Ein Formular ist erst zugänglich, wenn nicht nur die Felder, sondern auch Validierung, Fehlerkorrektur und Bestätigung funktionieren. Platzhalter ersetzen keine dauerhafte Beschriftung. Fehlermeldungen sollten das betroffene Feld identifizieren und erklären, wie der Fehler behoben wird.

Testfälle sollten mindestens enthalten:

1. vollständiges Ausfüllen nur mit Tastatur;
2. Absenden mit leeren oder falschen Feldern;
3. Korrektur, ohne bereits gültige Eingaben zu verlieren;
4. verständliche Erfolgsmeldung;
5. Verhalten bei Serverfehler oder Zeitüberschreitung;
6. Prüfung mit Bildschirmleseprogramm an kritischen Stellen.

6. Automatische und manuelle Tests kombinieren

Automatisierte Prüfwerkzeuge finden bestimmte Muster schnell: fehlende Beschriftungen, einige Kontrastprobleme oder ungültige Beziehungen. Sie können jedoch nicht zuverlässig beurteilen, ob ein Alternativtext sinnvoll ist, die Fokusreihenfolge der Aufgabe entspricht oder eine Fehlermeldung verständlich bleibt.

Ein belastbarer Testplan kombiniert:

• automatisierte Prüfung repräsentativer Templates;
• Tastaturtest aller zentralen Abläufe;
• Prüfung mit Vergrößerung und unterschiedlichen Ansichten;
• Stichproben mit Bildschirmleseprogramm;
• manuelle Kontrolle von Struktur, Textalternativen und Fehlermeldungen;
• Tests realer Nutzerinnen und Nutzer, wenn Risiko und Reichweite dies rechtfertigen.

Nicht nur die Startseite sollte geprüft werden. Wählen Sie für jeden wichtigen Seitentyp mindestens ein repräsentatives Beispiel und zusätzlich bekannte Sonderfälle.

7. Abnahme und laufende Verantwortung definieren

Barrierefreiheit kann nach dem Launch durch neue Inhalte, Plugins oder Designänderungen wieder beeinträchtigt werden. Deshalb braucht die Übergabe mehr als einen Prüfbericht.

Zur Abnahme gehören:

• dokumentiertes Ziel und geprüfter Umfang;
• Liste der Testwerkzeuge, Geräte und manuellen Verfahren;
• Befunde mit Schweregrad, URL und reproduzierbarem Testfall;
• Verantwortliche und Fristen für offene Punkte;
• Komponentenregeln im Designsystem;
• Redaktionsanleitung für Überschriften, Links, Bilder und Dokumente;
• Regressionstests für spätere Releases.

Projektcheck vor der Freigabe

Vor dem Launch sollten Sie fünf Fragen mit Belegen beantworten können:

1. Ist der rechtliche und technische Geltungsbereich entschieden?
2. Sind zentrale Abläufe vollständig mit Tastatur bedienbar?
3. Sind Struktur, Beschriftungen, Fokus und Fehlermeldungen verständlich?
4. Wurden automatische Befunde manuell eingeordnet?
5. Gibt es nach der Veröffentlichung Verantwortliche und wiederkehrende Kontrollen?

Barrierefreiheit ist kein einzelnes Zertifikat, das jede künftige Änderung abdeckt. Sie ist eine Qualitätsanforderung an das Produkt und den Prozess. Je früher Ziel, Komponenten und Tests feststehen, desto geringer ist das Risiko, kurz vor dem Launch grundlegende Entscheidungen neu treffen zu müssen.

Weiterführende Primärquellen: Bundesministerium für Arbeit und Soziales zum BFSG sowie W3C, Web Content Accessibility Guidelines (WCAG) 2.2.