Bedienoberflächen gestalten mit Designsystem, Barrierefreiheit und Tests

Das Wichtigste auf einen Blick

Normen und Pflichten: BITV 2.0, WCAG 2.2 und DIN EN ISO 9241

Wer Bedienoberflächen gestalten will, die auch einer Prüfung standhalten, muss drei Ebenen auseinanderhalten: die internationale Norm, die technische Spezifikation und die nationale Verordnung. Jede Ebene regelt etwas anderes. Die Norm beschreibt Vorgehen und Grundsätze. Die WCAG liefern einzelne, prüfbare Kriterien. Die BITV macht diese Kriterien für bestimmte Stellen verbindlich.

Die WCAG 2.2 hat das W3C im Oktober 2023 veröffentlicht. Sie kennt drei Konformitätsstufen: A, AA und AAA. In Europa ist AA der übliche Maßstab, weil die EN 301 549 darauf verweist. Neu gegenüber der Version 2.1 sind unter anderem die Kriterien Zielgröße mit mindestens 24 mal 24 CSS-Pixeln, Fokus nicht verdeckt, redundante Eingabe und barrierefreie Authentifizierung.

Das frühere Kriterium 4.1.1 Parsing wurde gestrichen. Für die Praxis bleiben die bekannten Hürden entscheidend: Kontrast von mindestens 4,5 zu 1 für Fließtext, 3 zu 1 für grafische Elemente, Bedienbarkeit ausschließlich per Tastatur, verständliche Beschriftungen und eine Fokusreihenfolge, die der Leserichtung folgt.

DIN EN ISO 9241 beschreibt, wie Mensch und System zusammenarbeiten sollen. Vier Teile sind für die Oberflächengestaltung besonders relevant:

Der Überblick des DIN über Normen und Standards ordnet ein, wie internationale und nationale Normen zusammenwirken. Wer wissen will, wie eine DIN-Norm entsteht und wann sie gilt, findet das Verfahren dort beschrieben.

Die BITV 2.0 gilt für öffentliche Stellen des Bundes. Technisch verweist sie auf die EN 301 549. Länder erlassen eigene Barrierefreiheitsverordnungen, Kommunen fallen je nach Landesrecht darunter. Ob eine Anwendung betroffen ist, hängt also von der Trägerschaft ab, nicht vom Erscheinungsbild.

Für den privaten Sektor greift das Barrierefreiheitsstärkungsgesetz. Es gilt seit dem 28. Juni 2025 für bestimmte Produkte und Dienstleistungen, etwa Online-Shops, Bankdienstleistungen, Telekommunikation und Personenbeförderung. Auch dort ist die EN 301 549 der technische Maßstab.

Aus den Kriterien lässt sich ein Prüfset ableiten. Es umfasst Kontrastmessung, Tastaturdurchlauf, Screenreader-Durchlauf, Zoom- und Reflowprüfung sowie die Kontrolle aller Formulare. Dieses Set gehört als Checkliste in jede Abnahme.

Praktisch heißt das: Anforderungen gehören in die Gestaltungsphase, nicht in eine Nachbesserungsrunde kurz vor dem Start. Ein nachträglich ergänzter Fokusrahmen kostet mehr als ein von Beginn an mitgeplanter.

Designsystem als Fundament: Tokens, Komponenten und Dokumentation

Ein Designsystem ist keine Stilvorlage, sondern ein Produkt mit Versionen, Verantwortlichen und Änderungsprozess. Es besteht aus Design Tokens, Komponenten, Mustern, Inhalten und Dokumentation. Ohne Pflege veraltet es schneller, als es Nutzen stiftet.

Tokens sind benannte Werte für Farbe, Typografie, Abstand, Radius, Schatten, Bewegung und Zustände. Sie liegen als Variablen im Gestaltungswerkzeug und als CSS-Variablen im Code. Ändert sich ein Token, ändert sich jede Stelle, die darauf verweist. Deshalb werden Tokens vor dem ersten Bildschirmentwurf festgelegt.

Komponenten sind die sichtbaren Bausteine: Schaltfläche, Eingabefeld, Auswahlfeld, Dialog, Tabelle, Navigation und Hinweis. Jede Komponente braucht dokumentierte Zustände, definiertes Tastaturverhalten, passende Rollen für Assistenztechnik und geprüfte Kontrastwerte. Ein Zustand ohne Dokumentation ist ein Zustand, den niemand zuverlässig nachbaut.

Bekannte Systeme zeigen, wie der Aufbau gelingt. Material Design von Google beschreibt Prinzipien, Komponenten und Muster einer umfangreichen Bibliothek. Das Fluent 2 Design System von Microsoft erklärt, wie Design Tokens, Komponenten und Plattformanpassungen zusammenspielen.

