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.

Umgesetzt werden diese Entscheidungen fast alle im Stylesheet. Der Bereich CSS sammelt die Eigenschaften, an denen Kontrast, Fokus, Zoom und Bewegung am Ende hängen.

Diese Seite sortiert das Wissen dieser Website nach Zuständigkeit. Sie zeigt, welche Themen im Design entschieden werden und wo die Grenze zur Entwicklung verläuft. Die Einzelheiten stehen auf den verlinkten Seiten.

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. Links im Fließtext brauchen eine Unterstreichung oder 3:1 Kontrast zum Text.
• Der Entwurf muss größere Textabstände vertragen: Zeilenhöhe 1,5, Absatzabstand 2 em, Buchstabenabstand 0,12 em und Wortabstand 0,16 em (WCAG 1.4.12).
• 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.
• Die Übergabe enthält Annotationen zu Überschriften, Landmarks, Tab-Reihenfolge, Namen von Icon-Buttons und Statusmeldungen. ARIA selbst schreibt die Entwicklung.

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 bringt sie ein ganzes Layoutraster durcheinander.

Die wirksamste Maßnahme ist deshalb eine Komponentenbibliothek, in der die Zustände von Anfang an vorhanden sind. Eine Prüfung am Ende findet nur, was dort fehlt. Jedes Bedienelement braucht fünf Zustände: Ruhe, Hover, Fokus, aktiv, deaktiviert. Der Fokuszustand fehlt am häufigsten, dabei brauchen Tastaturnutzende genau ihn.

Die acht 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, Laufschriften und Auto-Play brauchen eine Pausierung, sobald sie länger als fünf Sekunden laufen und neben anderem Inhalt stehen (2.2.2). Zeitfenster müssen verlängerbar sein (2.2.1). Nichts darf öfter als dreimal pro Sekunde blitzen (2.3.1, Stufe A), weil das Anfälle auslösen kann. Parallax-Effekte und Animationen, die beim Scrollen oder Klicken entstehen, regelt 2.3.3 „Animation durch Interaktionen“. Das Kriterium gehört zur Stufe AAA und ist damit keine Pflicht. Es ist trotzdem eine gute Praxis: Der Entwurf liefert eine ruhige Variante für prefers-reduced-motion mit, damit die Entwicklung sie nicht erfinden muss.

7. Schrift und Textabstände. Die WCAG schreiben keine Schriftart vor, auch keine serifenlose. Sie verlangen, dass Text sich auf 200 Prozent vergrößern lässt, ohne dass Inhalt verloren geht (1.4.4). Außerdem muss das Layout größere Abstände vertragen, die Nutzende per Stylesheet oder Erweiterung setzen: Zeilenhöhe 1,5, Absatzabstand 2 em, Buchstabenabstand 0,12 em und Wortabstand 0,16 em (1.4.12). Pflicht ist dabei nur, dass nichts abgeschnitten wird oder sich überlappt. Buttons mit fester Höhe und Karten mit fester Textmenge fallen hier am häufigsten durch. Bewährt haben sich darüber hinaus Fließtext ab 16 Pixeln, Zeilen bis etwa 80 Zeichen, linksbündiger Flattersatz und keine längeren Passagen in Versalien. Diese Werte stammen aus 1.4.8 auf Stufe AAA und aus der Leseforschung. Sie sind Empfehlungen. Text gehört außerdem nicht in Bilder (1.4.5), weil er sich dort weder vergrößern noch umbrechen lässt.

8. Links erkennbar machen. Ein Link im Fließtext, der sich nur durch seine Farbe vom umgebenden Text abhebt, verstößt gegen 1.4.1. Die einfachste Lösung ist die Unterstreichung. Soll sie entfallen, braucht die Linkfarbe mindestens 3:1 Kontrast zum umgebenden Text und zusätzlich ein zweites Signal bei Hover und Fokus, etwa eine Unterstreichung, die dann erscheint. In Navigationen und Buttons ist die Rolle aus Position und Form erkennbar. Dort gilt die Regel nicht. Am besten legt das Designsystem einmal fest, wie Links im Text aussehen.

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.

Die Übergabe an die Entwicklung

Viele Barrieren entstehen zwischen Entwurf und Code, weil der Entwurf zeigt, wie etwas aussieht, und offenlässt, was es ist. Die Entwicklung muss dann raten. Annotationen im Entwurf schließen diese Lücke. Dafür gibt es fertige Werkzeuge, etwa das Accessibility Annotation Kit für Figma. Fünf Angaben gehören in jede Übergabe:

1. Überschriften und Landmarks. Welcher Text ist eine Überschrift welcher Ebene, wo liegen Kopfbereich, Navigation, Hauptinhalt und Fußbereich? Die Grundlage dafür steht unter Struktur-Elemente.
2. Lese- und Tab-Reihenfolge. Nummern im Entwurf zeigen, in welcher Reihenfolge der Fokus die Bedienelemente erreicht. Das betrifft vor allem Layouts, deren visuelle Reihenfolge von der logischen abweicht.
3. Namen für Icon-Buttons. Ein Lupen-Symbol braucht den Namen „Suche“, ein Kreuz den Namen „Dialog schließen“. Der Name wird im Entwurf festgelegt und in der Entwicklung umgesetzt.
4. Verhalten interaktiver Muster. Öffnet sich ein Menü per Klick oder Hover? Wohin springt der Fokus, wenn ein Dialog aufgeht und wieder zugeht? Die passenden Muster stehen unter Barrierefreie Komponenten.
5. Statusmeldungen. Ladeanzeigen, Erfolgsmeldungen und Trefferzahlen nach einer Suche müssen auch beim Screenreader ankommen (4.1.3). Der Entwurf markiert, welche Meldungen das sind.

So prüfst du einen Entwurf

Acht 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 geht kaputt?
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. Textabstände erhöhen. Zeilenhöhe auf 1,5 und Absätze auf 2 em setzen: Wird Text abgeschnitten oder überlappt er? Im fertigen Produkt erledigt das ein Bookmarklet für 1.4.12 in Sekunden.
7. Links im Fließtext ansehen. Sind sie ohne Farbsehen erkennbar? Der Graustufentest aus Schritt 4 zeigt es sofort.
8. 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. Das ist der häufigste Einzelbefund im Design: Hier macht das Design aktiv kaputt, was der Browser von allein richtig gemacht hätte.

Platzhalter statt Beschriftung. Ein Formular ohne sichtbare Labels sieht aufgeräumt aus und ist nach dem ersten Tippen unlesbar. Mehr dazu unter 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 hebt die Grenze von 4,5:1 nicht auf. 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. Acht Kriterien decken den Großteil der Designentscheidungen ab: 1.4.1, 1.4.3, 1.4.11, 2.4.7, 2.5.8, 1.4.10, 1.4.4 und 1.4.12. 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. Wichtig ist nur, dass 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. Die Marke bleibt dabei erkennbar.

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