Barrierefreiheit im UX- und UI-Design

Im Design fallen die Entscheidungen, die später am teuersten zu korrigieren sind: Kontrastwerte, Fokuszustände, Zielgrößen, das Verhalten bei 400 Prozent Zoom und die Frage, ob Bedeutung nur über Farbe transportiert wird. Wer sie im Entwurf richtig trifft, spart dem Team die Runde, in der ein fertiges Interface nachträglich umgebaut wird – und liefert Zustände mit, die sonst niemand spezifiziert hat.

Diese Seite sortiert das Wissen dieser Website nach Zuständigkeit. Sie erklärt die Themen nicht neu, sondern zeigt, welche davon im Design entschieden werden – und wo die Grenze zur Entwicklung verläuft.

Das Wichtigste in Kürze

• Kontrast ist eine Designentscheidung: 4,5:1 für Text, 3:1 für große Schrift und für Bedienelemente und ihre Zustände.
• Der Fokuszustand gehört in die Komponentenbibliothek. Wenn er dort fehlt, wird er im Code erfunden oder weggelassen.
• Zielgrößen ab 24 × 24 CSS-Pixel oder genug Abstand – auf dem Desktop genauso wie mobil.
• Bedeutung nie allein über Farbe. Rot markierte Pflichtfelder brauchen ein zweites Signal.
• Der Entwurf muss bei 400 % Zoom funktionieren – das entspricht 320 Pixeln Breite.
• Bewegung braucht eine Aus-Option, und prefers-reduced-motion muss im Entwurf mitgedacht sein.
• Nicht deine Aufgabe: ARIA, Fokusreihenfolge im DOM, Alt-Texte einzelner Bilder.

Warum das Design der teuerste Zeitpunkt zum Nachbessern ist

Ein falscher Kontrastwert in einer Designvorlage kostet fünf Minuten. Derselbe Wert, nachdem er in dreißig Komponenten und zweihundert Screens ausgerollt ist, kostet ein Sprint-Ziel. Dasselbe gilt für Zielgrößen: Eine Icon-Leiste mit 16-Pixel-Buttons lässt sich im Entwurf umbauen, im fertigen Produkt bricht sie ein ganzes Layoutraster.

Deshalb ist die wirksamste Maßnahme keine Prüfung am Ende, sondern eine Komponentenbibliothek, in der die Zustände von Anfang an vorhanden sind. Fünf Zustände je Bedienelement, nicht zwei: Ruhe, Hover, Fokus, aktiv, deaktiviert. Der Fokuszustand ist der, der am häufigsten fehlt – und genau der, den Tastaturnutzende brauchen.

Die sechs Entscheidungen, die im Design fallen

1. Kontrast. Für Fließtext gilt 4,5:1, für Text ab 18,66 px fett oder 24 px normal reichen 3:1. Oft übersehen: Auch Bedienelemente und ihre Zustandsgrenzen brauchen 3:1 – das regelt 1.4.11 Nicht-Text-Kontrast. Ein hellgrauer Rahmen um ein Eingabefeld ist der Klassiker, der daran scheitert. Werte prüfst du mit dem Kontrast-Check, die Systematik steht unter Farbkontraste.

2. Der Fokuszustand. Er muss sichtbar sein (2.4.7) und darf nicht vollständig hinter Sticky-Headern oder Bannern verschwinden (2.4.11, neu in WCAG 2.2). Was ein brauchbarer Fokusring leistet, steht unter Tastaturbedienung & sichtbarer Fokus. Ein Tipp aus der Praxis: Ein zweifarbiger Ring – innen hell, außen dunkel – funktioniert auf jedem Hintergrund, ohne dass du ihn je wieder anpassen musst.

3. Zielgrößen. 2.5.8 Zielgröße (Minimum) verlangt 24 × 24 CSS-Pixel oder ausreichenden Abstand. Betroffen sind vor allem Icon-Leisten, Schließen-Kreuze und Paginierungen. Wer wissen will, warum ein paar Pixel hier so viel ausmachen, findet die Begründung unter Motorische Einschränkungen.

4. Farbe als einziges Signal. Ein rot umrandetes Pflichtfeld, eine grün markierte Zeile, ein Diagramm, dessen Serien sich nur farblich unterscheiden – alle drei verstoßen gegen 1.4.1. Die Lösung ist immer ein zweites Signal: ein Symbol, ein Muster, eine Beschriftung. Wen das betrifft, steht unter Farbfehlsichtigkeit.

5. Zoom und Umbruch. Der Entwurf muss bei 400 Prozent Zoom ohne horizontales Scrollen bedienbar bleiben – praktisch entspricht das einer Breite von 320 Pixeln. Feste Höhen, zweispaltige Karten und Tabellen sind die üblichen Bruchstellen. Details unter Reflow, Zoom & Textabstände; wer damit täglich arbeitet, ist unter Bildschirmvergrößerung beschrieben.