Weitere Referenzen sind IBM Carbon, Adobe Spectrum, das GOV.UK Design System und KoliBri, die Komponentenbibliothek des Landes Schleswig-Holstein. Wer ein eigenes System aufbaut, übernimmt Prinzipien und Prüfverfahren, nicht das Erscheinungsbild.

Inhalte gehören zum System. Mikrotexte für Schaltflächen, Fehlermeldungen und Hinweise werden zentral gepflegt. Eine Schaltfläche mit unklarer Beschriftung bleibt unbrauchbar, auch wenn Kontrast und Fokus stimmen.

Namenskonventionen halten die Bibliothek lesbar. Üblich ist eine Reihenfolge von Kategorie, Element, Variante und Zustand, damit Suche und Filter im Werkzeug zuverlässig treffen.

Der Aufbau folgt fünf Schritten:

Versionierung folgt sinnvoll dem Schema Hauptversion, Nebenversion, Korrektur. Wird eine Komponente abgelöst, braucht sie einen angekündigten Auslaufpfad, sonst bleiben alte Varianten jahrelang im Bestand.

Kennzahlen zeigen, ob sich der Aufwand trägt: Anteil wiederverwendeter Komponenten, Zahl der Abweichungen, Zeit von Entwurf bis Freigabe und Quote bestandener Prüfungen.

Werkzeuge: Figma, Sketch, Storybook und Prüfprogramme

Figma hat sich in vielen Produktteams durchgesetzt. Komponenten, Varianten, Auto Layout und Variablen bilden Tokens und Bausteine ab. Der Dev Mode liefert Maße, Werte und Exporte an die Entwicklung. Weil das Werkzeug im Browser läuft, arbeiten Gestaltung und Entwicklung an derselben Datei.

Sketch arbeitet nativ auf dem Mac. Symbols und geteilte Libraries halten wiederkehrende Elemente konsistent, die Cloud übernimmt Übergabe und Kommentare. Teams, die lokal statt im Browser arbeiten, fahren damit gut.

Adobe XD spielt in neuen Projekten kaum noch eine Rolle, weil Adobe den Ausbau eingestellt hat. Für Bestandsprojekte bleibt es relevant, für Neuplanungen ist es selten die erste Wahl.

Für Übergabe und Dokumentation kommen Werkzeuge wie Zeplin, Supernova, Zeroheight und Storybook hinzu. Storybook zeigt Komponenten im Code mit allen Zuständen und dient zugleich als Prüffläche für automatisierte Barrierefreiheitstests.

Design Tokens lassen sich als Datei austauschen. Die Design Tokens Community Group des W3C beschreibt ein Format, das Werkzeuge und Code verstehen. Erweiterungen wie Tokens Studio exportieren Werte aus Figma in dieses Format.

Prüfprogramme ergänzen die Gestaltungsarbeit: axe DevTools, Lighthouse, Pa11y und WAVE finden fehlende Alternativtexte, Kontrastfehler und Beschriftungsprobleme. Colour Contrast Analyser und Stark messen Farbwerte direkt im Entwurf. Für Screenreader-Läufe stehen NVDA und JAWS unter Windows, VoiceOver unter macOS und iOS sowie TalkBack unter Android bereit.

Eine Testmatrix hält fest, welche Kombination aus Browser, Betriebssystem und Assistenztechnik geprüft wird. Ohne diese Festlegung bleibt jede Prüfung eine Momentaufnahme.

Testmethoden: automatisiert, manuell, mit Nutzenden

Automatisierte Prüfungen finden nur einen Teil der Barrieren. Fehlende Alternativtexte, zu geringe Kontraste und nicht verknüpfte Formularbeschriftungen fallen zuverlässig auf. Fokusreihenfolge, Verständlichkeit und Bedienlogik bleiben unentdeckt. Der WebAIM Million Report weist seit Jahren bei über 90 Prozent der geprüften Startseiten mindestens einen automatisch erkennbaren WCAG-Verstoß aus.

Usability-Tests liefern die belastbarsten Hinweise. Fünf Teilnehmende je Runde decken die meisten schweren Probleme auf. Erhoben werden Aufgabenbearbeitung, Erfolgsquote, Zeit bis zur Lösung, Fehlerzahl und eine kurze Bewertung nach jeder Aufgabe. Der System Usability Scale liefert einen Vergleichswert über Runden hinweg.

Ergänzend helfen günstige Verfahren: heuristische Evaluation, Cognitive Walkthrough und First-Click-Test liefern schon vor dem ersten Nutzendentest Hinweise. Ein Baumtest prüft die Informationsarchitektur, bevor Bildschirme entstehen. Die RITE-Methode verkürzt Runden, weil Probleme sofort behoben und erneut geprüft werden.

Für Barrierefreiheitstests werden Menschen mit Behinderung bezahlt rekrutiert und mit ihrer eigenen Assistenztechnik getestet. Das ist aufwendiger als ein Labortest mit Standardnutzenden, deckt aber genau die Fälle ab, die automatisierte Werkzeuge nicht sehen. Aufzeichnung und Einwilligung regelt das Team vorab und informiert über Zweck, Dauer und Verwendung der Daten.

