Digitale Accessibility, explained for teams

UX Designers Guide für digitale Barrierefreiheit

—

von

Daniel-A11y-Blog
in

Was bedeutet Barrierefreiheit für UX/UI Designer eigentlich?

Barrierefreiheit UX Designer zu sein bedeutet: Du gestaltest Interfaces, die für Menschen aller Fähigkeiten nutzbar, wahrnehmbar und bedienbar sind – einschließlich Nutzer mit dauerhaften, vorübergehenden oder situationsbedingten Einschränkungen. Das betrifft Sehbehinderungen, motorische Einschränkungen, kognitive Unterschiede und temporäre Situationen wie Sonnenlicht auf dem Bildschirm oder eine gebrochene Hand.

Als UX/UI Designer trägst du eine der zentralsten Verantwortungen im Team für digitale Barrierefreiheit: Du entscheidest über Layout, visuelle Hierarchie, Farbkonzept, Interaktionsmuster und Informationsstruktur – alles, bevor eine einzige Zeile Code geschrieben wird. Barrierefreiheit im Design zu verankern ist immer günstiger als sie später nachzurüsten.

Ab Juni 2025 gilt in Deutschland das BFSG (Barrierefreiheitsstärkungsgesetz), das digitale Barrierefreiheit für viele kommerzielle Angebote verpflichtend macht. Als UX/UI Designer bist du direkt betroffen.

Roles Involved in Accessibility in Accessibility Roles and Responsibilities Mapping (ARRM)

Wo fange ich als UX/UI Designer mit Barrierefreiheit an?

Neu beim Thema Barrierefreiheit? Starte in dieser Reihenfolge:

  1. Kontrast & Farbe prüfen lernen (Abschnitt 1) – der häufigste Fehler, der schnellste Fix
  2. WCAG Checkliste für Designer einmalig durcharbeiten (Abschnitt 3)
  3. Keyboard Navigation selbst ausprobieren – Tab-Taste, keine Maus (Abschnitt 4)
  4. VoiceOver oder NVDA 10 Minuten Scren Reader auf deinen eigenen Designs testen (Abschnitt 5)

Bereits vertraut mit den Grundlagen? Dann sind diese Abschnitte dein nächster Schritt:

  • WCAG 2.2 – neue Anforderungen speziell für Designer (Abschnitt 2)
  • Handover & Annotations – wie du Entwickler korrekt briefst (Abschnitt 3)

1. Grundlagen der Barrierefreiheit – was du als UX/UI Designer täglich brauchst

Kontrast & Farbe

Farbkontrast ist die häufigste Barrierefreiheitslücke in UX-Designs. Prüfe ihn bei jedem Farbentscheid, nicht erst am Ende des Projekts.

Was schreibt WCAG 2.2 vor?

  • Normaler Text: Mindest-Kontrastverhältnis 4,5:1
  • Großer Text (18pt / 14pt fett): 3:1
  • UI-Komponenten & grafische Elemente: 3:1

Empfohlene Tools für Barrierefreiheit für UX/UI Design:

A11yCasts explains Check for Accessible Colors

Wichtig: Kontrast allein reicht nicht. Verlasse dich nie ausschließlich auf Farbe zur Informationsvermittlung (WCAG 1.4.1). Fehlerfelder z. B. brauchen zusätzlich ein Icon oder eine Textbeschriftung.

Figma Plugins für barrierefreies UX/UI Design

Diese Plugins unterstützen dich direkt im Design-Prozess:

Browser Extensions für UX/UI Designer

Als Designer nutzt du diese Tools primär für Reviews von implementierten Designs, nicht täglich.

2. WCAG 2.2 – Was UX/UI Designer wissen müssen

Typografie & Text (WCAG 1.4.4 & 1.4.12)

Kontrast ist nicht alles. Diese Anforderungen betreffen direkt deine Typografie-Entscheidungen:

WCAG 1.4.12 – Textabstand (AA)

Stelle sicher, dass dein Layout nicht bricht, wenn Nutzer diese Abstände individuell einstellen:

  • Zeilenhöhe: 1,5× Schriftgröße
  • Absatzabstand: 2× Schriftgröße
  • Buchstabenabstand: 0,12× Schriftgröße
  • Wortabstand: 0,16× Schriftgröße

Praktisch bedeutet das: Keine fixen Containerhöhen, die Text abschneiden. Kein Overflow: hidden auf Textbereichen.

WCAG 1.4.4 – Textgröße (AA): Text muss bis 200% skalierbar sein, ohne dass Inhalt verloren geht oder sich überlagert.

Empfehlung: Mindestschriftgröße 16px für Fließtext. Nie unter 12px für irgendwelche UI-Texte.

Fokus-Indikator Design (WCAG 2.4.11 – neu in WCAG 2.2)