6. Bewegung und Zeit. Automatisch startende Karussells, Parallax-Effekte und Auto-Play brauchen eine Pausierung (2.2.2); Zeitfenster müssen verlängerbar sein (2.2.1). Und der Entwurf sollte eine Variante für prefers-reduced-motion mitliefern, statt sie der Entwicklung zu überlassen.

Was ausdrücklich nicht deine Aufgabe ist

• ARIA und Rollen entstehen im Code. Was du liefern kannst, ist die Angabe, was ein Element ist – Schaltfläche oder Link, siehe Buttons vs. Links.
• Die Fokusreihenfolge folgt der Reihenfolge im DOM. Wenn dein Layout sie umsortiert, ist das aber sehr wohl ein Designbefund – melde ihn.
• Alt-Texte einzelner Inhaltsbilder schreibt die Redaktion; Alt-Texte für Icons und Illustrationen im System gehören dagegen zur Komponentenspezifikation.

So prüfst du einen Entwurf

Sechs Prüfungen, alle vor der Übergabe:

1. Kontraste messen, nicht schätzen – auch für Platzhaltertexte, deaktivierte Zustände und Rahmen.
2. Fokuszustand suchen. Ist er für jedes Bedienelement spezifiziert? Wenn nicht, ist der Entwurf unvollständig.
3. Den Entwurf auf 320 Pixel Breite ziehen. Was bricht?
4. In Graustufen ansehen. Alles, was dann seine Bedeutung verliert, verstößt gegen 1.4.1.
5. Trefferflächen messen – Icon-Leisten, Schließen-Kreuze, Paginierung.
6. Die Fehlerdarstellung durchspielen. Steht neben der roten Umrandung ein Text, der sagt, was falsch ist? Das ist die Designseite von Fehlermeldungen barrierefrei.

Häufiger Fehler in der Praxis

Den Fokusring aus ästhetischen Gründen entfernen. Der häufigste Einzelbefund überhaupt – und der einzige, bei dem das Design aktiv etwas kaputt macht, das der Browser von sich aus richtig gemacht hätte.

Platzhalter statt Beschriftung. Ein Formular ohne sichtbare Labels sieht aufgeräumt aus und ist nach dem ersten Tippen unlesbar – siehe Labels & Beschriftungen.

Nur den Idealzustand entwerfen. Fehlerfall, Ladezustand, leerer Zustand und langer Text fehlen in den meisten Übergaben – und werden dann im Code improvisiert.

Kontrast am Markenhandbuch entlang begründen. Die Hausfarbe ist kein Argument gegen 4,5:1. Sie darf bleiben, wo sie großflächig wirkt, und braucht eine dunklere Variante für Text.

Häufige Fragen

Muss ich als Designerin die WCAG auswendig kennen?

Nein. Sechs Kriterien decken den Großteil der Designentscheidungen ab: 1.4.1, 1.4.3, 1.4.11, 2.4.7, 2.5.8 und 1.4.10. Der Rest ist Entwicklung oder Redaktion. Die vollständige Referenz steht unter WCAG-2.2-Referenz, falls du im Audit nachschlagen musst.

Darf ich einen eigenen Fokusstil statt des Browser-Standards nehmen?

Ja, und das ist meist sogar besser – solange er sichtbar bleibt und genug Kontrast zum Hintergrund hat. Verboten ist nur das ersatzlose Entfernen.

Wie gehe ich mit einem Markenfarbschema um, das durchfällt?

Trenne Markenfarbe von Textfarbe. Die Hausfarbe darf großflächig, in Bildern und als Akzent auftreten; für Text und Bedienelemente braucht es eine abgedunkelte Variante derselben Farbe. Das ist ein üblicher und akzeptierter Weg, kein Bruch mit der Marke.

Wer prüft am Ende, ob der Entwurf umgesetzt wurde?

Idealerweise du selbst, im fertigen Produkt – die meisten Abweichungen entstehen zwischen Übergabe und Umsetzung. Wie ein strukturierter Durchlauf aussieht, steht unter Barrierefreiheit selbst testen.

Verwandte Themen

• Barrierefreiheit für die Redaktion – wer deine Vorlagen später mit Inhalt füllt
• Barrierefreiheit im Projekt steuern – wo Designzeit für Zustände eingeplant wird
• Barrierefreie Komponenten – die Umsetzungsseite deiner Entwürfe
• Curb-Cut-Effekt & Mythen – warum „barrierefrei sieht langweilig aus“ nicht stimmt

Quellen

• Designing for Web Accessibility – die Designgrundregeln (W3C WAI)
• Understanding SC 1.4.11: Non-text Contrast (W3C)
• The WebAIM Million – Kontrast als häufigster Einzelfehler