Barrierefreiheit ist kein Widget

Seit dem 28. Juni 2025 ist Barrierefreiheit für Teile der privaten Wirtschaft nicht mehr nur gute Absicht. Das Barrierefreiheitsstärkungsgesetz (BFSG) erfasst unter anderem Dienstleistungen im elektronischen Geschäftsverkehr für Verbraucher — typischerweise Onlineshops, Buchungen und ähnliche Bestellstrecken. Parallel dazu fragen Notariate, Praxen und andere Betriebe nach Websites, die Leistungen verständlich erklären und auch ohne Maus nutzbar sind.

Barrierefreiheit beschäftigt mich in Projekten schon länger. Im Blog fehlte dazu bisher der praktische Blick: was ich in Projekten tatsächlich zuerst anschaue, und warum ein nachträglich eingebautes „Accessibility-Widget“ selten die Antwort ist.

Was das Gesetz betrifft — und was nicht

Kurz und ohne Rechtsberatung: Unter das BFSG fallen vor allem Angebote, über die Verbraucher online etwas bestellen, buchen oder einen Vertrag abschließen. Reine Informationsseiten oder rein betriebliche B2B-Tools sind oft nicht erfasst. Für Dienstleistungen gibt es außerdem eine Ausnahme für Kleinstunternehmen (weniger als zehn Beschäftigte und höchstens zwei Millionen Euro Jahresumsatz bzw. Bilanzsumme).

Ob dein Shop oder dein Buchungssystem darunterfällt, lässt sich nicht aus einer Blog-Überschrift ableiten. Das klärt man am konkreten Fall — mit Kammer, Beratung oder interner Prüfung. Als Entwickler plane ich deshalb früh den Anwendungsbereich mit ein, statt am Ende ein Overlay darüberzulegen.

Technisch orientiert sich vieles an bekannten Webstandards: wahrnehmbar, bedienbar, verständlich, robust — in der Praxis oft WCAG 2.1 AA bzw. die zugehörigen Normen für IKT. Für dich als Betreiber heißt das weniger „ein Zertifikat kaufen“, sondern: Navigation, Formulare, Fehlerzustände und Inhalte müssen auch mit Tastatur und Hilfsmitteln funktionieren.

Warum Widgets allein nicht reichen

Ein Button, der Kontraste umschaltet oder Text vorliest, wirkt auf dem Papier wie die schnelle Lösung. In der Praxis prüfe ich etwas anderes: Kann ich den Bestellprozess nur mit der Tastatur durchlaufen? Sind Fehlermeldungen am Feld verständlich? Haben Bilder sinnvolle Alternativtexte? Sind Überschriften und Labels so gesetzt, dass ein Screenreader den Ablauf nachvollziehen kann?

Wenn diese Grundlagen fehlen, kaschiert ein Widget die Lücken höchstens. Manchmal verschlechtert es sogar die Bedienung, weil es eigene Layer, Fokusfallen oder zusätzliche Skripte mitbringt. Barrierefreiheit sitzt in Markup, Struktur und Inhalt — nicht in einem Drittanbieter-Skript, das man „einschaltet“.

Das gilt auch für die Pflicht, Informationen zur Barrierefreiheit selbst barrierefrei bereitzustellen. Eine Erklärung, die nur als unzugängliches PDF liegt oder den tatsächlichen Stand der Seite nicht trifft, hilft niemandem — weder Nutzern noch einer späteren Prüfung.

Was ich in Projekten zuerst prüfe

In Kundenprojekten starte ich selten mit der kompletten WCAG-Checkliste. Ich gehe die Stellen durch, an denen Menschen scheitern oder abspringen:

1. Einstieg und Navigation — Skip-Link, sinnvolle Reihenfolge, sichtbarer Fokus, keine Maus-only-Steuerung.
2. Formulare und Bestellstrecke — Labels, Fehlermeldungen, Pflichtfelder, Bestätigungsschritte. Gerade hier entscheidet sich, ob ein Shop unter dem BFSG überhaupt praxistauglich barrierefrei ist.
3. Inhalt und Sprache — klare Überschriften, lesbare Absätze, erklärte Fachbegriffe. Für ein Notariatsprojekt habe ich ergänzende Fassungen in Leichter Sprache und eine Barrierefreiheitserklärung mitgedacht; die Leistungsseiten sollten für Erstkontakte ebenso funktionieren wie für erfahrene Mandanten.
4. Medien und Kontrast — Alternativtexte, ausreichender Kontrast, reduzierte Bewegung, wenn prefers-reduced-motion gesetzt ist.
5. Migration — bestehende Adressen müssen weiterführen. Bei der Notariats-Website waren das 28 bekannte URLs, jede Weiterleitung einzeln geprüft. Barrierefreiheit ohne Auffindbarkeit ist halb fertig.

Technik wähle ich so, dass diese Punkte nicht gegen das Framework kämpfen. Für die genannte Website etwa Astro mit eigenem Hosting im Container: wenig unnötiges JavaScript auf Inhaltsseiten, klare HTML-Struktur, Betrieb unter Kontrolle. Das ist kein Allheilmittel — aber ein Stack, der zugängliche Seiten nicht aktiv erschwert.

Verständlichkeit ist Teil der Zugänglichkeit

Barrierefreiheit endet nicht bei Kontrastwerten. Wer eine Beurkundung vorbereitet, eine Behandlung sucht oder ein Produkt bestellt, braucht Texte, die den nächsten Schritt erklären. Auf der Branchen-Seite für Notariate steht genau das im Mittelpunkt: sachliche Information statt Werbe-Lautstärke, Kontaktwege mit möglichst wenig beteiligten Diensten, unterschiedliche Vorkenntnisse berücksichtigen.

Leichte Sprache ist dabei kein Deko-Feature. Sie ist eine bewusste zweite Fassung für Menschen, die Fachsprache nicht oder nur mit Mühe lesen. Ob und in welchem Umfang sie sinnvoll ist, hängt von Zielgruppe und Auftrag ab — aber die Frage gehört in die Planung, nicht in den Hotfix nach dem Launch.

Dasselbe Muster gilt für Shops: Produktinformationen, Lieferkosten und Fehlermeldungen müssen am richtigen Punkt stehen. Wer nur das Design poliert und den Checkout unklar lässt, baut eine schöne Hürde.

Was du als nächstes tun kannst

Wenn du einen Shop oder eine buchbare Website betreibst, lohnt ein ehrlicher Durchgang mit Tastatur und — wenn möglich — einem Screenreader. Notiere, wo der Fokus verschwindet, wo Fehler unklar sind und wo Inhalte nur als Bild existieren. Parallel kläre den rechtlichen Anwendungsbereich; ich ersetze hier keine Beratung.

Planst du einen Relaunch oder eine neue Bestellstrecke, bauen wir Barrierefreiheit und Datenschutz von Anfang an ein — nicht als Anhang. Auf danielgtmn.com findest du den Ablauf und die Branchen-Seiten; für ein kurzes Erstgespräch reicht eine Nachricht an hello@danielgtmn.com.

Hinweis: Die rechtlichen Einordnungen in diesem Text geben den Stand nach meiner Kenntnis wieder und ersetzen keine Rechtsberatung.