Abnahmekriterien gehören in die Definition of Done. Eine Komponente gilt erst als fertig, wenn Tastaturbedienung, Fokusdarstellung, Kontrast, Beschriftung und Screenreader-Ausgabe geprüft sind. Regressionstests nach jeder Änderung verhindern, dass behobene Fehler zurückkehren.

Beispielbudgets für Designsystem, Audit und Tests

Die folgenden Werte sind eine Beispielrechnung, keine Preisliste. Angenommen werden Tagessätze zwischen 900 und 1.200 Euro netto für Agenturen und spezialisierte Dienstleister. Alle Beträge verstehen sich netto zuzüglich der gesetzlichen Umsatzsteuer von derzeit 19 Prozent.

Leistung	Aufwand	Beispielkosten netto

Ein mittleres Vorhaben mit 85 Personentagen liegt bei einem Tagessatz von 950 Euro netto bei rund 80.750 Euro. Dazu kommt die Pflege. Als Erfahrungswert für die laufende Betreuung eines Designsystems gelten 15 bis 20 Prozent des Erstaufwands pro Jahr, im Beispiel also etwa 12.000 bis 16.000 Euro netto.

Kleinere Teams können den Einstieg verkleinern: Tokens, zehn Komponenten, Dokumentation und ein Audit ergeben je nach Umfang etwa 35 Personentage und rund 33.000 Euro netto. Wichtiger als die Summe ist die Reihenfolge. Erst Grundlagen und Prüfverfahren, dann Komponenten in Breite.

Nicht alle Posten fallen gleichzeitig an. Audit und Grundlagen laufen vor dem ersten Sprint, Komponenten entstehen danach in mehreren Ausbaustufen. Öffentliche Auftraggeber trennen diese Leistungen sinnvoll in Losen, damit Zwischenergebnisse prüfbar bleiben.

Rollen, Zusammenarbeit und Pflege

Ein Designsystem braucht eine verantwortliche Person, auch wenn viele daran mitarbeiten. Typische Rollen sind Design System Lead, Product Designer, Frontend-Entwicklung, Accessibility-Spezialist und Redaktion für Inhalte und Mikrotexte.

Änderungen laufen über einen sichtbaren Prozess: Antrag, Bewertung, Umsetzung, Prüfung, Veröffentlichung. Eine regelmäßige Sprechstunde senkt die Hürde für Beiträge aus Projekten. Ein Änderungsprotokoll macht nachvollziehbar, welche Version wann galt.

Barrierefreiheit ist keine Rolle für sich, sondern eine Eigenschaft jeder Komponente. Prüfschritte werden deshalb in den Standardablauf eingebaut, nicht an eine externe Stelle ausgelagert. Wer Gestaltung, Entwicklung und Prüfung voneinander trennt, verliert die Gründe für Entscheidungen.

Häufige Fragen

Gilt die BITV 2.0 auch für kommunale Websites?

Die BITV 2.0 des Bundes gilt für öffentliche Stellen des Bundes. Länder haben eigene Verordnungen, Kommunen unterliegen dem jeweiligen Landesrecht. In der Praxis orientieren sich viele Stellen an der WCAG 2.2 in Stufe AA, weil die EN 301 549 diesen Maßstab vorgibt.

Reicht WCAG 2.2 AA aus?

Für die meisten gesetzlichen Anforderungen ja. Stufe AA ist der übliche Bezugspunkt. Sie bleibt jedoch eine Untergrenze: Verständlichkeit, Aufgabenpassung und Arbeitsaufwand prüft kein Kriterienkatalog, sondern nur ein Test mit Nutzenden.

Wie viele Personen braucht ein Usability-Test?

Fünf Teilnehmende je Runde und Zielgruppe decken die meisten schwerwiegenden Probleme auf. Mehrere kleine Runden sind aussagekräftiger als eine große Erhebung am Ende. Für Barrierefreiheitstests kommen Testpersonen mit eigener Assistenztechnik hinzu.

Was kostet ein Designsystem?

Der Erstaufbau eines mittleren Systems liegt nach der Beispielrechnung bei rund 80.000 Euro netto, kleinere Einstiege bei etwa 33.000 Euro netto. Die laufende Pflege liegt bei 15 bis 20 Prozent des Erstaufwands pro Jahr.

Kann ein Team Material Design oder Fluent 2 direkt übernehmen?

Beide Systeme sind als Grundlage nutzbar und ausführlich dokumentiert. Marke, Inhalte, Plattformen und eigene Barrierefreiheitsanforderungen erfordern trotzdem Anpassungen. Lizenzbedingungen und Pflegezustand sollten vor der Übernahme geprüft werden.