Was Barrierefreiheit auf Websites konkret bedeutet
Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um und gilt seit dem 28. Juni 2025 für Unternehmen, die Dienstleistungen an Verbraucher erbringen — darunter viele gewerbliche Website-Betreiber.
Barrierefreiheit ist in diesem Kontext keine gestalterische Eigenschaft, sondern eine technische Anforderungsdimension. Die Grundlage bilden die WCAG 2.1 auf Konformitätsstufe AA — ein technischer Standard, der präzise definiert, wie Inhalte strukturiert, kodiert und bedienbar sein müssen, damit Menschen mit unterschiedlichen Einschränkungen sie nutzen können.
Der entscheidende Unterschied zum gestalterischen Verständnis: Eine Website kann optisch klar, leserlich und inhaltlich vollständig sein — und dennoch mehrere WCAG-Anforderungen nicht erfüllen. Die Lücken liegen in der technischen Umsetzung, nicht im Design.
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.
Warum das BFSG für Websites jetzt relevant ist
Seit dem 28. Juni 2025 sind Unternehmen, die in den Anwendungsbereich des BFSG fallen, zur Einhaltung der Barrierefreiheitsanforderungen verpflichtet. Die Kleinstunternehmen-Ausnahme (weniger als 10 Mitarbeiter und Jahresumsatz unter 2 Millionen Euro) gilt nur für Dienstleistungsanbieter, nicht für Produkthersteller — und auch dort bestehen Unklarheiten in der Abgrenzung.
Verstöße können von zuständigen Marktüberwachungsbehörden verfolgt werden. Das BFSG sieht für Verstöße Ordnungswidrigkeitenverfahren vor. Wie aktiv die Durchsetzung in der Praxis erfolgt, ist noch nicht vollständig absehbar — das formale Risiko besteht jedoch ab dem Stichtag.
Hinzu kommt eine Pflicht, die viele nicht im Blick haben: Betroffene Anbieter müssen eine Erklärung zur Barrierefreiheit bereitstellen und einen zugänglichen Feedbackmechanismus anbieten. Beides fehlt auf den meisten gewerblichen Websites vollständig — auch auf solchen, die optisch professionell wirken.
Warum Barrierefreiheitsanforderungen in der Praxis in vielen Fällen nicht erfüllt sind
Standard-Themes, Page-Builder und CMS-Templates wurden historisch ohne WCAG-Konformität als Ziel entwickelt. outline: none in CSS ist in vielen Themes Standard — weil die blaue Fokusmarkierung des Browsers optisch störend wirkt. Formularfelder werden mit placeholder-Attributen beschriftet statt mit programmatisch verknüpften <label>-Elementen — weil das Ergebnis visuell identisch wirkt. Alternativtexte werden ausgelassen oder aus Dateinamen generiert — weil es für normale Besucher keinen sichtbaren Unterschied macht.
Diese Muster entstehen strukturell: Barrierefreiheit wurde im Entwicklungsprozess nicht als Anforderung definiert, nicht getestet und nicht abgenommen. Die BFSG-Pflicht trifft damit Websites, deren gesamter Entwicklungsprozess nicht auf diese Anforderungen ausgerichtet war — und bei denen eine nachträgliche Herstellung von Konformität nicht durch einfache Korrekturen, sondern durch systematische Prüfung und Anpassung erfolgen muss.
Warum sich Barrierefreiheitsmängel von außen erkennen lassen
Barrierefreiheitsmängel sind keine internen Konfigurationszustände, die nur mit Zugang zum CMS oder zur Entwicklungsumgebung sichtbar sind. Der HTML-Quellcode einer Website ist öffentlich zugänglich — er kann von jedem Besucher, jedem automatisierten Prüfsystem und jeder Behörde ohne Zugang zur Website-Verwaltung analysiert werden. Ob ein Bild ein korrektes alt-Attribut hat, ob ein Formularfeld programmatisch mit einem Label verknüpft ist, ob outline: none in den Stylesheets gesetzt ist — all das ist im öffentlichen HTML und CSS sichtbar.
Automatisierte Barrierefreiheits-Prüftools wie axe, Lighthouse oder Deque führen genau diese Analysen systematisch durch. Sie protokollieren WCAG-Verstöße reproduzierbar — vor einer möglichen Beschwerde, ohne Ankündigung und ohne Zugang zu internen Systemen. Das Ergebnis ist dokumentierbar: erkannter Verstoß, betroffenes Element, technische Begründung. Für Marktüberwachungsbehörden und Verbände ist das ein vollständig verwertbares Prüfergebnis. Diese Prüfung wird systematisch durchgeführt — nicht als Einzelfall, sondern standardisiert und reproduzierbar.
Warum sichtbare Barrierefreiheit täuscht
Von außen wirkt eine gut gestaltete Website unauffällig. Abstände sind konsistent, Schriftgrößen leserlich, die Farbgebung erscheint kontrastreich. Das genügt nicht.
WCAG 2.1 AA enthält zahlreiche Anforderungen, die im normalen visuellen Browsing vollständig unsichtbar sind:
- Ob Bilder korrekte Alternativtexte haben, sieht kein Besucher beim normalen Surfen
- Ob die Seite vollständig per Tastatur bedienbar ist, fällt nur beim expliziten Test auf
- Ob Fokuszustände sichtbar markiert sind, zeigt sich nur bei Tab-Navigation
- Ob Formulare programmatisch korrekt beschriftet sind, ist nur im Quellcode oder mit Screenreader erkennbar
- Ob Landmarks und Überschriftenhierarchie semantisch korrekt umgesetzt sind, bleibt im Browser-Rendering unsichtbar
Diese Punkte lassen sich nicht zuverlässig manuell prüfen, da sie von technischen Zuständen und Template-Strukturen abhängen.
Eine optisch saubere Website kann dutzende WCAG-Verstöße enthalten — ohne dass ein normaler Besucher einen Hinweis darauf bemerkt.
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üfenTypische technische Fehler bei der Website-Barrierefreiheit
Diese Umsetzungsprobleme sind in der Praxis in vielen Fällen anzutreffen — und für normale Besucher nicht erkennbar.
Fehlende oder falsche Alternativtexte
Das alt-Attribut bei Bildern fehlt vollständig, ist leer obwohl das Bild informativ ist, oder enthält den Dateinamen statt einer inhaltlichen Beschreibung. Screenreader lesen in diesen Fällen entweder nichts vor — oder technische Bezeichnungen, die keinen Informationswert haben. Dekorative Bilder erfordern ein explizit leeres alt="", damit Screenreader sie korrekt überspringen.
Deaktivierte Fokusmarkierung
Viele CSS-Frameworks, Themes und Templates entfernen aktiv die Browser-Fokusmarkierung mit outline: none oder outline: 0, weil der blaue Rahmen gestalterisch störend wirkt. Für Tastaturnutzer bedeutet das: Es ist visuell nicht erkennbar, welches Element gerade fokussiert ist. Navigation und Formularausfüllung ohne Maus sind damit faktisch nicht möglich. Das ist eine der häufigsten und folgenreichsten Zugänglichkeitsbarrieren.
Tastaturnavigation unvollständig oder nicht vorhanden
Dropdown-Menüs, modale Dialoge, Tabs, Akkordeons, Custom-Select-Felder und andere interaktive Komponenten sind bei vielen Websites ausschließlich mit Maus bedienbar. Tastaturnutzer — und damit alle Screenreader-Nutzer — können Teile der Navigation oder des Inhalts nicht erreichen. Besonders betroffen sind Komponenten, die mit JavaScript nachgebaut wurden, ohne das zugehörige ARIA-Keyboard-Interaction-Pattern zu implementieren.
Unzureichende Farbkontraste
WCAG 2.1 AA verlangt ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text gegenüber dem Hintergrund und 3:1 für großen Text sowie Bedienelemente. Farben, die gestalterisch als ausreichend kontrastreich wahrgenommen werden — helles Grau auf Weiß, gedämpfte Markenfarben auf hellem Untergrund — unterschreiten diesen Schwellenwert systematisch. Das menschliche Auge ist kein zuverlässiges Messinstrument dafür; Kontraste müssen numerisch geprüft werden.
Formularfelder ohne korrekte Label-Verknüpfung
Formularfelder, deren sichtbares Label nicht programmatisch mit dem Eingabefeld verknüpft ist (via for/id-Attribut oder aria-labelledby), werden von Screenreadern nicht korrekt angesagt. Platzhaltertexte im Feld (placeholder) ersetzen Labels nicht — sie verschwinden beim Tippen und sind für assistive Technologien unzuverlässig. In der Praxis sind Kontaktformulare, Newsletter-Anmeldeformulare und Bestellformulare in vielen Fällen falsch beschriftet.
Problematische modale Fenster und Overlays
Modale Dialoge müssen beim Öffnen den Fokus einfangen, per Tastatur (Escape-Taste) schließbar sein, den Hintergrund für Screenreader inert setzen und beim Schließen den Fokus an die auslösende Stelle zurückgeben. Cookie-Banner, Lightboxen, Chat-Overlays und andere Popup-Elemente sind in der Praxis in vielen Fällen nicht nach diesem Standard implementiert. Der Fokus wandert in den Hintergrund, Screenreader lesen falsche Inhalte vor, die Schließen-Schaltfläche ist per Tastatur nicht erreichbar.
Fehlende semantische Seitenstruktur
Fehlende oder falsche HTML-Landmark-Elemente (<main>, <nav>, <header>, <footer>, <aside>), übersprungene Überschriftenhierarchien (ein <h1> gefolgt direkt von <h4>), Links ohne erkennbaren Linktext ("Hier klicken", "Mehr") — diese strukturellen Fehler sind für Screenreader-Nutzer erheblich störend, für sehende Besucher aber vollständig unsichtbar. Screenreader navigieren Seiten primär über die semantische Struktur, nicht über das visuelle Layout.
Typische Fehlannahme
Annahme: „Meine Website wurde von einem professionellen Anbieter erstellt und sieht gut aus — sie sollte die Anforderungen erfüllen."
Tatsächlich: Barrierefreiheit ist eine eigenständige technische Anforderung, die explizit adressiert werden muss — und die in Standard-CMS-Themes, Website-Baukästen und professionell entwickelten Agentur-Websites in vielen Fällen nicht korrekt umgesetzt ist. Die meisten Theme- und Template-Anbieter geben keine WCAG-Konformitätsgarantien, weil ihre Produkte diese Anforderungen strukturell nicht erfüllen. outline: none in CSS, placeholder statt programmatisch verknüpfter Labels, fehlende Alternativtexte — diese Muster sind in Standard-Themes die Regel, nicht die Ausnahme. Design-Qualität und technische Barrierefreiheit sind zwei voneinander unabhängige Dimensionen einer Website, und das optische Ergebnis gibt keinen Hinweis auf den Barrierefreiheitsstatus. Ob WCAG 2.1 AA erfüllt ist, ist von außen durch automatisierte HTML-Analyse reproduzierbar feststellbar — und in der Praxis in vielen Fällen nicht gegeben.
Warum sich das ohne technische Prüfung schwer beurteilen lässt
Die meisten WCAG-Anforderungen lassen sich nicht durch visuelles Überprüfen der Website feststellen. Kontraste müssen numerisch gemessen, Tastaturbedienbarkeit durch aktives Testing geprüft, Screenreader-Kompatibilität durch Audiofeedback verifiziert werden.
Selbst Personen, die die Anforderungen kennen, können den tatsächlichen Umsetzungsstand einer bestimmten Website ohne systematische Analyse nicht verlässlich einschätzen. Denn: Die Zugänglichkeit hängt von Hunderten einzelner Entscheidungen in HTML, CSS und JavaScript ab — vom Template, von eingebundenen Drittkomponenten, von nachträglichen Anpassungen, von CMS-Plugin-Interaktionen.
Ob Alternativtexte korrekt gesetzt, Kontraste ausreichend, Fokusführung vorhanden und Formulare korrekt beschriftet sind — das lässt sich ohne strukturierte technische Prüfung nicht verlässlich feststellen. Auch nicht für die Person, die die Website selbst betreibt — und auch nicht für die Agentur, die das Theme oder die Website entwickelt hat, wenn kein explizites Barrierefreiheits-Audit durchgeführt wurde. Wer diese Prüfung nicht vorgenommen hat, kann die Frage „Erfüllt meine Website die BFSG-Anforderungen?" nicht verlässlich beantworten.
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.
Was die Analyse erfasst
Genau hier setzt die Analyse an. Sie prüft grundlegende Barrierefreiheitsindikatoren — Alternativtexte, Kontrastpotenziale, Fokusmarkierungen, semantische Struktur, Formular-Labels — und ordnet die Befunde im Kontext der BFSG-Anforderungen ein.
Das Ergebnis zeigt, welche Bereiche technisch auffällig sind und wo Klärungsbedarf besteht — ohne zu garantieren, ohne zu urteilen.