Was ist ein Fokus-Indikator und warum ist er Designverantwortung?

Der Fokus-Indikator ist das visuelle Zeichen, das anzeigt, welches Element aktuell per Tastatur fokussiert ist. Viele UX/UI Designer entfernen ihn aus ästhetischen Gründen – das ist ein kritischer Barrierefreiheitsfehler und seit WCAG 2.2 explizit geregelt.

Understanding SC 2.4.11 Focus Not Obscured (Minimum) (Level AA)

WCAG 2.4.11 – Focus Appearance (AA, neu):

  • Eine Fläche von mindestens dem Umfang des Elements × 2px abdecken
  • Einen Kontrast von mindestens 3:1 zum unfokussierten Zustand haben

Was das für dein UX Design bedeutet:

  • Definiere einen expliziten Fokus-Stil in deinem Design-System – kein Browser-Default
  • Fokus-Ringe auf dunklem Hintergrund: weißer oder heller Ring, auf hellem Hintergrund: dunkler Ring
  • Häufig bewährt: 2–3px Outline + 2px Offset in einer gut sichtbaren Kontrastfarbe

Ressource: A guide to designing accessible, WCAG-conformant focus indicators

Touch Target Sizes (WCAG 2.5.8 – neu in WCAG 2.2)

Wie groß müssen klickbare Elemente im barrierefreien UX Design sein?

Empfehlung für die Praxis:

  • Buttons, Links und Icons immer mindestens 24x24px (Level AA) und 44×44px (Level AAA) Klickbereich – auch wenn das visuelle Element kleiner ist
  • Enge Icon-Buttons (Close, Menu, Chevron) besonders prüfen
  • Nutze Padding statt größerer Icons, um den Klickbereich zu vergrößern

Motion & Animation

Warum ist prefers-reduced-motion eine Designentscheidung?

prefers-reduced-motion ist eine CSS Media Query, die Nutzer in ihrem Betriebssystem aktivieren können. Sie signalisiert, dass der Nutzer keine oder weniger Animationen möchte – aus Gründen wie Epilepsie, Schwindel oder Konzentrationsstörungen. Die Entscheidung, welche Animationen abgeschaltet werden, triffst du als UX/UI Designer in den Specs.

Was du in deinen Specs festlegen musst:

  • Welche Animationen werden bei prefers-reduced-motion: reduce ausgeblendet oder ersetzt?
  • Gibt es eine statische Fallback-Variante für alle Loading-Animationen, Parallax-Effekte, Auto-Play-Videos?

Faustregeln:

  • Auto-Play-Videos: immer pausierbar, kein Audio per Default
  • Karussells: immer pausierbar (WCAG 2.2.2)
  • Parallax-Effekte: immer mit statischer Fallback-Variante

Dark Mode & High Contrast Mode

Dark Mode

Definiere im Design-System beide Farbmodi explizit. Nicht jede Farbe, die im Light Mode WCAG-konform ist, besteht auch im Dark Mode – beide Modi müssen separat geprüft werden.

Windows High Contrast Mode (Forced Colors)

Viele Nutzer mit Sehbehinderungen nutzen diesen Modus. Browser ersetzen dann fast alle CSS-Farben durch Systemfarben.

Was das für dein Design bedeutet:

  • Layouts dürfen nicht zusammenbrechen, wenn Farben wegfallen
  • Icons, die nur per Hintergrundfarbe erkennbar sind, werden unsichtbar
  • Reine Farbtrennungen ohne Borders funktionieren nicht mehr

Ressource: The Guide To Windows High Contrast Mode

3. WCAG Checklisten & Handover für UX/UI Designer

WCAG Checklisten für Designer

Welche WCAG-Checkliste eignet sich für UX/UI Designer am besten?

Empfohlen für den täglichen Einsatz: Figma – Stark WCAG Checklist (Annotations for the handover – important!)

Vollständige Referenz: WebAim WCAG Checklist

Gut lesbare, praxisnahe Übersicht: A11yproject Checklist

Technisch präzise: IBM Checklist

Web Accessibility Checklists

A11yCasts explains How to do an Accessibility Check

Handover & Annotations – der kritischste Schritt für Barrierefreiheit UX Designer

Warum ist der Figma-Handover so entscheidend für digitale Barrierefreiheit?

Das Prinzip heißt Shift-Left: Barrierefreiheit so früh wie möglich im Prozess verankern, nicht erst kurz vor der Übergabe. Jeder Fehler, der im Design übersehen wird, potenziert sich nach dem Handover – aus einer fehlenden Annotation werden Stunden Debugging, aus einer falschen Farbentscheidung wird ein Sprint-Ticket, aus einer unklaren Fokus-Reihenfolge wird ein QA-Befund kurz vor Release.

