BFSG ist da – so machst du eine bestehende Seite regelkonform barrierefrei
Das Barrierefreiheitsstärkungsgesetz gilt seit Juni 2025 – und viele Bestandsseiten sind immer noch nicht konform. Die gute Nachricht: Nachrüsten geht ohne Relaunch. Was das Gesetz fordert, wo Bestandsseiten typischerweise durchfallen und wie du priorisiert vorgehst.
Seit dem 28. Juni 2025 ist das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft. Keine Ankündigung mehr, keine Schonfrist – geltendes Recht. Trotzdem sehen wir in Audits regelmäßig Websites, die weit von der geforderten Barrierefreiheit entfernt sind. Manche Betreiber wissen nicht, dass sie betroffen sind. Andere wissen es und schieben es vor sich her, weil sie einen teuren Relaunch fürchten.
Beides ist riskant – und das mit dem Relaunch ist in den meisten Fällen falsch. Eine bestehende Seite lässt sich gezielt nachrüsten, wenn man weiß, wo man ansetzt. Genau darum geht es in diesem Artikel.
Was das Gesetz fordert
Vorab: Wir sind Entwickler, keine Anwälte – für die verbindliche Einordnung eures Einzelfalls gehört eine Rechtsberatung dazu. Die Grundzüge sind aber klar:
Wer ist betroffen? Das BFSG setzt den European Accessibility Act um und zielt auf Produkte und Dienstleistungen für Verbraucher: Online-Shops, Buchungs- und Terminsysteme, Online-Banking, Telekommunikation, E-Books und mehr. Vereinfacht: Wer online Waren oder Dienstleistungen an Verbraucher verkauft oder anbahnt, fällt in der Regel darunter. Reine B2B-Angebote sind ausgenommen – aber Vorsicht: Sobald auch Verbraucher bestellen können, ist die Trennung dahin.
Wer ist ausgenommen? Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz oder Bilanzsumme – allerdings nur bei Dienstleistungen, nicht beim Inverkehrbringen von Produkten.
Welche Fristen gelten? Für Websites und Online-Shops: keine. Die vielzitierte Übergangsfrist bis 2030 betrifft eng umrissene Fälle, etwa Produkte, die vor dem Stichtag rechtmäßig im Einsatz waren – eine betroffene Website muss seit Juni 2025 barrierefrei sein. Dazu gehört auch eine Erklärung zur Barrierefreiheit, gut auffindbar und selbst barrierefrei.
Was droht bei Verstößen? Bußgelder, Marktüberwachung, dazu Abmahnungen und Unterlassungsklagen von Verbänden. Der eigentliche Schaden ist aber oft ein anderer: Wer nicht barrierefrei ist, schließt zahlende Kunden aus. Barrierefreiheit ist kein Compliance-Häkchen, sondern bessere Software für alle – größere Klickflächen, klarere Formulare, saubere Struktur helfen jedem Nutzer.
Audit zuerst: Erst messen, dann fixen
Der Maßstab ist konkret: Die harmonisierte europäische Norm EN 301 549 verweist für Web-Inhalte auf die WCAG 2.1, Konformitätsstufe AA. Das ist eure Messlatte – nicht das Bauchgefühl und nicht das Overlay-Widget, das Barrierefreiheit per JavaScript "nachrüsten" will. (Von solchen Overlays raten wir ab: Sie beheben die Probleme nicht im Code und fallen in Prüfungen regelmäßig durch.)
Ein belastbares Audit hat zwei Teile:
Automatisiert prüfen Tools wie axe, Lighthouse oder Pa11y die maschinell erkennbaren Kriterien: fehlende Alt-Attribute, Kontrastverhältnisse, fehlende Labels, ARIA-Fehler. Das ist schnell, reproduzierbar – und findet nur einen Teil der Probleme.
Manuell kommt der Rest: Ist die Seite komplett per Tastatur bedienbar? Ergibt die Fokus-Reihenfolge Sinn? Funktioniert das Menü mit dem Screenreader? Sind Fehlermeldungen verständlich? Diese Prüfungen kann kein Tool ersetzen – hier entscheidet sich, ob die Seite wirklich benutzbar ist oder nur den Scanner besteht.
Das Ergebnis ist eine priorisierte Mängelliste: Was verhindert Nutzung komplett (Blocker), was erschwert sie, was ist Kosmetik. Diese Liste ist euer Fahrplan.
Typische Baustellen im Bestand
Nach etlichen Audits können wir sagen: Es sind fast immer dieselben sechs Baustellen.
Tastaturnavigation. Dropdown-Menüs, Modals und Slider, die nur mit der Maus funktionieren. Wer per Tab navigiert, kommt nicht rein – oder nicht wieder raus. Klassiker: das Modal ohne Fokus-Falle, hinter dem die Seite weiterscrollt.
Fokus-States. Irgendwann hat jemand outline: none ins CSS geschrieben, weil der Fokusring "hässlich" war. Damit ist die Tastaturnavigation blind. Der Fix ist heute elegant, denn :focus-visible greift nur bei Tastaturbedienung – Mausnutzer sehen keinen Ring:
:focus-visible {
outline: 3px solid currentColor;
outline-offset: 2px;
}Kontraste. Hellgrauer Text auf Weiß, weiße Schrift auf Hero-Bildern. WCAG AA fordert 4,5:1 für Fließtext, 3:1 für große Schrift und UI-Komponenten. Messen statt schätzen – die Werte lügen nicht.
Alt-Texte. Entweder fehlen sie, oder sie heißen IMG_2394.jpg. Informative Bilder brauchen eine Beschreibung ihrer Funktion, dekorative ein leeres alt="" – damit der Screenreader sie überspringt statt Dateinamen vorzulesen.
Formular-Labels und Fehlermeldungen. Placeholder ist kein Label. Felder brauchen programmatisch verknüpfte Beschriftungen, Fehler müssen am Feld hängen und vorgelesen werden:
<label for="email">E-Mail-Adresse</label>
<input id="email" type="email" autocomplete="email"
aria-invalid="true" aria-describedby="email-error">
<p id="email-error">Bitte gib eine gültige E-Mail-Adresse an.</p>ARIA – zu wenig oder zu viel. Eigenentwickelte Komponenten (Tabs, Akkordeons, Autosuggest) ohne Rollen und Zustände sind für Screenreader unsichtbar. Genauso häufig: ARIA-Attribute, die blind aus Snippets kopiert wurden und mehr kaputt machen als helfen. Die erste Regel von ARIA gilt immer noch – kein ARIA ist besser als falsches ARIA. Natives HTML zuerst.
Nachrüsten ohne Relaunch: priorisiert vorgehen
Die Mängelliste aus dem Audit sortieren wir in zwei Kategorien:
Quick Wins sind Fixes ohne strukturelle Eingriffe: Kontraste anpassen, Fokus-States wiederherstellen, Alt-Texte ergänzen, Labels verknüpfen, Sprachauszeichnung (lang-Attribut) korrigieren. Das sind Stunden bis wenige Tage – und sie räumen oft die Mehrheit der automatisiert gefundenen Fehler ab.
Strukturelle Fixes brauchen mehr: interaktive Komponenten tastaturfähig neu bauen, Formular-Flows überarbeiten, Heading-Struktur und Landmarks geradeziehen, PDF-Dokumente ersetzen. Hier wird pro Komponente geschätzt und in Etappen gearbeitet – beginnend mit den Seiten, über die euer Umsatz läuft: Checkout, Buchungsstrecke, Kontaktformular.
Der Punkt dabei: Barrierefreiheit ist kein Alles-oder-nichts. Jede abgeräumte Barriere hilft real – Nutzern wie Risikobewertung. Ein dokumentierter, priorisierter Plan mit sichtbarem Fortschritt ist auch gegenüber der Marktüberwachung eine andere Ausgangslage als Nichtstun. Ein Relaunch lohnt sich nur, wenn die Seite ohnehin am Ende ihres Lebenszyklus ist – Barrierefreiheit allein ist selten der Grund.
Dranbleiben: A11Y in CI und Definition of Done
Die nachgerüstete Seite ist konform – bis zum nächsten Feature, das ein unzugängliches Modal mitbringt. Barrierefreiheit ist kein Projekt mit Enddatum, sondern eine Qualitätseigenschaft. Zwei Verankerungen sorgen dafür, dass sie es bleibt:
In der CI-Pipeline: Automatisierte A11Y-Checks (z.B. axe-core in den E2E-Tests) laufen bei jedem Merge Request. Neue Kontrastfehler oder fehlende Labels brechen den Build – sie erreichen Produktion gar nicht erst.
In der Definition of Done: Kein Feature ist fertig, das nicht per Tastatur bedienbar ist. Dieser eine Satz im Team-Standard verändert mehr als jedes nachgelagerte Audit – weil er das Problem an der Quelle löst, wo der Fix Minuten kostet statt Tage.
Hotel Edita
Drei Drupal Major-Updates, Hosting-Migration und Barrierefreiheit – Rundum-Modernisierung für das Hotel Edita.
Fazit
Das BFSG ist seit Juni 2025 geltendes Recht, und für betroffene Websites gibt es keine Übergangsfrist. Der Weg zur Konformität ist aber kein Relaunch, sondern ein Prozess: sauberes Audit gegen WCAG 2.1 AA, Quick Wins zuerst, strukturelle Fixes priorisiert nach Nutzung, und Verankerung in Pipeline und Arbeitsweise, damit es so bleibt.
Wisst ihr, wo eure Seite steht? Fordert unseren kostenlosen A11Y-Quickcheck an: Wir prüfen die zentralen Seiten automatisiert und stichprobenartig manuell – ihr bekommt eine ehrliche Ersteinschätzung, wie weit ihr von der Konformität entfernt seid und was die dringendsten Baustellen sind.
Kostenlosen A11Y-Quickcheck anfordern
Unsere Quellen für den Artikel
- Bundesregierung – FAQ zum BFSG
- Bundesfachstelle Barrierefreiheit – FAQ
- § 38 BFSG Übergangsbestimmungen
- IHK Köln – Barrierefreie Websites
- Aktion Mensch – BFSG
Und natürlich unser Projekt für das Hotel Edita
Fachlich geprüft von Simon
Simon hat an diesem Projekt selbst mitentwickelt und diesen Artikel auf technische Richtigkeit geprüft. KI-gestützt geschrieben, von Menschen verantwortet.
Zum Profil von Simon