Viele Unternehmen wissen inzwischen, dass Barrierefreiheit für Websites und Apps relevant ist. Die schwierigere Frage ist praktischer: Was müssen Produkt-, Design-, Content- und Entwicklungsteams jetzt konkret umsetzen?
Dieser Artikel ergänzt unsere BFSG-Checkliste. Dort geht es stärker um Einordnung, Audit und erste Prüfpunkte. Hier geht es um die Arbeit am Produkt: welche Anforderungen in Komponenten, Formularen, Texten, Designsystemen und Release-Prozessen landen sollten.
Wichtig: Dieser Beitrag ist keine Rechtsberatung. Ob und in welchem Umfang eine Website, App oder digitale Dienstleistung rechtlich verpflichtet ist, hängt vom konkreten Angebot, vom Unternehmen und vom Einzelfall ab. Für rechtliche Bewertungen, insbesondere zum Barrierefreiheitsstärkungsgesetz (BFSG), sollten Unternehmen juristischen Rat einholen.
WCAG als technischer Arbeitsstandard
Die Web Content Accessibility Guidelines (WCAG) der W3C Web Accessibility Initiative sind der zentrale technische Referenzrahmen für barrierefreie Webinhalte. Für Websites, Web-Apps und viele hybride App-Oberflächen sind sie auch dann sinnvoll, wenn die rechtliche Bewertung separat erfolgt.
Praktisch heißt das: Unternehmen sollten WCAG nicht nur als Audit-Dokument verstehen, sondern als Produktstandard. Jede neue Komponente, jedes Formular und jeder wichtige Flow sollte gegen die vier WCAG-Prinzipien geprüft werden:
- Wahrnehmbar: Inhalte müssen auch ohne perfekte Sicht, Farbe oder Audio verständlich sein.
- Bedienbar: Funktionen müssen mit Tastatur, Touch, Maus und Hilfstechnologien nutzbar sein.
- Verständlich: Sprache, Navigation, Fehlermeldungen und Interaktionen müssen nachvollziehbar bleiben.
- Robust: Markup und Zustände müssen mit Browsern, Screenreadern und anderen Assistive Technologies funktionieren.
Ein guter interner Standard ist: Neue UI wird nicht als fertig betrachtet, solange Tastaturbedienung, Fokus, Kontrast, Semantik, Formularverhalten und verständliche Inhalte nicht geprüft sind.
Tastaturbedienung zuerst ernst nehmen
Tastaturbedienung ist einer der schnellsten Wege, echte Accessibility-Probleme sichtbar zu machen. Wenn ein Dialog, Menü, Filter, Kalender, Slider oder Checkout-Schritt nicht ohne Maus funktioniert, ist die Oberfläche für viele Nutzer blockiert.
Unternehmen sollten für jede Website und App mindestens diese Regeln verbindlich machen:
- Alle interaktiven Elemente sind per Tastatur erreichbar.
- Die Fokusreihenfolge folgt der visuellen und logischen Struktur.
- Der Fokus ist jederzeit klar sichtbar.
- Modale Dialoge halten den Fokus im Dialog und geben ihn beim Schließen sinnvoll zurück.
- Menüs, Tabs, Akkordeons, Autocomplete-Felder und Dropdowns haben erwartbare Tastatursteuerung.
- Es gibt keine Tastaturfallen, aus denen Nutzer nicht wieder herauskommen.
Das ist keine Spezialdisziplin für den letzten QA-Termin. Designer müssen Fokuszustände gestalten. Entwickler müssen semantische Elemente und korrektes Fokusmanagement verwenden. Tester müssen wichtige Flows ausschließlich mit Tastatur durchlaufen.
Fokuszustände sichtbar und robust gestalten
Fokus ist Navigation. Wer den Fokus entfernt, entfernt Orientierung.
Ein häufiger Fehler ist outline: none ohne gleichwertigen Ersatz. Ein anderer Fehler sind Fokusrahmen, die zwar technisch existieren, aber wegen schwachem Kontrast, abgeschnittenen Containern oder Animationen kaum wahrnehmbar sind.
Gute Fokuszustände sind:
- deutlich sichtbar auf hellen und dunklen Flächen
- nicht nur über Farbe erkennbar
- konsistent über Buttons, Links, Inputs, Cards und komplexe Widgets
- nicht durch
overflow: hiddenabgeschnitten - im Designsystem dokumentiert
Für Apps und komplexe Web-Produkte lohnt sich außerdem ein eigener Fokus-Review für Modals, Toasts, Tab-Navigation, Sidebars, Tabellen, Drag-and-drop-Alternativen und mehrstufige Workflows.
Formulare zugänglich bauen
Formulare entscheiden oft über Umsatz, Leads, Buchungen, Bewerbungen oder Supportfälle. Gleichzeitig sind sie einer der häufigsten Accessibility-Risikobereiche.
Jedes Formular sollte diese Mindestanforderungen erfüllen:
- Jedes Eingabefeld hat ein sichtbares, programmatisch verknüpftes Label.
- Pflichtfelder sind eindeutig erkennbar.
- Hilfetexte sind dem Feld zugeordnet.
- Fehlermeldungen nennen das Problem und, wenn möglich, die Lösung.
- Fehler werden nicht nur farblich markiert.
- Nach dem Absenden gelangen Nutzer logisch zum Fehler oder zur Zusammenfassung.
- Erfolgsmeldungen und Statusänderungen werden für Screenreader angekündigt.
- Autocomplete, Eingabetypen und mobile Tastaturen sind sinnvoll konfiguriert.
Besonders kritisch sind mehrstufige Formulare, Checkout-Prozesse, Login, Passwort-Reset, Datei-Uploads, Datumsfelder und dynamische Validierung. Diese Flows sollten immer manuell mit Tastatur und Screenreader getestet werden.
Kontrast, Typografie und visuelle Zustände prüfen
Kontrast ist nicht nur eine Frage von Fließtext. Unternehmen sollten auch Icons, Platzhalter, Labels, Fehlermeldungen, Status-Badges, Charts, Fokusrahmen, Disabled States und Hover-Zustände prüfen.
Gute visuelle Barrierefreiheit beginnt im Design:
- Textgrößen und Zeilenhöhen funktionieren auf mobilen Viewports.
- Text bleibt lesbar, wenn Nutzer zoomen oder Schrift vergrößern.
- Farbe ist nicht das einzige Signal für Status, Fehler oder Auswahl.
- Interaktive Ziele sind groß genug und haben ausreichend Abstand.
- Inhalte über Bildern oder Videos haben stabile Lesbarkeit.
- Animationen respektieren reduzierte Bewegungseinstellungen.
Wenn ein Designsystem Farb-Tokens nutzt, sollten die erlaubten Kombinationen dokumentiert werden. Ein Button-Token allein reicht nicht. Teams brauchen klare Regeln, welche Text-, Hintergrund-, Rahmen-, Fokus- und Statusfarben zusammen barrierearm funktionieren.
Inhalte verständlich machen
Barrierefreiheit ist nicht nur Code. Unklare Texte können genauso ausschließen wie fehlende Labels.
Für Content-Teams und Produktverantwortliche sind diese Punkte wichtig:
- Überschriften beschreiben den Inhalt der folgenden Sektion.
- Linktexte sind auch ohne umliegenden Satz verständlich.
- Buttons benennen die Aktion konkret.
- Fehlermeldungen erklären verständlich, was zu tun ist.
- Alternativtexte beschreiben relevante Bildinhalte, nicht dekorative Stimmung.
- Tabellen haben klare Überschriften und werden nicht für Layout missbraucht.
- Komplexe Informationen werden strukturiert, nicht in langen Textblöcken versteckt.
SEO und Accessibility arbeiten hier oft in dieselbe Richtung. Klare Überschriften, eindeutige Linktexte und verständliche Seitentitel helfen Nutzern, Screenreadern und Suchmaschinen.
Semantik vor ARIA
ARIA kann helfen, wenn native HTML-Elemente nicht ausreichen. Es kann aber auch viel kaputtmachen, wenn es falsch eingesetzt wird.
Die robuste Grundregel lautet: Erst semantisches HTML, dann ARIA nur dort, wo es wirklich gebraucht wird. Ein echter button bringt Tastaturverhalten und Rolle bereits mit. Ein korrektes label ist besser als nachträglich improvisierte Beschriftung. Eine saubere Überschriftenstruktur ist verlässlicher als visuelle Textgrößen ohne Bedeutung.
Unternehmen sollten deshalb in Code-Reviews auf diese Muster achten:
- Keine klickbaren
div- oderspan-Elemente für echte Aktionen. - Links navigieren, Buttons lösen Aktionen aus.
- Überschriften werden nicht nach Optik, sondern nach Struktur gewählt.
- Landmark-Regionen wie
main,nav,headerundfootersind sinnvoll gesetzt. - ARIA-Attribute werden getestet, nicht nur hinzugefügt.
Accessibility ins Designsystem einbauen
Wenn Barrierefreiheit pro Seite neu gelöst wird, bleibt sie teuer und fehleranfällig. Für Unternehmen mit mehreren Websites, Apps, Portalen oder Kampagnen gehört Accessibility ins Designsystem.
Das Designsystem sollte für zentrale Komponenten dokumentieren:
- Tastaturverhalten
- Fokuszustände
- erlaubte Farb- und Kontrastkombinationen
- Screenreader-Namen und Zustandsansagen
- Fehlermuster und Validierungslogik
- Responsive Verhalten
- Do's and Don'ts für Content und Varianten
Wichtig ist auch die technische Umsetzung. Ein Designsystem ist nur dann wirksam, wenn Buttons, Inputs, Dialoge, Tabs, Tabellen, Navigation und Notifications als geprüfte Komponenten bereitstehen und in Produktteams tatsächlich verwendet werden.
Automatisiert testen, aber manuell entscheiden
Automatisierte Tools sind wichtig. Sie finden fehlende Labels, manche Kontrastfehler, ungültige ARIA-Attribute und strukturelle Probleme schnell. Sie ersetzen aber keine manuelle Prüfung.
Ein sinnvoller Testmix sieht so aus:
- Linting und Komponenten-Tests während der Entwicklung.
- Automatisierte Accessibility-Checks in CI für zentrale Seiten und Komponenten.
- Manuelle Tastaturtests für kritische Flows.
- Screenreader-Tests mit realistischen Aufgaben.
- Browser- und Device-Checks für responsive Layouts.
- Regressionstests nach Änderungen an Designsystem, Navigation und Formularen.
Für Web-Teams sind Tools wie axe, Lighthouse oder Playwright-basierte Checks nützlich. Die Entscheidung, ob ein Flow wirklich verständlich und bedienbar ist, bleibt aber eine manuelle Qualitätsfrage.
Organisation: Verantwortlichkeiten klären
Barrierefreiheit scheitert selten an einem einzelnen fehlenden Attribut. Häufig scheitert sie daran, dass niemand im Prozess zuständig ist.
Unternehmen sollten Accessibility deshalb organisatorisch verankern:
- Produktmanagement priorisiert Accessibility-Anforderungen in Roadmaps.
- Design definiert zugängliche Zustände und Komponenten.
- Entwicklung setzt Semantik, Tastaturverhalten und Tests um.
- Content pflegt klare Sprache, Alternativtexte und Struktur.
- QA prüft Tastatur, Screenreader und Regressionen.
- Recht oder Compliance klärt regulatorische Einordnung mit externer Beratung, wenn nötig.
Praktisch funktioniert das am besten mit einer priorisierten Maßnahmenliste: Blocker zuerst, dann wiederkehrende Komponenten, danach Templates und Content-Migration. So entsteht Fortschritt, ohne dass Teams in einem unübersichtlichen Komplettprojekt stecken bleiben.
Was Unternehmen jetzt priorisieren sollten
Wenn Sie nicht wissen, wo Sie anfangen sollen, ist diese Reihenfolge pragmatisch:
- Kritische Nutzerflows identifizieren: Kontakt, Anfrage, Kauf, Buchung, Login, Suche, Bewerbung.
- Diese Flows per Tastatur und Screenreader testen.
- Formularlabels, Fehlermeldungen, Fokus und Kontrast korrigieren.
- Wiederkehrende Komponenten im Designsystem reparieren.
- Content-Struktur, Linktexte, Alternativtexte und Seitentitel verbessern.
- Automatisierte Checks in Entwicklung und CI ergänzen.
- Accessibility als Akzeptanzkriterium für neue Features aufnehmen.
Das Ziel ist nicht, einmalig ein Dokument abzuhaken. Das Ziel ist ein Produktprozess, in dem neue Barrieren gar nicht erst entstehen.
Rechtlicher Kontext: sorgfältig, aber nicht panisch
In Deutschland setzt das BFSG Anforderungen des European Accessibility Act um. Die Bundesregierung beschreibt das Gesetz als Rahmen für mehr Barrierefreiheit bei bestimmten Produkten und Dienstleistungen. Für digitale Angebote können je nach Geschäftsmodell insbesondere Websites und Apps relevant sein, über die solche Dienstleistungen erbracht werden.
Trotzdem gilt: Nicht jede Website ist gleich betroffen, und die genaue Pflicht hängt vom Einzelfall ab. Unternehmen sollten die rechtliche Einordnung nicht aus Blogartikeln ableiten, sondern bei Bedarf mit qualifizierter Rechtsberatung klären.
Technisch ist die Richtung dennoch klar: Wer heute Websites und Apps nach WCAG-Prinzipien, mit sauberem Designsystem und belastbaren Tests baut, reduziert Risiken und verbessert gleichzeitig die Produktqualität.
