Warum das BFSG, die WCAG und inklusives Design 2026 zu den wichtigsten Skills für Product & UI/UX Designer gehören
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.
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:
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.
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.
Jeder Inhalt muss so präsentiert werden, dass Nutzer ihn wahrnehmen können — unabhängig von ihren sensorischen Fähigkeiten. Das bedeutet:
Alle Funktionen müssen per Tastatur, Sprachsteuerung oder assistiver Technologie bedienbar sein. In der Praxis:
Inhalte und Bedienung müssen nachvollziehbar sein. Das ist oft weniger eine technische als eine UX-Writing-Frage:
Inhalte müssen mit aktuellen und zukünftigen assistiven Technologien funktionieren. Das ist vor allem ein Entwicklerthema, aber Designer beeinflussen es durch klare Strukturvorgaben:
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.
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:
Zwei Sonderfälle, die im Alltag am häufigsten schiefgehen: Im Dark Mode kippen Kontraste, die im hellen Schema stimmen, weil gesättigte Markenfarben auf dunklem Grund flimmern. Und bei Typografie entscheidet nicht nur der Kontrast, sondern ob die Schrift bei 200 % Zoom und eigener Zeilenhöhe der Nutzer noch trägt.
Formulare sind der Ort, an dem Accessibility-Mängel am teuersten werden: Wer sich nicht registrieren kann, kann auch nicht konvertieren. Wie Formulare insgesamt gebaut sein sollten, steht in Formular-Design für Web und App — hier nur die typischen Barrieren:
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.
Apps haben eigene Regeln, die das BFSG ausdrücklich einschließt. Vier Aspekte, die im Mobile-Kontext besonders zählen:
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.
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.
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".
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.
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.
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.
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.
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.
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.
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. Wie du ein solches System aufbaust, ohne dich zu verheben, steht in Design System entwickeln für kleine Teams.
Eine kurze Checkliste vor jedem Design-Handoff spart viele spätere Diskussionen. Erprobte Items:
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.
Die ethische Begründung ist stark, aber nicht immer die, die Budgets überzeugt. Die wirtschaftliche Argumentation ist es:
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.
Seit das Gesetz gilt, drehen sich die ersten zwanzig Minuten fast jedes Kickoffs um dieselben Fragen. Die Antworten, so kurz wie möglich — und mit dem Hinweis, dass ich Designer bin, kein Jurist. Bei Zweifeln im Einzelfall lohnt sich der Blick in die Leitlinien der Bundesfachstelle Barrierefreiheit oder ein Anwalt.
Wenn ihr über die Website Verträge mit Verbrauchern schließt — also Produkte verkauft, Termine buchbar macht, Abos abschließt — ja. Das Gesetz zielt auf Dienstleistungen für Verbraucher. Eine reine Unternehmenspräsentation ohne Bestell- oder Buchungsfunktion fällt meist nicht darunter. Der Shop-Teil einer sonst informativen Seite aber schon.
Für Pflegeeinrichtungen habe ich die Frage gesondert aufgeschrieben, weil dort die Verunsicherung groß ist und die Antwort meistens „nein" lautet: Gilt das BFSG für Ihre Pflegeeinrichtung? — mit dem Abgrenzungskriterium, der Sonderrolle öffentlicher Träger und dem Grund, es trotzdem zu tun.
Reine B2B-Angebote sind vom BFSG ausgenommen. Zwei Einschränkungen: Sobald ein Angebot auch Verbrauchern offensteht (etwa ein SaaS-Tarif, den auch Privatpersonen buchen können), gilt das Gesetz. Und viele B2B-Kunden — insbesondere öffentliche Stellen — verlangen Barrierefreiheit inzwischen vertraglich, unabhängig vom BFSG.
Für Dienstleistungen gilt eine Ausnahme für Kleinstunternehmen: weniger als zehn Beschäftigte und höchstens zwei Millionen Euro Jahresumsatz oder Bilanzsumme. Für Produkte (Hardware, E-Book-Reader, Selbstbedienungsterminals) gilt die Ausnahme nicht. Und: Die Ausnahme befreit von der Pflicht, nicht vom Nutzen — die Argumente aus Abschnitt 7 gelten weiter.
Das BFSG selbst nennt keine WCAG-Version, sondern verweist auf die europäische Norm EN 301 549, die derzeit WCAG 2.1 auf Level AA abbildet. Praktisch heißt das: 2.1 AA ist die Pflicht, 2.2 AA ist der sinnvolle Maßstab, weil die neuen Kriterien (Fokus-Sichtbarkeit, Zielgröße, Drag-Alternativen) ohnehin gutes Design sind und die nächste Normfassung sie übernehmen wird.
Es gibt keinen pauschalen Bestandsschutz für Websites. Verträge, die vor dem 28. Juni 2025 geschlossen wurden, dürfen bis Juni 2030 unverändert weiterlaufen; Selbstbedienungsterminals haben längere Fristen. Für eine Website, über die heute neue Verträge zustande kommen, gilt das Gesetz aber jetzt — unabhängig davon, wann sie gebaut wurde.
Die Marktüberwachung kann Nachbesserung verlangen, das Angebot untersagen und Bußgelder bis 100.000 Euro verhängen. Realistischer als die Behörde sind aber Beschwerden einzelner Nutzer und Verbände, die Verfahren anstoßen können. Und der leise Schaden: Nutzer, die nicht durchkommen, tauchen in keiner Statistik auf — sie sind einfach weg.
Nein. Die Erklärung ist eine Pflichtangabe, kein Nachweis. Sie muss den Stand ehrlich beschreiben, bekannte Einschränkungen nennen und einen Kontaktweg für Barrieremeldungen bieten. Eine Erklärung, die „vollständig konform" behauptet, während der Checkout nicht per Tastatur bedienbar ist, macht die Sache schlimmer, nicht besser. Wie so eine Erklärung aussehen kann, zeigt die Barrierefreiheitserklärung dieser Website.
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:
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.
Weiterlesen: Die drei Baustellen mit den meisten Barrieren haben eigene Artikel: Formular-Design, Farbsysteme und Datentabellen. Wie kognitive Prinzipien und Barrierefreiheit zusammenspielen, steht in Neurowebdesign. Wie diese Website selbst abschneidet, steht offen in der Barrierefreiheitserklärung.
Ihr müsst eine Website oder App BFSG-konform machen? Mit einem BFSG-Check und WCAG-Audit ab 499 € wisst ihr in wenigen Tagen, wo ihr steht — oder erzähl mir direkt von deinem Projekt.
Transparenzhinweis: Die Bilder in diesem Artikel wurden mit KI erstellt. Der Text wurde mit KI auf Rechtschreibung und Grammatik geprüft. Die redaktionelle Verantwortung liegt bei Jannik Noe.
Jannik Noe
Product & UI/UX Designer aus Hamburg. Ich gestalte und baue Websites, Web-Apps und Software — von der Konzeption bis zum Launch — und zeige Teams im Workshop, wie KI in echte Designprozesse passt.
Mehr über mich →Barrierefreiheit & BFSG
WCAG-Audit mit priorisierter Mängelliste und konkreten Fixes — ab 499 € je nach Umfang, kurzfristig startbar. Auf Wunsch setze ich die Korrekturen in Design und Code um.
Warum Icons einzeln nie auffallen und zusammen immer — und wie du mit Inventur, Raster, Varianten und klaren Beschriftungen ein Set baust, das in Web und App auch nach Jahren noch zusammenhält
Warum der Fehlerfall im Product Design fast immer zuletzt gestaltet wird — und wie du Meldung, Ort, Wiederanlauf und Datensicherheit so zusammenbringst, dass Nutzer:innen weiterkommen statt stehenzubleiben
Warum ein gutes Raster unsichtbar bleibt und seine Abwesenheit sofort auffällt — und wie du Spaltensystem, Abstandsskala und Weißraum so aufbaust, dass sie in Web und App auch nach Monaten noch halten
Du planst eine Website, eine App, ein Redesign — oder möchtest euer Team mit einem AI-UX Workshop voranbringen?
Ich unterstütze Unternehmen dabei, komplexe Anforderungen in klare, nutzerfreundliche Lösungen zu übersetzen.