Barrierefreiheit ist für Websites und Apps kein Randthema mehr. Sie betrifft Nutzererlebnis, Conversion, Markenvertrauen und je nach Angebot auch rechtliche Anforderungen. Spätestens seit dem Barrierefreiheitsstärkungsgesetz, kurz BFSG, beschäftigen sich viele Unternehmen mit der Frage: Muss unsere Website oder App barrierefrei sein, und was bedeutet das technisch?
Dieser Beitrag ersetzt keine Rechtsberatung. Er zeigt aber, wie Unternehmen das Thema pragmatisch und professionell angehen können: mit einem technischen Audit, klaren WCAG-Kriterien, sauberer Umsetzung und laufender Qualitätssicherung.
Was ist das BFSG?
Das BFSG setzt in Deutschland Anforderungen aus dem European Accessibility Act um. Es zielt darauf ab, bestimmte Produkte und Dienstleistungen barrierefrei zugänglich zu machen. Für digitale Teams relevant sind insbesondere Angebote, die über Websites oder Apps erbracht werden können, zum Beispiel bestimmte E-Commerce-, Banking-, Telekommunikations- oder Buchungsdienste.
Wichtig ist: Nicht jede Unternehmenswebsite ist automatisch gleich betroffen. Entscheidend sind Angebot, Unternehmensgröße, Dienstleistung und Einzelfall. Trotzdem ist es riskant, Barrierefreiheit nur als Pflichtfrage zu betrachten. Viele Verbesserungen helfen allen Nutzern: klarere Formulare, bessere Tastaturbedienung, lesbare Kontraste, verständliche Fehlermeldungen und stabile Layouts.
Was hat WCAG mit dem BFSG zu tun?
Die Web Content Accessibility Guidelines, kurz WCAG, sind der internationale technische Standard für barrierefreie Webinhalte. Die W3C Web Accessibility Initiative beschreibt WCAG als Standard für Web Content, inklusive Text, Bilder, Struktur, Code und Interaktion. WCAG 2.2 ist seit Oktober 2023 als W3C Recommendation verfügbar und wurde später aktualisiert.
WCAG basiert auf vier Prinzipien:
- Wahrnehmbar: Inhalte müssen sichtbar, hörbar oder anderweitig erfassbar sein.
- Bedienbar: Nutzer müssen die Oberfläche per Tastatur, Touch, Maus oder Hilfstechnologie bedienen können.
- Verständlich: Inhalte und Interaktionen müssen nachvollziehbar sein.
- Robust: Code muss mit unterschiedlichen Browsern, Geräten und Assistive Technologies funktionieren.
Für Unternehmen ist WCAG deshalb der sinnvollste technische Referenzrahmen, auch wenn die konkrete rechtliche Bewertung im Einzelfall separat erfolgen muss.
Warum Accessibility-Overlays nicht reichen
Viele Anbieter versprechen Barrierefreiheit per Script oder Overlay. Das klingt bequem, löst aber selten die eigentlichen Probleme. Ein Overlay kann keinen semantisch falschen HTML-Aufbau reparieren, keine schlecht geplante Tastaturführung ersetzen und keine unverständlichen Formularfehler in gute UX verwandeln.
Barrierefreiheit entsteht im Produkt selbst:
- in der Informationsarchitektur
- im Designsystem
- in den Komponenten
- im Content
- in Formularen
- in Tests mit Tastatur und Screenreader
- in der laufenden Wartung
Ein Overlay kann höchstens ergänzen. Es sollte niemals die technische Umsetzung ersetzen.
Die wichtigsten technischen Maßnahmen
Semantisches HTML
Screenreader und andere Hilfstechnologien verlassen sich auf Struktur. Überschriften, Listen, Buttons, Links, Formulare und Regionen sollten semantisch korrekt ausgezeichnet sein. Ein klickbares div ist kein Button. Ein Button, der navigiert, sollte oft ein Link sein.
Tastaturbedienung
Jede wichtige Funktion muss ohne Maus erreichbar sein. Fokuszustände müssen sichtbar bleiben. Modale Dialoge brauchen Fokusmanagement. Menüs, Dropdowns und Slider müssen per Tastatur bedienbar sein.
Kontrast und Lesbarkeit
Texte, Icons und UI-Zustände brauchen ausreichenden Kontrast. Das gilt nicht nur für normalen Text, sondern auch für Platzhalter, Fehlermeldungen, deaktivierte Zustände und Fokusrahmen. Schriftgrößen, Zeilenhöhen und Abstände müssen auf mobilen Geräten funktionieren.
Formulare
Formulare sind einer der häufigsten Fehlerbereiche. Jedes Feld braucht ein Label. Fehlermeldungen müssen verständlich sein und dem Feld zugeordnet werden. Pflichtfelder sollten erkennbar sein. Erfolgsmeldungen sollten für Screenreader angekündigt werden.
Alternativtexte
Bilder brauchen sinnvolle Alternativtexte, wenn sie Inhalt transportieren. Rein dekorative Bilder sollten für Assistive Technologies ausgeblendet werden. Produktbilder, Diagramme oder Screenshots brauchen dagegen Kontext.
Motion und Animation
Animationen können Orientierung schaffen, aber auch Probleme verursachen. Nutzer mit reduzierter Bewegungseinstellung sollten respektiert werden. Kritische Informationen dürfen nicht ausschließlich durch Bewegung vermittelt werden.
Performance und Stabilität
Barrierefreiheit und Performance hängen zusammen. Langsame, springende Oberflächen sind für alle störend und für manche Nutzer besonders schwer bedienbar. Stabile Layouts, schnelle Interaktionen und klare Ladezustände verbessern die Zugänglichkeit.
BFSG-Checkliste für Websites und Apps
Diese Checkliste ersetzt kein vollständiges Audit, hilft aber bei der ersten Einordnung:
- Sind alle Seiten per Tastatur bedienbar?
- Ist der Fokus sichtbar und logisch?
- Gibt es eine saubere Überschriftenstruktur?
- Sind Buttons und Links semantisch korrekt?
- Haben Formularfelder Labels und verständliche Fehlermeldungen?
- Werden Statusmeldungen für Screenreader angekündigt?
- Sind Kontraste ausreichend?
- Gibt es Alternativtexte für relevante Bilder?
- Funktionieren Navigation und Formulare auf mobilen Geräten?
- Sind PDF-Downloads oder eingebettete Dokumente zugänglich?
- Gibt es einen Prozess für neue Inhalte und Komponenten?
- Wurden echte Screenreader- und Tastaturtests durchgeführt?
Wenn mehrere Punkte unklar sind, ist ein Accessibility-Audit sinnvoll.
Wie ein professioneller Accessibility-Audit abläuft
Ein gutes Audit besteht nicht nur aus einem automatisierten Tool-Report. Tools finden viele technische Probleme, aber nicht alle. Sie erkennen zum Beispiel fehlende Labels, manche Kontrastprobleme oder ARIA-Fehler. Sie verstehen aber nicht zuverlässig, ob eine Nutzerführung logisch ist, ob Texte verständlich sind oder ob ein komplexer Workflow mit Screenreader wirklich funktioniert.
Ein professioneller Ablauf umfasst:
- Seitenauswahl: wichtigste Templates, Formulare, Checkout- oder Buchungsprozesse.
- Automatisierte Analyse: schnelle Erkennung wiederkehrender technischer Fehler.
- Manuelle Prüfung: Tastatur, Screenreader, Fokusreihenfolge, Semantik.
- Priorisierung: Blocker zuerst, kosmetische Details später.
- Umsetzung: Komponenten, Designsystem und Inhalte korrigieren.
- Regressionstests: sicherstellen, dass Probleme nicht wiederkehren.
- Dokumentation: nachvollziehbare Maßnahmen und offene Risiken.
Barrierefreiheit im Designsystem verankern
Wenn ein Unternehmen mehrere Websites, Apps oder Portale betreibt, sollte Barrierefreiheit nicht pro Seite neu gelöst werden. Sie gehört ins Designsystem: Buttons, Inputs, Modals, Navigation, Tabs, Tooltips und Tabellen müssen zugänglich gebaut und dokumentiert sein.
Das spart langfristig Aufwand. Jede neue Funktion profitiert von geprüften Komponenten. Accessibility wird so nicht zur Nacharbeit, sondern zum Standard.
Häufige Fehler in Unternehmen
Der erste Fehler ist, Barrierefreiheit erst kurz vor Launch zu prüfen. Dann sind Grundsatzentscheidungen bereits getroffen und Korrekturen teuer.
Der zweite Fehler ist, nur die Startseite zu testen. Kritisch sind meist Formulare, Logins, Buchungsstrecken, Tabellen, Filter und dynamische App-Bereiche.
Der dritte Fehler ist, Accessibility als rein technisches Thema zu behandeln. Inhalte, Sprache, Fehlermeldungen und Produktlogik sind genauso wichtig wie ARIA-Attribute.
Für wen lohnt sich das jetzt?
Ein Audit lohnt sich besonders, wenn:
- Ihre Website Leads oder Umsatz generiert.
- Ihre App für Kunden, Patienten, Bewerber oder Mitglieder wichtig ist.
- Sie E-Commerce, Buchung, Login oder digitale Services anbieten.
- Sie ein neues Designsystem planen.
- Sie ohnehin einen Relaunch vorbereiten.
- Sie BFSG-Risiken früh klären möchten.
Auch wenn Ihr Unternehmen nicht unmittelbar betroffen ist, verbessert Accessibility die Qualität des digitalen Produkts. Bessere Formulare, klarere Strukturen und robustere Komponenten zahlen auf Conversion, Supportaufwand und Vertrauen ein.
Wie hafencity.dev unterstützt
Wir verbinden UX/UI Design, Designsysteme und technische Barrierefreiheit. Dadurch bleibt Accessibility nicht im Audit-Dokument stecken, sondern wird im Produkt umgesetzt: in Komponenten, Seiten, Formularen und Workflows.
Wenn Sie wissen möchten, wo Ihre Website oder App steht, starten wir mit einem kompakten Audit und einer priorisierten Maßnahmenliste. Danach kann Ihr Team selbst umsetzen oder wir übernehmen die technische Korrektur.
