Digitale Barrierefreiheit: Warum das BFSG für sauber gebaute Websites kein Problem ist

Seit dem 28. Juni 2025 ist das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft. Viele Unternehmen behandeln es als weiteres Compliance-Thema zwischen DSGVO und TTDSG. Das ist technisch und wirtschaftlich verkürzt. Eine Website, die den Anforderungen genügt, ist in den meisten Fällen einfach eine sauber gebaute Website. Umgekehrt entlarvt das BFSG, wer seine digitale Präsenz auf zusammengeklickten Baukasten-Themes aufgebaut hat. Die Rechnung dafür wird jetzt fällig, parallel in drei Währungen: Bußgelder, verlorene Rankings, verlorene Nutzer.

Was das BFSG konkret verlangt

Das BFSG ist die deutsche Umsetzung des European Accessibility Act (Richtlinie EU 2019/882). Es richtet sich an Hersteller, Händler und Dienstleister, die Produkte oder Dienstleistungen für Verbraucher bereitstellen. Betroffen sind unter anderem Online-Shops, Buchungssysteme, Banking-Portale, Personenverkehrsdienste, elektronische Kommunikationsdienste und E-Book-Plattformen. Reine B2B-Angebote sind ausgenommen, sofern die Zielgruppe eindeutig erkennbar ist. Auch Kleinstunternehmen mit unter zehn Beschäftigten und einem Jahresumsatz unter zwei Millionen Euro fallen nicht in den Anwendungsbereich, zumindest nicht bei Dienstleistungen.

Bei Verstößen drohen laut § 37 BFSG Bußgelder bis zu 100.000 Euro für schwerwiegende Verstöße und bis zu 10.000 Euro für die übrigen Fälle. Marktüberwachungsbehörden, Wettbewerber und anerkannte Verbände können Verfahren einleiten. Für bestehende Dienstleistungen gilt eine Übergangsfrist bis zum 27. Juni 2030, sofern sie auf unveränderter technischer Grundlage weiterbetrieben werden. Wer seine Website in diesem Zeitraum relauncht oder wesentlich überarbeitet, verliert diesen Bestandsschutz sofort.

Warum das Gesetz kein juristisches, sondern ein technisches Thema ist

Technische Grundlage des BFSG sind die Web Content Accessibility Guidelines der W3C, konkret WCAG 2.2 auf Konformitätsstufe AA. Die Kriterien sind keine Geschmacksfragen, sondern prüfbare Engineering-Anforderungen: Farbkontrast von mindestens 4,5:1 für Fließtext und 3:1 für grafische UI-Elemente, vollständige Tastaturbedienbarkeit ohne Fokus-Fallen, sichtbare Fokus-Indikatoren, textuelle Alternativen für Nicht-Text-Inhalte, semantisch korrekte Dokumentstruktur. In Version 2.2 neu hinzugekommen sind unter anderem Anforderungen an die Sichtbarkeit des Fokus (2.4.11), an die Dismiss-Logik von Hover-Inhalten (1.4.13) und an die Remap-Barkeit von Tastenkürzeln.

Keines dieser Kriterien verlangt, dass eine Website weniger schön, weniger animiert oder weniger markenstark sein muss. Sie verlangen, dass unter der sichtbaren Oberfläche echter Code steht, nicht eine Aneinanderreihung generischer div-Container. Ein Button muss ein button-Element sein, eine Überschrift ein h1 bis h6, eine Navigation ein nav. Wenn ARIA-Attribute zum Einsatz kommen, dann ergänzend, nicht als Ersatz für fehlende Semantik. Das ist seit zwanzig Jahren Stand der Technik. Das BFSG macht es jetzt haftungsrelevant.

Der eigentliche Schmerzpunkt: Baukasten-Themes

Wer seine Website auf einem gekauften WordPress-Theme mit Elementor, Divi oder einem vergleichbaren Page-Builder betreibt, hat in den seltensten Fällen eine Chance auf Konformität. Die Ursache liegt in der Architektur. Page-Builder rendern ihre Inhalte als verschachtelte div-Strukturen mit inline-Styles und generieren Overlays, Modals und Slider, deren Fokus-Management und Tastatur-Interaktion nicht zu den WCAG-Kriterien passen. Typische Befunde aus technischen Audits: Buttons sind mit span oder a href='#' umgesetzt, Farbkontraste liegen unter 3:1, Formulare haben keine zugeordneten Labels, Bilder tragen generische Alt-Texte aus dem Dateinamen, Slider fangen den Tastatur-Fokus ein.

Nachrüsten lässt sich das in vielen Fällen nicht wirtschaftlich. Ein Plugin, das ein Accessibility-Widget mit Kontrast-Umschalter und Schriftvergrößerung einblendet, löst das Problem nicht, sondern kaschiert es. Marktüberwachungsbehörden und Verbände prüfen den zugrundeliegenden DOM-Baum, nicht das Overlay. Und selbst wenn ein solches Widget juristisch ausreichte, bliebe das zweite Problem bestehen: Google prüft den gleichen DOM-Baum.

