Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 für Unternehmen, die Dienstleistungen an Verbraucher erbringen. Technische Grundlage sind die WCAG 2.1 auf Konformitätsstufe AA. Barrierefreiheit ist keine gestalterische, sondern eine technische Eigenschaft — die meisten WCAG-Anforderungen sind im normalen Browser-Rendering nicht sichtbar und lassen sich durch visuelle Inspektion der Website nicht prüfen.
Was das BFSG für Website-Betreiber bedeutet
Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um. Es gilt seit dem 28. Juni 2025 für Unternehmen, die Dienstleistungen an Verbraucher erbringen. Die Ausnahme für Kleinstunternehmen (unter 10 Mitarbeiter und unter 2 Millionen Euro Jahresumsatz) gilt nur für Dienstleister, nicht für Produkthersteller.
Grundlage der technischen Anforderungen sind die WCAG 2.1 auf Konformitätsstufe AA — ein internationaler Standard, der konkrete Implementierungsanforderungen für HTML, CSS, JavaScript und semantische Struktur definiert.
In der Praxis erfüllen Websites diese Anforderungen in vielen Fällen nicht — auch wenn sie optisch professionell wirken und von erfahrenen Agenturen entwickelt wurden. Barrierefreiheit ist keine Eigenschaft, die durch gutes Design entsteht. Sie erfordert explizite technische Implementierung auf Ebene des HTML, der CSS-Konfiguration und des JavaScript-Verhaltens — Schritte, die in vielen Website-Projekten nicht explizit adressiert werden.
Website optisch unauffällig ≠ WCAG 2.1 AA-konform
Design professionell umgesetzt ≠ technisch zugänglich
Barrierefreiheitserklärung vorhanden ≠ tatsächliche Barrierefreiheit gegeben
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.
Ob eine Website grundlegende Barrierefreiheitsanforderungen erfüllt, lässt sich durch visuelle Inspektion nicht feststellen. Diese Anforderungen sind im normalen Browser-Rendering unsichtbar — aber automatisiert und von außen prüfbar.
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üfenWarum Barrierefreiheit eine technische — keine gestalterische — Eigenschaft ist
Barrierefreiheit betrifft nicht das visuelle Erscheinungsbild einer Website, sondern ihre technische Implementierung. Eine Website kann optisch klar, leserlich und professionell wirken — und dennoch für Menschen mit Screenreadern, für Tastaturnutzer oder für Personen mit eingeschränktem Farbsehen erhebliche Barrieren aufweisen.
Die meisten WCAG-Anforderungen sind im normalen Browser-Rendering vollständig unsichtbar: ob Bilder Alternativtexte haben, ob Elemente per Tastatur erreichbar sind, ob Fokuszustände sichtbar markiert werden, ob semantische Struktur korrekt implementiert ist — das zeigt sich erst bei technischer Analyse oder bei Nutzung assistiver Technologien.
Warum Barrierefreiheitsanforderungen in der Praxis in vielen Fällen nicht umgesetzt sind
Standard-Themes, beliebte Page-Builder und CMS-Templates wurden historisch ohne WCAG-Konformität als Ziel entwickelt. Fokusmarkierungen werden typischerweise mit outline: none entfernt — weil sie im Design als störend empfunden werden. Formularfelder werden mit placeholder-Attributen beschriftet anstatt mit programmatisch verknüpften <label>-Elementen. Alternativtexte werden pauschal leer gelassen oder automatisch aus Dateinamen generiert, ohne inhaltliche Bedeutung zu transportieren.
Diese Muster entstehen nicht durch Fehler einzelner Entwickler. Sie entstehen, weil Barrierefreiheit in den meisten Website-Projekten kein explizit adressiertes Anforderungskriterium ist — weder in der Auftragsstellung noch in der Qualitätssicherung. Die BFSG-Pflicht trifft damit Websites, deren gesamter Entwicklungsprozess nicht auf diese Anforderungen ausgerichtet war.
Warum sich Barrierefreiheitsmängel von außen erkennen lassen
Grundlegende WCAG-Anforderungen sind technisch messbar — ohne Zugang zum Quellcode-Repository oder zur internen Entwicklungsumgebung. Das HTML-Dokument einer Website ist beim Seitenaufruf vollständig ö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 Überschriften-Hierarchien vollständig sind, ob Farbkontrastwerte den WCAG-Schwellenwert von 4,5:1 für normalen Text erfüllen.
Diese Prüfungen sind reproduzierbar und dokumentierbar. Zuständige Überwachungsbehörden und Beschwerdeführer können diese Analyse ohne Aufwand durchführen — und die Ergebnisse sind öffentlich nachvollziehbar, bevor der Betreiber von der Prüfung weiß. Diese Prüfung wird systematisch durchgeführt — nicht als Einzelfall, sondern standardisiert und reproduzierbar.
Typische technische Problembereiche
- Fehlende oder falsche Alternativtexte bei Bildern — Screenreader können keinen Kontext liefern
- Deaktivierte Fokusmarkierung durch
outline: nonein CSS — Tastaturnavigation faktisch nicht möglich - Interaktive Komponenten (Dropdown-Menüs, Tabs, Modals) nicht per Tastatur bedienbar
- Farbkontraste unter dem WCAG-Schwellenwert von 4,5:1 für normalen Text
- Formularfelder ohne programmatisch verknüpfte Labels (
for/id-Attribut fehlt) - Fehlende oder fehlerhafte ARIA-Attribute bei custom-implementierten Komponenten
- Keine Barrierefreiheitserklärung und kein Feedbackmechanismus — beides ist nach BFSG Pflicht
Diese Punkte lassen sich nicht zuverlässig manuell prüfen, da sie von technischen Zuständen und Template-Strukturen abhängen.
Typische Fehlannahme
Annahme: „Meine Website ist modern gestaltet und von einer Agentur umgesetzt worden — Barrierefreiheit sollte kein Problem sein."
Tatsächlich: Barrierefreiheit wird bei vielen Website-Projekten nicht explizit adressiert — sie entsteht nicht automatisch durch professionelle Gestaltung. Standard-Themes, beliebte Page-Builder und CMS-Templates erfüllen WCAG 2.1 AA in der Regel nicht vollständig. Viele Agenturen berücksichtigen Barrierefreiheitsanforderungen nur auf explizite Anfrage — und selbst dann werden häufig nur die offensichtlichsten visuellen Kriterien beachtet, während technische Anforderungen wie korrekte Fokusführung, semantische Struktur und ARIA-Implementierung ungeprüft bleiben. Ohne strukturierte Barrierefreiheitsprüfung als expliziten Projektbestandteil sind WCAG-Verstöße die Regel, nicht die Ausnahme.
Warum sich das ohne technische Prüfung nicht einschätzen lässt
Die meisten Barrierefreiheitsprobleme zeigen sich nicht beim visuellen Durchsuchen einer Website. Sie erfordern automatisierte Testtools, Screen-Reader-Tests, Keyboard-Only-Navigation und manuelle Prüfung der semantischen HTML-Struktur.
Ob Kontraste ausreichend sind, muss numerisch gemessen werden. Ob der Fokus beim Öffnen eines Modals korrekt gesetzt wird, muss durch Tastaturnavigation getestet werden. Ob ARIA-Attribute korrekt implementiert sind, zeigt sich nur im Accessibility-Tree des Browsers. Ob alle interaktiven Elemente per Tastatur erreichbar sind, lässt sich nur durch vollständige Tastaturnavigation feststellen — nicht durch visuelle Inspektion.
Ob die Anforderungen des BFSG auf Ihrer Website tatsächlich erfüllt sind, lässt sich ohne strukturierte technische Analyse nicht verlässlich feststellen — auch nicht durch die Agentur, die die Website entwickelt hat, wenn Barrierefreiheit nicht explizit getestet wurde.
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.
Die Analyse bildet genau diese technische Prüfung ab — tatsächliche Erreichbarkeit, technische Einbindung und reale Lade- und Verarbeitungsprozesse.
Website prüfen