Der Handover ist trotzdem der Moment, an dem Barrierefreiheit im Design endgültig gerettet oder verloren geht. Entwickler können nur umsetzen, was sie explizit dokumentiert bekommen. Vieles, was für Barrierefreiheit entscheidend ist, ist im visuellen Design nicht sichtbar – es muss annotiert werden.

Nutze dafür das Figma – Stark WCAG Checklist Plugin (Abschnitt WCAG Checklisten für Designer)

Was gehört in die Accessibility-Annotations im Figma-Handover?

Ein sehr ausführliche Auflistung, was beim Handover wichtig ist, findet Ihr hier: A Designer’s Guide to Documenting Accessibility & User Interactions

1. Landmark-Rollen:

Markiere im Design, welcher Bereich welche HTML-Landmark-Rolle hat: <header>, <main>, <nav>, <aside>, <footer>, <section> mit aria-label Landmarks über ARIA-Rollen im Layout vergeben

2. Lesereihenfolge (Reading Order):

Definiere explizit die Reading Order – besonders wenn das visuelle Layout von der logischen Lesereihenfolge abweicht (z. B. Sidebar vor Content, Cards in Grid-Layouts, Sticky Headers).

3. Fokus-Reihenfolge:

Markiere die Tab-Reihenfolge für komplexe Komponenten: Modals, Dropdowns, Date Pickers, Custom Select-Elemente. Success Criterion 2.4.3 Focus Order

4. ARIA-Labels & Rollen

Du musst als UX/UI Designer keine ARIA-Attribute auswendig kennen – das ist die Aufgabe der Entwickler. Was du können musst: beschreiben, was passieren soll. Welche Elemente gehören zusammen? Welcher Text gehört zu welchem Eingabefeld? Was soll ein Screen Reader vorlesen, wenn ein Nutzer auf einen Icon-Button trifft? Diese Beschreibungen sind deine Annotations – der Entwickler übersetzt sie dann in den richtigen ARIA-Code.

Konkret bedeutet das: Statt aria-describedby zu schreiben, annotierst du „diese Fehlermeldung ist mit dem E-Mail-Feld verknüpft“. Statt aria-live zu kennen, schreibst du „diese Statusmeldung soll automatisch vorgelesen werden, wenn sie erscheint“. Die Fachsprache gehört dem Entwickler – die Intention gehört dir.

  • Icon-Buttons ohne sichtbaren Text: Was ist der aria-label?
  • Formularfelder: Welches Label gehört zu welchem Input?
  • Status-Meldungen: Automatisch vorlesen? (aria-live)

The Hidden Gold of Web Accessibility: Everything About ARIA Labels

Seh gute Übersicht: ARIA Authoring Practices Pattern

5. Fehlerzustände:

Jeder Fehlerzustand braucht:

  • Eine sichtbare Fehlermeldung (kein reines Rot-Einfärben)
  • Die Verbindung zwischen Fehlermeldung und Formularfeld (muss vom Screen Reader vorgelesen werden)
  • Müssen dem User einen konkreten Hinweis auf die Lösung geben

6. Komplexe Komponenten:

Für Komponenten wie Tabs, Accordions, Modals, Date Pickers: Verlinke auf das entsprechende ARIA Authoring Practices Pattern und annotiere erwartetes Keyboard-Verhalten.

Wichtig: Keine ARIA ist besser als schlechtes ARIA.
Bevor du ARIA verwendest, lies folgenden Artikel: No ARIA is better than Bad ARIA

Empfohlene Werkzeuge für Accessibility Annotations:

Video-Empfehlung:

  • Alt-Text Annotations in Stark for Figma and Sketch

Alt-Text Konzeption – eine Designaufgabe, keine Redaktionsaufgabe

Wer ist verantwortlich für Alt-Texte – Design oder Redaktion?

Alt-Texte sind die Textalternative für Bilder – sie werden von Screen Readern vorgelesen, erscheinen wenn ein Bild nicht lädt, und werden von Suchmaschinen indexiert. Für Nutzer, die Bilder nicht sehen können, sind sie die einzige Möglichkeit, den Bildinhalt zu verstehen, denn der ALT Text wird vom Screen Reader vorgelesen.

Alt-Texte sind keine pauschale Designaufgabe – die Verantwortung hängt davon ab, wer das Bild im Kontext platziert.

Als UX/UI Designer definierst du die Regeln: Welche Bilder sind dekorativ, welche informativ, welche funktional? Diese Prinzipien gehören in den Handover und ins Design-System.

Sobald ein Content Creator Bilder eigenständig über ein CMS hochlädt, liegt die Verantwortung für den konkreten Alt-Text bei ihm – er kennt den redaktionellen Kontext. Gibt es keinen Content Creator im Team, fällt diese Aufgabe an den Designer zurück.

