Digitale Barrierefreiheit

Das BFSG betrifft grundsätzlich alle Unternehmen, die Produkte und Dienstleistungen an Verbraucher (B2C) anbieten. Dazu gehören Online-Shops, Unternehmenswebsites mit Kontaktformularen, Buchungssysteme, Apps und elektronische Dokumente. Ausgenommen sind nur Kleinstunternehmen (unter 10 Mitarbeiter UND unter 2 Mio. Euro Jahresumsatz) - wobei auch diese bei Neuaufträgen freiwillig barrierefrei sein sollten.

Ab dem 28. Juni 2025 können bei Verstößen gegen das BFSG Bußgelder von bis zu 100.000 Euro verhängt werden. Zudem drohen Abmahnungen durch Wettbewerber oder Verbände. Wichtiger noch: Sie schließen potenzielle Kunden aus - in Deutschland leben 7,8 Millionen schwerbehinderte Menschen, und viele weitere profitieren von barrierefreien Websites (ältere Menschen, temporär Eingeschränkte).

Die Kosten variieren stark je nach aktuellem Zustand Ihrer Website. Eine Analyse und Beratung beginnt bei ca. 500-1.000 Euro. Die Umsetzung kann bei kleineren Websites 2.000-5.000 Euro kosten, bei komplexen Portalen oder Shops auch deutlich mehr. Wichtig: Je früher Sie beginnen, desto kostengünstiger. Bei Neuentwicklungen ist Barrierefreiheit von Anfang an einzuplanen.

Das BFSG verlangt mindestens WCAG 2.1 Level AA. Das sind 50 Erfolgskriterien. Level A (30 Kriterien) sind die absoluten Grundlagen, Level AA (20 zusätzliche Kriterien) die empfohlene Stufe für die meisten Websites. Level AAA (28 weitere Kriterien) ist optional, aber für bestimmte Branchen (Gesundheit, öffentliche Einrichtungen) empfehlenswert.

Automatische Tools wie WAVE, axe oder Lighthouse können ca. 30-40% der WCAG-Kriterien prüfen. Dazu gehören Kontraste, fehlende Alt-Texte, Formular-Labels und einige strukturelle Probleme. Für eine vollständige Prüfung braucht es jedoch manuelle Tests: Tastaturnavigation, Screenreader-Tests, kognitive Verständlichkeit. Wir kombinieren beides in unserem BFSG Compliance Check.

Screenreader lesen Websites für blinde und sehbehinderte Nutzer vor. Für die Kompatibilität sind entscheidend: semantisches HTML mit korrekter Verwendung von header, nav, main, article und footer, eine durchgängige Überschriften-Hierarchie (H1 → H2 → H3 ohne Sprünge), beschreibende Alt-Texte für alle Bilder (nicht „Bild1.jpg“), ARIA-Labels für interaktive Elemente ohne sichtbaren Text, Formulare mit per for-Attribut verknüpften Labels und zugänglichen Fehlermeldungen sowie Skip-Links zum Hauptinhalt. Testen lässt sich das mit echten Screenreadern wie NVDA (kostenlos) oder VoiceOver auf Mac und iOS. Unser Ansatz: Barrierefreiheit von Anfang an einplanen, nicht nachträglich flicken.

Tastaturnavigation ist essentiell für motorisch eingeschränkte Nutzer, die keine Maus bedienen können, für Power-User und für Screenreader-Nutzer. Zur Umsetzung gehören: eine logische Tab-Reihenfolge von oben nach unten und links nach rechts, ein sichtbarer Fokus-Indikator um das fokussierte Element (niemals outline: none), Skip-Links direkt zum Hauptinhalt, mit Pfeiltasten bedienbare Dropdown-Menüs, modale Dialoge mit gefangenem Fokus und Schließen per Escape sowie keine Tastatur-Fallen, die Nutzer nicht wieder verlassen können. Test: Lässt sich die komplette Website nur mit Tab, Enter, Pfeiltasten und Escape bedienen?

Kurze Antwort: Nein. Accessibility-Overlays wie AccessiBe, UserWay oder AudioEye versprechen Barrierefreiheit per JavaScript-Widget, liefern sie aber nicht: Overlays können strukturelle HTML-Probleme nicht lösen, stören häufig die Navigation mit Screenreadern, bergen rechtliche Risiken (Unternehmen wurden trotz Overlay-Nutzung verklagt), verlangsamen die Website durch zusätzliches JavaScript und erzeugen ein falsches Sicherheitsgefühl. Die richtige Lösung ist, Barrierefreiheit von Grund auf in Design und Entwicklung einzuplanen – semantisches HTML, korrekte ARIA-Labels und ausreichende Kontraste kann kein Widget nachträglich reparieren. Wir empfehlen keine Overlay-Widgets und bauen Websites von Anfang an barrierefrei.