// BFSG 2026
Barrierefreie Website erstellen lassen — BFSG-konform (WCAG 2.1 AA)_
Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) für Anbieter digitaler Produkte und Dienstleistungen im B2C-Bereich. Wer jetzt handelt, vermeidet Bußgelder, schützt sich vor Abmahnungen und erschließt gleichzeitig eine größere Zielgruppe. Als Webentwickler aus Hannover setze ich Barrierefreiheit sauber im Code um — nicht mit oberflächlichen Overlay-Plugins, sondern strukturell und nachhaltig.
Was ist das BFSG — und wen betrifft es?
Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um. Ab dem 28. Juni 2025 müssen Unternehmen, die Verbrauchern digitale Produkte oder Dienstleistungen anbieten, die Anforderungen der WCAG 2.1 auf Konformitätsstufe AA erfüllen. Das betrifft Webshops, Bankportale, Buchungsplattformen, Software-as-a-Service-Anbieter und viele weitere digitale Angebote. Kleinstunternehmen mit weniger als zehn Beschäftigten und einem Jahresumsatz unter zwei Millionen Euro sind unter bestimmten Bedingungen ausgenommen — die Ausnahme muss aber dokumentiert werden. Verstöße können mit Bußgeldern und wettbewerbsrechtlichen Abmahnungen geahndet werden. Dieser Text ist allgemeine Information und keine Rechtsberatung; für konkrete rechtliche Fragen wenden Sie sich bitte an einen Fachanwalt.
Was WCAG 2.1 AA in der Praxis bedeutet
Die Web Content Accessibility Guidelines (WCAG) 2.1 definieren vier Grundprinzipien: wahrnehmbar, bedienbar, verständlich, robust. Auf Stufe AA sind unter anderem folgende Anforderungen relevant: Farbkontrast von mindestens 4,5:1 für normalen Text und 3:1 für großen Text, vollständige Tastaturbedienung ohne Maus, kompatible Semantik für Screenreader (ARIA-Labels, Landmarks, Rollen), barrierefreie Formulare mit klar verknüpften Labels und aussagekräftigen Fehlermeldungen, keine zeitabhängigen Inhalte ohne Steuerelemente, und Untertitel für vorab aufgezeichnete Videoinhalte. Mit Next.js und React lassen sich diese Anforderungen konsequent und wartbar umsetzen, weil semantisches HTML, ARIA und Fokus-Management direkt im Code verankert werden — nicht erst nachträglich aufgeklebt.
Neubau vs. Nachrüstung: Was passt zu Ihnen?
Für viele Unternehmen stellt sich die Frage: Bestehende Website barrierefrei nachrüsten oder neu aufbauen? Beides ist möglich — die richtige Wahl hängt vom Zustand des bestehenden Codes und dem Umfang der Anforderungen ab. Bei einer Nachrüstung beginnen wir mit einem strukturierten Accessibility-Audit: Ich prüfe Kontraste, Tastaturnavigation, Screenreader-Kompatibilität und Formularlogik mit echten Tools (axe, Lighthouse, manuelle Tests) und erstelle einen priorisierten Maßnahmenplan. Anschließend werden die identifizierten Lücken im bestehenden Codebase geschlossen. Bei einem Neubau wird Barrierefreiheit von Anfang an als Designprinzip integriert — mit Next.js, TypeScript und Tailwind CSS, die alle konsequent auf semantisches HTML und gute ARIA-Unterstützung ausgelegt sind. Das Ergebnis ist robuster und langfristig günstiger als nachträgliche Korrekturen.
Vorgehen: Audit → Maßnahmenplan → Umsetzung → Erklärung
Der typische Projektablauf für barrierefreie Websites gliedert sich in vier Phasen. Erstens der Accessibility-Audit: automatisierte Scans mit axe-core und Lighthouse, ergänzt durch manuelle Tastatur- und Screenreader-Tests mit NVDA oder VoiceOver. Zweitens der Maßnahmenplan: priorisierte Liste aller Befunde nach Kritikalität und Umsetzungsaufwand. Drittens die Umsetzung: Implementierung der Maßnahmen im Code — von Kontrastanpassungen über semantisches Markup bis hin zu vollständiger Tastaturnavigation. Viertens die Barrierefreiheitserklärung: Das BFSG verlangt eine öffentlich zugängliche Erklärung, die den Konformitätsstatus dokumentiert. Diese wird nach Abschluss der Umsetzung erstellt und auf der Website veröffentlicht. Für Standard-Websites dauert dieser Prozess in der Regel zwei bis vier Wochen, für komplexere Projekte entsprechend länger.
Warum echter Code besser ist als ein Overlay-Plugin
Accessibility-Overlays und Widget-Plugins werben damit, Barrierefreiheit mit einer einzigen Zeile JavaScript nachzurüsten. Das klingt verlockend — funktioniert aber nicht. Studien und Praxistests zeigen, dass solche Overlays echte Screenreader-Nutzer häufig mehr behindern als unterstützen, und dass sie keine rechtssichere WCAG-Konformität herstellen. Mehrere Klagen gegen Overlay-Anbieter in den USA unterstreichen das. Barrierefreiheit muss im Code verankert sein: in der HTML-Semantik, im Fokus-Management, in der ARIA-Implementierung und in der visuellen Gestaltung. Als Entwickler baue ich das von Grund auf oder rüste es gezielt nach — für eine Website, die nicht nur formal compliant ist, sondern auch für Menschen mit Behinderungen tatsächlich funktioniert.
- WCAG 2.1 AA: Kontrast, Tastatur, Screenreader, Formulare, Fokus-Management
- Next.js + TypeScript: semantisches HTML und ARIA direkt im Component-Design
- Accessibility-Audit mit axe-core, Lighthouse und manuellen Tests
- Barrierefreiheitserklärung nach BFSG-Anforderungen
- Nachrüstung bestehender Websites oder Neubau barrierefrei von Grund auf
- Aus Hannover — remote in ganz Deutschland, Österreich und der Schweiz
Häufige Fragen
Alles, was Sie vor dem Start wissen möchten.
Bereit für eine barrierefreie Website?
Nehmen Sie jetzt Kontakt auf — ich melde mich innerhalb eines Werktags. Das kostenlose 30-minütige Erstgespräch dient dazu, Ihren konkreten Bedarf zu besprechen und einen ersten Überblick über Aufwand und Vorgehen zu geben.
// Kostenloses 30-min Erstgespräch · Hannover & remote (DACH)