Drei Fragen für jeden Alt-Text:

  1. Ist das Bild rein dekorativ? → alt="", kein Text nötig
  2. Trägt das Bild Information? → Was würde fehlen, wenn das Bild nicht da wäre? Das ist der Alt-Text.
  3. Ist das Bild ein Link oder Button? → Der Alt-Text beschreibt das Ziel, nicht das Bild.

Typische Fehler:

  • alt="Bild" oder alt="foto_homepage_hero_final.jpg" – bitte nie so im ALT Text beschreiben
  • Redundante Alt-Texte, die denselben Text wiederholen, der schon daneben steht
  • Dekorative Bilder mit informativem Alt-Text (Screen Reader lesen ihn trotzdem vor)

Ressource:

An alt Decision Tree (W3C)

4. Tastaturnavigation – auch Barrierefreiheit für UX Designer

Ist Tastaturnavigation eine Aufgabe für Designer oder Entwickler?

Tastaturnavigation wird oft als reine Entwickleraufgabe betrachtet – das ist ein Irrtum. Die Reihenfolge, in der Elemente fokussiert werden, ergibt sich aus dem visuellen Layout. Die Erkennbarkeit des Fokus-Indikators ist reine Designverantwortung. Beides muss im Design definiert werden, bevor Entwickler es umsetzen können.

Selbsttest für UX/UI Designer: Öffne dein Design (oder die implementierte Version) und navigiere ausschließlich per Tab-Taste:

  • Weißt du immer, wo du gerade bist?
  • Ergibt die Reihenfolge logisch Sinn?
  • Kommst du zu allen interaktiven Elementen?
  • Kommst du aus Modals und Dropdowns wieder heraus (Escape)?

A11yCast Videos zu Tastaturnavigation:

A11yCasts #03 – What is focus?

A11yCasts#04 – Controlling focus wit tabindex

Keyboard Navigation | Accessibility with JSer

A11yCasts #18 – Why headings and landmarks are so important

5. Screen Reader – Grundwissen für Barrierefreiheit UX Designer

Müssen UX/UI Designer Screen Reader beherrschen?

Nein – du musst kein Experte werden. Aber 10 Minuten mit VoiceOver auf deinen eigenen Designs zeigen dir mehr als jede Checkliste. Du hörst sofort, wo Informationen fehlen, wo die Reihenfolge keinen Sinn ergibt, und welche Elemente keinen verständlichen Namen haben.

VoiceOver (macOS) – Schnelleinstieg

VoiceOver (macOS) Official guide & shortcuts

  • Command + F5: Start/ End VoiceOver
  • Control: Stop reading
  • Control + Option + Command + H: Next heading
  • Control + Option + Command + J: Next form field
  • Control + Option + U – opens: VoiceOver- Menue In Menue Jump between sections & landmarks, headings, links, form fields, etc.

A11yCasts #07 – Screen reader basics VoiceOver MacOS

A11yCasts – Assistive Tech: VoiceOver on Mobile iOS

Talkback (Adroid Screenreader)

A11yCasts – Assistive Tech: TalkBack Android

TalkBack aktivieren: https://support.google.com/accessibility/android/answer/6007100

NVDA & JAWS (Windows)

Für Designer die relevanten Einstiegspunkte:

Tipp: NVDA + Firefox ist die Kombination, die du für Tests nutzen solltest – sie entspricht dem, was viele Windows-Nutzer mit Sehbehinderungen tatsächlich verwenden.

6. Trainings: Barrierefreiheit für UX Designer lernen

Kostenlose Trainings

Wo kann ich als UX/UI Designer Barrierefreiheit kostenlos lernen?

Kostenpflichtige Trainings

  • Deque University Tiefes Verständnis in über 200 Stunden Trainings und Zertifikaten. Unter anderem Vorbereitung für das IAAP Zertifikat. Web Accessibility Curriculum: 250 USD | Full Access: 450 USD: Deque University

Ressourcen zu Barrierefreiheit im UX Design

Was kommt als Nächstes?

Digitale Barrierefreiheit ist eine Teamaufgabe. Als UX/UI Designer arbeitest du eng mit Entwicklern, QA und Product Ownern zusammen. Schau dir an, wie andere Rollen im Team Barrierefreiheit angehen:

  • → Entwickler-Guide: Wie deine Design-Entscheidungen in Code umgesetzt werden
  • → QA-Guide: Wie Barrierefreiheit getestet wird – und wie du dabei helfen kannst
  • → Product Owner Guide: Warum Barrierefreiheit im Sprint priorisiert werden muss
  • → WCAG 2.2 Überblick: Alle relevanten Neuerungen kompakt erklärt