Die SEO-Dividende: Accessibility und Ranking teilen den Code

Sauberes semantisches HTML, korrekte Heading-Hierarchien, beschreibende Link-Texte, zugängliche Bilder mit Alt-Attributen, schnelle Ladezeiten durch schlanke Markup-Strukturen: Das sind gleichzeitig WCAG-Kriterien und SEO-Ranking-Faktoren. Googles Crawler und ein Screenreader sind sich technisch ähnlicher, als es auf den ersten Blick wirkt. Beide lesen das DOM sequenziell, beide sind auf Semantik angewiesen, beide scheitern an endlosen div-Kaskaden ohne Struktur.

Der Zusammenhang zu den Core Web Vitals ist ebenso direkt. Ein schlankes, semantisches Markup lädt schneller, reduziert Layout-Shifts und verbessert den Largest Contentful Paint. Barrierefrei gebaute Formulare haben weniger JavaScript-Overhead und bessere Interaction-to-Next-Paint-Werte. Wer Accessibility als getrenntes Projekt behandelt, das man nachträglich aufsetzt, hat bereits den architektonischen Fehler gemacht.

Unser Vorgehen: Engineering statt Pflaster

Wir bauen Websites in Next.js mit React und TypeScript, komponentenbasiert und ohne Page-Builder. Jede Komponente, vom Button bis zum Slider, wird mit den WCAG-Kriterien als Entwurfsvorgabe entwickelt, nicht als nachträgliche Prüfung. Das bedeutet konkret: Radix UI oder Headless UI als Basis für interaktive Komponenten, die Tastatur-Interaktion und ARIA-Pattern out of the box korrekt abbilden. Semantische HTML-Elemente statt div-Suppe. Farbpaletten, die bereits im Design-System auf Kontrast geprüft sind. Fokus-Indikatoren, die zur Marke passen, statt des Browser-Defaults abzuschalten.

Im technischen Audit prüfen wir Bestandswebsites entlang der WCAG-2.2-AA-Kriterien automatisiert mit axe-core und Lighthouse, ergänzt durch manuelle Tests mit Screenreader und reiner Tastaturnavigation. Die Ergebnisse führen zu einer Priorisierung: Welche Kriterien sind im bestehenden Stack mit vertretbarem Aufwand nachrüstbar, welche erfordern einen Relaunch. Die Antwort ist bei Baukasten-Sites fast immer die zweite. Bei einer in React oder Next.js sauber entwickelten Seite fast immer die erste.

Parallel zum Audit dokumentieren wir den aktuellen Stand in einer Erklärung zur Barrierefreiheit, die selbst den WCAG-Kriterien genügt und auf der Website prominent verlinkt wird. Das ist eine Pflicht aus dem BFSG, wird aber von vielen Kanzlei-Mustern unvollständig abgebildet. Eine korrekte Erklärung benennt die Grundlage (WCAG 2.2 AA), den Stand der Prüfung, nicht konforme Bereiche und einen Feedback-Mechanismus.

Messbare Hebel

• Rechtssicherheit: Bußgeldrisiko bis 100.000 Euro je Verstoß nach § 37 BFSG reduziert sich auf Null, wenn die WCAG-2.2-AA-Kriterien erfüllt sind.
• SEO-Gewinne: Bessere semantische Struktur verbessert Crawlbarkeit und Ranking, insbesondere bei Long-Tail-Queries mit konkreter Nutzerabsicht.
• Core Web Vitals: Schlankes Markup ohne Page-Builder-Ballast verbessert LCP und INP messbar, typische Verbesserungen von 20 bis 40 Prozent sind realistisch.
• Nutzerreichweite: Rund 10 Prozent der deutschen Bevölkerung haben eine schwere Behinderung, weitere 20 Prozent temporäre Einschränkungen. Die Zielgruppe ist größer als viele Marketing-Abteilungen annehmen.
• Konversionsrate: Klare Fokus-Indikatoren, zugängliche Formulare und verständliche Fehlermeldungen reduzieren Abbrüche bei allen Nutzern, nicht nur bei denen mit Einschränkung.

Fazit: Das BFSG ist kein Risiko, sondern ein Qualitäts-Lackmustest

Unternehmen, die jetzt handeln, erhalten drei Ergebnisse gleichzeitig: Sie erfüllen eine gesetzliche Pflicht, sie verbessern ihre Auffindbarkeit bei Google und sie bauen ihre digitale Infrastruktur auf einem Fundament, das auch die nächsten Anforderungen (Core Web Vitals, strukturierte Daten, KI-Crawler, Voice Interfaces) problemlos trägt. Wer dagegen glaubt, mit einem Accessibility-Plugin aus dem Marketplace sei die Sache erledigt, addiert nur technische Schulden. Ein technisches Audit entlang der WCAG 2.2 AA ist in drei bis fünf Werktagen erledigt und liefert eine belastbare Entscheidungsgrundlage für Relaunch oder gezielte Nachbesserung. Ab diesem Punkt ist das BFSG nicht mehr Ihr Problem, sondern das Ihrer Wettbewerber.