Barrierefreiheit ist kein Nischenthema mehr
Seit dem 28. Juni 2025 ist in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft — die nationale Umsetzung des European Accessibility Act. Websites, Apps, E-Commerce-Plattformen, Banking-Angebote und viele weitere digitale Produkte müssen seitdem barrierefrei gestaltet sein. Was früher ein Nice-to-have war, ist heute juristisch relevant, wirtschaftlich notwendig und gestalterisch überfällig.
Doch Barrierefreiheit nur als Compliance-Thema zu begreifen, verschenkt ihr Potenzial. Gutes Accessibility-Design macht Produkte für alle Menschen besser: schneller, klarer, robuster. Wer 2026 noch denkt, dass Barrierefreiheit nur eine Minderheit betrifft, arbeitet an einer Realität vorbei — rund 15 % der Weltbevölkerung leben mit einer Behinderung, und situative Einschränkungen (grelles Sonnenlicht, Lärm, Stress, eine gebrochene Hand) betreffen irgendwann jede Nutzerin und jeden Nutzer.
Barrierefreiheit ist wie eine Rampe vor einem Eingang: Sie wurde für Menschen im Rollstuhl gebaut — aber sie hilft auch Eltern mit Kinderwagen, Reisenden mit Rollkoffer und jedem, der schnell reingehen will. Gutes Accessibility-Design ist immer universelles Design.
1. Was das BFSG für Designer wirklich bedeutet
Der rechtliche Rahmen kurz erklärt
Das BFSG verpflichtet Anbieter, bestimmte digitale Produkte und Dienstleistungen für Menschen mit Behinderungen zugänglich zu machen. Betroffen sind unter anderem E-Commerce, Banking, Mobilitäts-Apps, digitale Verträge, E-Books und Messenger-Dienste. Als technischer Standard gelten die WCAG 2.1 Level AA, bei öffentlichen Stellen oft sogar 2.2 AA.
Konkret heißt das für Design-Teams:
- Nachweispflicht: Jeder Anbieter muss eine Barrierefreiheitserklärung veröffentlichen
- Meldepflicht bei Mängeln: Nutzer können Barrieren melden, die innerhalb angemessener Frist behoben werden müssen
- Marktaufsicht: Die zentrale Marktüberwachungsstelle kann prüfen und Sanktionen verhängen
- Bestandsschutz: Nur für bestimmte Produkte, Neuentwicklungen müssen grundsätzlich konform sein
Warum das Designer direkt betrifft
Barrierefreiheit beginnt nicht im Code, sondern im Design. Wer Farbkontraste ignoriert, Touch-Targets zu klein plant oder Interaktionsmuster allein auf Hover aufbaut, produziert Barrieren, die Entwickler später nicht mehr elegant lösen können. Das BFSG macht damit eine ohnehin gute Design-Praxis juristisch verbindlich.
Praxis-Tipp: Accessibility ist kein letzter Prüfschritt vor dem Launch, sondern eine Design-Haltung ab der ersten Skizze. Wer erst in der QA-Phase prüft, baut sich teure Rückbauten ein.
2. Die vier WCAG-Prinzipien als Design-Leitfaden
Die WCAG-Richtlinien folgen vier Grundprinzipien, die sich als Merksatz einprägen: POUR — Perceivable, Operable, Understandable, Robust. Sie sind kein technischer Jargon, sondern ein guter Check für jedes Design.
Wahrnehmbar (Perceivable)
Jeder Inhalt muss so präsentiert werden, dass Nutzer ihn wahrnehmen können — unabhängig von ihren sensorischen Fähigkeiten. Das bedeutet:
- Textalternativen für Bilder: Aussagekräftige Alt-Texte, die die Funktion und nicht nur das Motiv beschreiben
- Ausreichender Farbkontrast: Mindestens 4,5:1 für normalen Text, 3:1 für große Schrift
- Skalierbarkeit: Text muss bis 200 % zoombar sein, ohne dass Layouts zerbrechen
- Keine Farbe allein als Informationsträger: Rot-Grün-Sehschwäche betrifft rund 9 % der Männer — Status nie nur über Farbe signalisieren
Bedienbar (Operable)
Alle Funktionen müssen per Tastatur, Sprachsteuerung oder assistiver Technologie bedienbar sein. In der Praxis:
- Tastaturnavigation: Jeder interaktive Bereich muss ohne Maus erreichbar sein — und der Fokusring muss sichtbar bleiben
- Genügend Zeit: Keine zwangsweisen Timeouts ohne Warnung und Verlängerungsoption
- Keine Epilepsie-Trigger: Nichts, was häufiger als dreimal pro Sekunde blitzt
- Gesten mit Alternativen: Komplexe Gesten in Apps (Pinch, Swipe-Kombinationen) brauchen immer eine einfachere Alternative
Verständlich (Understandable)
Inhalte und Bedienung müssen nachvollziehbar sein. Das ist oft weniger eine technische als eine UX-Writing-Frage:
- Klare Sprache: Kurze Sätze, aktive Formulierungen, keine überflüssigen Fachbegriffe
- Konsistente Navigation: Wiederkehrende Elemente immer an derselben Stelle
- Verständliche Fehlermeldungen: „E-Mail-Adresse ohne @ ist ungültig" ist hilfreich, „Error 422" ist es nicht
- Vorhersehbares Verhalten: Keine Aktion darf unerwartet ausgelöst werden, etwa ein Formular, das beim Klick auf ein Dropdown abgeschickt wird
Robust (Robust)
Inhalte müssen mit aktuellen und zukünftigen assistiven Technologien funktionieren. Das ist vor allem ein Entwicklerthema, aber Designer beeinflussen es durch klare Strukturvorgaben:
- Semantische Struktur: Headings in logischer Hierarchie (H1 → H2 → H3), keine Hierarchie-Sprünge
- ARIA-Rollen dort, wo HTML nicht ausreicht: Bewusst einsetzen, nicht als Pflaster
- Komponenten-Namen: Jeder Button sollte einen sprechenden Namen haben — nicht nur ein Icon
Merksatz für den Alltag: Wenn ein Screen die POUR-Prinzipien erfüllt, ist er nicht nur barrierefrei — er ist meistens auch klarer, robuster und einfacher zu entwickeln.
3. Accessibility im Webdesign: Die häufigsten Baustellen
Farben und Kontraste
Die meisten Barrieren im Web sind unsichtbare Entscheidungen aus dem Styleguide: hellgrauer Hilfstext auf weißem Hintergrund, pastellfarbene Disabled-States, CTA-Buttons mit 2,8:1 Kontrast. Ein kurzer Check im Contrast-Checker bei jeder Farbentscheidung kostet Sekunden und rettet ganze Seiten vor Unbenutzbarkeit.
Praktische Werkzeuge:
- Figma-Plugins: „A11y — Color Contrast Checker" oder „Stark" prüfen Kontraste live im Design
- Browser-Tools: Chrome DevTools Accessibility-Panel, axe DevTools oder WAVE-Toolbar
- Farbsystem-Check: Lege für jedes Paar Textfarbe × Hintergrund den Kontrastwert in den Design-Tokens fest
Formulare — die größte Fehlerquelle
Formulare sind der Ort, an dem Accessibility-Mängel am teuersten werden: Wer sich nicht registrieren kann, kann auch nicht konvertieren. Die typischen Fehler:
- Label-freie Felder: Platzhaltertext ist kein Label — er verschwindet bei Eingabe und fällt Screenreadern oft komplett weg
- Unklare Fehlermeldungen: „Bitte ausfüllen" hilft niemandem — sag, was fehlt und warum
- Fehlende Fokus-Styles: Wer Default-Fokusringe entfernt, ohne Alternative zu bauen, zerstört die Tastaturnavigation
- Zeitdruck in Captchas: reCAPTCHA v2 mit Bilder-Rätsel scheitert bei vielen kognitiven Einschränkungen — Alternativen wie hCaptcha Accessibility oder invisible Captchas nutzen
Navigation und Landmarks
Screenreader-Nutzer navigieren über Landmarks — header, nav, main, footer, aside. Wenn Designer ihre Layouts nicht in diesen Begriffen denken, springt der Nutzer durch ein strukturloses Chaos. Die Design-Datei sollte schon zeigen, welche Bereiche semantisch zusammengehören.
4. Accessibility im App-Design: Mobile spezifisch denken
Apps haben eigene Regeln, die das BFSG ausdrücklich einschließt. Vier Aspekte, die im Mobile-Kontext besonders zählen:
Touch-Targets und Gesten
Apple empfiehlt mindestens 44×44 pt, Google 48×48 dp als Mindestgröße für Touch-Targets. Das ist keine Formalie — für Menschen mit motorischen Einschränkungen (und für jeden mit Handschuhen oder beim Zugfahren) ist das der Unterschied zwischen Nutzung und Aufgeben. Komplexe Gesten brauchen immer eine Button-Alternative.
Dynamic Type und Zoom
iOS und Android bieten systemweite Schriftgrößen-Einstellungen. Apps müssen diese Einstellung respektieren — Layouts, die bei 200 % Schriftgröße zerbrechen, sind nicht barrierefrei. Das bedeutet praktisch: Auto Layout in Figma mit fließenden Komponenten und das Vermeiden von festen Textgrößen.
VoiceOver und TalkBack
Screenreader auf Mobile funktionieren anders als auf Desktop. Jede interaktive Komponente muss ein Accessibility Label tragen, das in der Nutzersprache erklärt, was sie tut — nicht was sie technisch ist. Ein Herz-Icon sollte nicht „Herz-Button" heißen, sondern „Zu Favoriten hinzufügen".
- Label: Was tut dieses Element? („Menü öffnen")
- Hint: Wie lang muss ich es drücken? Welche Geste? Optional, aber hilfreich bei ungewöhnlichen Interaktionen
- Traits: Ist es ein Button, ein Link, ein Schalter? Hilft Screenreadern beim Interpretieren
Reduzierte Bewegung
Viele Nutzer aktivieren „Bewegung reduzieren" in den Systemeinstellungen — wegen Vestibular-Störungen, Migräne oder einfach Präferenz. Parallax-Scrolling, Auto-Play-Videos und aufwendige Seitenübergänge müssen sich an diese Einstellung anpassen (prefers-reduced-motion im Web, entsprechende APIs in iOS/Android).
Designer-Tipp: Baue jede Animation zweifach — einmal in voller Opulenz, einmal als minimaler Fade. Das ist schnell gedacht, leicht umgesetzt und rettet Nutzer vor echter Übelkeit.
5. Häufige Mythen und ihre Auflösung
„Barrierefreiheit sieht langweilig aus"
Das stimmt einfach nicht. Marken wie Apple, Microsoft oder das schwedische Designstudio Island beweisen seit Jahren, dass Accessibility und herausragende Ästhetik zusammen funktionieren. Die Annahme, man müsse für Barrierefreiheit auf Design-Qualität verzichten, ist fast immer eine Ausrede für nicht genug gedachte Entscheidungen.
„Das machen wir in Phase 2"
Phase 2 kommt nie. Accessibility nachträglich einzubauen, ist drei- bis fünfmal teurer als es von Anfang an zu planen — und funktioniert selten wirklich gut. Komponenten, die nicht zugänglich konzipiert wurden, müssen oft komplett neu geschrieben werden.
„Wir haben keine behinderten Kunden"
Doch. Man sieht sie nur nicht in den Analytics, weil sie nicht durchgekommen sind. Das Curb-Cut-Effekt-Prinzip zeigt seit Jahrzehnten: Features, die für Menschen mit Behinderungen gebaut wurden, werden von allen Nutzern wertgeschätzt — von Voice Control über Untertitel bis hin zum Dark Mode. Wer inklusiv baut, baut besser für alle.
„Ein Accessibility-Overlay löst das Problem"
Nein. Overlay-Tools wie AccessiBe oder UserWay versprechen Compliance auf Knopfdruck, liefern aber in der Praxis selten echte Barrierefreiheit — und schaffen oft neue Probleme. Die Accessibility-Community und inzwischen auch Gerichte haben diese Tools mehrfach kritisiert. Nichts ersetzt sauber gebaute Komponenten.
6. So integrierst du Accessibility in deinen Designprozess
Ab der Discovery mitdenken
Accessibility beginnt nicht in Figma, sondern in der Recherche. Beziehe Menschen mit verschiedenen Fähigkeiten in deine User Research ein — Nutzer mit Screenreader, mit motorischen Einschränkungen, mit kognitiven Besonderheiten. Die Erkenntnisse verändern die gesamte Konzeption.
Design-System als Accessibility-Multiplikator
Ein durchdachtes Design-System ist der stärkste Hebel: Wenn deine Button-Komponente einmal richtig gebaut ist (Kontrast, Fokus, Label, Tastatur, Screenreader), multipliziert sich diese Qualität über jedes Produkt. Umgekehrt wirken schlechte Accessibility-Defaults genauso — nach unten.
- Tokens mit Accessibility-Intent: „text-on-primary" statt nur „white"
- Dokumentierte Do's and Don'ts: In jeder Komponente ein Beispiel, wann sie nicht eingesetzt werden soll
- State-Vollständigkeit: Default, Hover, Focus, Active, Disabled, Error — nichts weglassen
- Code-Design-Parität: Wenn Entwickler zugängliche Komponenten bauen, müssen Designer sie auch so benutzen
Checklisten und Audits
Eine kurze Checkliste vor jedem Design-Handoff spart viele spätere Diskussionen. Erprobte Items:
- Sind alle Text-Kontraste ≥ 4,5:1 (große Schrift ≥ 3:1)?
- Ist jede Interaktion auch per Tastatur denkbar?
- Hat jedes Icon-only-Element ein klares Label?
- Sind Fehler- und Erfolgszustände nicht nur farblich markiert?
- Funktioniert das Layout bei 200 % Text-Zoom?
Testen mit echten Nutzern
Automatisierte Tools wie axe, Lighthouse oder WAVE decken etwa 30–40 % aller Accessibility-Probleme auf. Der Rest wird nur durch manuelles Testen und durch echte Nutzer sichtbar. Plane in größeren Projekten mindestens einen Usability-Test mit Screenreader-Nutzern ein — die Erkenntnisse sind unbezahlbar.
7. Der Business-Case: Warum Accessibility sich rechnet
Die ethische Begründung ist stark, aber nicht immer die, die Budgets überzeugt. Die wirtschaftliche Argumentation ist es:
- Größerer Markt: In Deutschland leben über 7,8 Millionen Menschen mit anerkannter Behinderung — ein Markt, der bei Nichtzugänglichkeit verloren geht
- Bessere SEO: Semantisch saubere Seiten, korrekte Heading-Hierarchie und gute Alt-Texte korrelieren direkt mit Suchmaschinen-Sichtbarkeit
- Höhere Conversion: Klare Sprache, gute Kontraste und fehlerfreie Formulare wirken für alle
- Geringeres Prozessrisiko: Das BFSG sieht Bußgelder bis zu 100.000 Euro vor — Klagen einzelner Nutzer kommen hinzu
- Markenwert: Inklusive Produkte ziehen Talente an, stärken Trust und erzeugen positive Presse
Faustregel: Jeder Euro, den du früh in Accessibility investierst, spart dir später etwa drei Euro in Rückbau, Support und Rechtskosten — und eröffnet gleichzeitig neue Nutzergruppen.
Fazit
Barrierefreiheit ist 2026 kein optionales Feature, sondern eine Grundvoraussetzung professionellen Designs. Das BFSG macht sie rechtlich verbindlich — aber die eigentliche Motivation sollte größer sein: Menschen in ihren realen Fähigkeiten und Einschränkungen ernst zu nehmen.
Die wichtigsten Takeaways:
- Rechtlicher Rahmen: Seit Juni 2025 sind viele digitale Produkte in Deutschland gesetzlich zur Barrierefreiheit verpflichtet
- POUR als Leitplanke: Wahrnehmbar, bedienbar, verständlich, robust — vier Prinzipien für jeden Screen
- Design-Entscheidungen zählen: Kontraste, Touch-Targets, Fokus-Styles und Struktur werden im Design festgelegt, nicht im Code
- Mobile braucht extra Aufmerksamkeit: Dynamic Type, VoiceOver-Labels und reduzierte Bewegung sind Pflichtkost
- Curb-Cut-Effekt: Was für Menschen mit Behinderungen gebaut wird, macht Produkte für alle besser
- Business-Case: Größerer Markt, bessere SEO, höhere Conversion, weniger Rechtsrisiko
Wer Barrierefreiheit als integralen Bestandteil der Gestaltung begreift — nicht als Compliance-Aufgabe am Ende — baut bessere Produkte. Für alle. Und das ist schließlich der Kern guten Designs.