Bild: Mit KI generiert

WCAG-Konformität gilt in vielen Teams als Entwicklungsaufgabe. Sie wird geprüft, nachdem das Interface gebaut ist: mit Lighthouse-Scores, automatisierten Accessibility-Tests und nachträglichen Korrekturen. Diese Reihenfolge ist teuer.

Die meisten Accessibility-Probleme in SaaS-Interfaces entstehen nicht, weil Entwickler:innen schlecht implementiert haben. Sie entstehen, weil Designer:innen Entscheidungen getroffen haben, die Accessibility strukturell ausschließen: Farbkombinationen ohne ausreichenden Kontrast, Fokuszustände ohne sichtbaren Indikator, Formulare ohne semantisch verknüpfte Labels. Diese Entscheidungen treffen Designer:innen, nicht Entwickler:innen; und sie lassen sich am einfachsten in der Designphase korrigieren, nicht danach.

Seit dem 28. Juni 2025 müssen viele digitale Produkte und Dienstleistungen für Verbraucher:innen die Anforderungen des Barrierefreiheitsstärkungsgesetzes erfüllen. Dazu können auch SaaS-Anwendungen gehören, sofern sie unter die vom Gesetz erfassten Dienstleistungen fallen. Das schafft rechtliche Dringlichkeit. Aber der eigentliche Grund, Accessibility in die Designpraxis zu integrieren, ist ein anderer: Interfaces, die für alle nutzbar sind, sind besser designte Interfaces.

In diesem Artikel erfährst du, welche Designentscheidungen WCAG-Konformität vorentscheiden, wie Kontrastwerte, Fokuszustände und Formularstruktur als Designsystem-Entscheidungen behandelt werden können und was Web App & SaaS Design in der Praxis von Accessibility verlangt.

Warum Accessibility eine Designaufgabe ist

Die Trennung zwischen Design und Accessibility ist ein organisatorisches Missverständnis. WCAG 2.2 — der Standard, auf den sich BFSG und der European Accessibility Act beziehen — definiert Anforderungen an Interfaces. Nicht an Code. Nicht an Entwicklungspraktiken. An das, was Nutzer:innen sehen, hören und bedienen.

Was das konkret bedeutet: Ein Button, dessen Farbe keinen ausreichenden Kontrast zum Hintergrund hat, verletzt WCAG-Anforderungen durch eine Designentscheidung. Ein Formularfeld, das keinen sichtbaren Focus State hat, verletzt WCAG durch ein fehlendes Designelement. Eine Fehlermeldung, die ausschließlich durch Farbe kommuniziert, verletzt WCAG durch eine UI-Copy-Entscheidung.

In allen drei Fällen liegt die Lösung in Figma, nicht im Code. Das ist kein Vorwurf; es ist eine Einladung: Designer:innen haben mehr Einfluss auf Accessibility-Ergebnisse als sie oft wissen.

Kontrast als Design-Token-Entscheidung

WCAG 2.2 Level AA verlangt für normalen Fließtext ein Kontrastverhältnis von mindestens 4,5:1 zwischen Textfarbe und Hintergrundfarbe. Für große Schrift ab 18 Punkt oder 14 Punkt fett gilt ein Mindestwert von 3:1.

Diese Anforderung klingt technisch. Sie ist in ihrer Konsequenz für die Designpraxis aber klar: Jede Farbkombination, die für Text und Hintergrund gewählt wird, ist eine Accessibility-Entscheidung. Wer Farben als Design Tokens mit semantischer Benennung strukturiert — color/text/primary referenziert auf gray-900 im Light Mode — kann Kontrastverhältnisse einmal definieren und systemweit durchsetzen. Wer Farben als individuelle Entscheidungen pro Komponente trifft, muss jede Kombination einzeln prüfen.

Die praktische Konsequenz für den Figma-Workflow: Kontrastverhältnisse gehören in die Token-Definition, nicht in den Review-Schritt. Tools wie das Figma-Plugin Stark ermöglichen Kontrast-Checks direkt im Design-Tool — bevor ein Screen in die Entwicklung übergeben wird.

Eine häufig übersehene Anforderung betrifft auch nicht-textuelle Elemente: Icons, Diagramme und UI-Komponenten wie Checkboxen oder Radiobuttons benötigen ein Kontrastverhältnis von mindestens 3:1 gegenüber dem Hintergrund. Das gilt auch für die Grenzen von Input-Feldern: ein hellgrauer Border auf weißem Hintergrund kann diese Anforderung verfehlen.

Focus States als vollständige Interaction-Design-Entscheidung

Der Focus State ist der in der Designpraxis am häufigsten unvollständig behandelte UI-State. In vielen Figma-Dateien existiert er gar nicht, weil er visuell unerwünscht scheint oder weil angenommen wird, dass Browser-Defaults ausreichen.

WCAG 2.2 hat mit den Erfolgskriterien 2.4.11 (Focus Not Obscured, Level AA) und 2.4.12 (Focus Not Obscured Enhanced, Level AAA) die Anforderungen an Focus Management verschärft: Ein fokussiertes Element muss sichtbar sein und darf nicht vollständig von anderen Inhalten verdeckt werden. Das ist eine direkte Antwort auf ein häufiges SaaS-Design-Muster: Sticky Headers und Modals, die den Fokusindikator eines Elements verdecken, das mit der Tastatur fokussiert wurde.

Der Focus State ist, wie im UI States Artikel beschrieben, für Nutzer:innen, die nicht mit der Maus navigieren, die einzige Orientierung im Interface. Für Keyboard-only User, Nutzer:innen assistiver Technologien und Personen mit motorischen Einschränkungen ist ein nicht sichtbarer Focus State keine Designentscheidung, es ist eine Barriere.

Was professionelles Focus-Design in SaaS-Interfaces ausmacht:

Ein Focus Ring, der ausreichend Kontrast zur Umgebung hat — nicht nur zum Hintergrund, sondern auch zum Element selbst. Eine Mindestgröße, die auch auf kleinen Elementen sichtbar ist. Konsistenz über alle interaktiven Elemente hinweg: Buttons, Links, Inputfelder, Dropdowns, Cards mit Klick-Interaktion. Und eine bewusste Entscheidung, ob der Focus Ring dem Brand-System folgt oder ob er als systemisches Accessibility-Element behandelt wird, das unabhängig vom visuellen Stil funktionieren muss.

Keyboard Navigation als Interaktionsarchitektur-Entscheidung

Keyboard-Bedienbarkeit ist WCAG-Anforderung (Erfolgskriterium 2.1.1) und gleichzeitig eines der komplexesten Designprobleme in SaaS-Interfaces. Komplexe Komponenten wie Data Tables, Multi-Select-Dropdowns, Date Pickers und Drag-and-Drop-Interfaces erfordern explizite Designentscheidungen über Tastaturinteraktionsmuster.

Für Browser-App-spezifische Komponenten gibt es etablierte Keyboard-Interaktionsmuster aus dem ARIA Authoring Practices Guide. Diese definieren, wie komplexe Widgets per Tastatur bedienbar sein sollen: welche Tasten welche Aktionen auslösen, wie der Fokus innerhalb einer Komponente verwaltet wird und wie Tab-Reihenfolge und Pfeiltasten-Navigation zusammenspielen.

Was das für die Designpraxis bedeutet: Die Tab-Reihenfolge einer Seite ist eine Informationsarchitektur-Entscheidung. Sie sollte dem visuellen Fluss entsprechen und kommunizieren, welche Aktionen in welcher Reihenfolge logisch sind. Wenn ein Modal geöffnet wird, muss der Fokus in das Modal springen — und beim Schließen zurück zum auslösenden Element. Das ist kein Implementierungsdetail, das Entwickler:innen entscheiden. Es ist eine Interaction-Design-Entscheidung, die im Prototypen spezifiziert werden sollte.

Formulare: Wo die meisten Accessibility-Fehler entstehen

Formulare sind in SaaS-Interfaces einer der häufigsten Accessibility-Schwachpunkte, und gleichzeitig der Bereich, in dem Designer:innen den größten Einfluss haben.

Label-Positionierung und semantische Verknüpfung. Ein Placeholder-Text, der das Label ersetzt, ist keine WCAG-konforme Lösung. Placeholders verschwinden beim ersten Zeichen der Eingabe, haben häufig zu geringen Kontrast und werden von Screenreadern nicht zuverlässig als Labels erkannt. Labels gehören über oder neben das Inputfeld: sichtbar, auch wenn das Feld befüllt ist.

Fehlermeldungen ohne Farbe als einziges Signal. Eine rote Umrandung des Inputfelds kommuniziert einen Fehler ausschließlich über Farbe. Das verstößt gegen WCAG 1.4.1 (Verwendung von Farbe). Fehlermeldungen brauchen zusätzlich eine textuelle Beschreibung des Problems — und im Idealfall eine konkrete Handlungsaufforderung, was zu tun ist.

Pflichtfelder erkennbar machen. Das Asterisk (*) als Pflichtfeld-Markierung ist weit verbreitet und kann accessibility-konform eingesetzt werden — wenn erklärt wird, was es bedeutet. Eine Legende zu Beginn des Formulars, die das Symbol erklärt, ist WCAG-Anforderung.

Error States als vollständige Komponenten. Ein Formularfeld hat mindestens fünf relevante Zustände: Default, Focus, Filled, Error und Disabled. Wer Error States als vollständige Komponenten designed, mit sichtbarer Fehlermarkierung, textueller Fehlermeldung und möglichst sofortiger Inline-Validierung nach Verlassen des Feldes, trifft eine Accessibility-Entscheidung und eine UX-Entscheidung gleichzeitig.

Accessibility als Designsystem-Eigenschaft

Der effektivste Weg, Accessibility in SaaS-Interfaces zu sichern, ist nicht eine abschließende Prüfung; es ist die Integration in das Designsystem.

Kontrastverhältnisse als Eigenschaft von Token-Paaren definieren, nicht als nachträgliche Prüfung. Focus States als vollständige Komponentenvariante anlegen, nicht als optionale Ergänzung. Error States und Label-Strukturen als Systemstandard setzen, nicht als Ausnahmefall.

Dieser Ansatz verbindet Accessibility direkt mit dem, was gutes Komponentendesign ohnehin auszeichnet: Vollständigkeit, Konsistenz und Skalierbarkeit. Eine Komponente ohne Focus State ist kein Accessibility-Problem, sie ist eine unfertige Komponente.

Take Away Message

Accessibility im SaaS-Design beginnt nicht mit einem Audit. Sie beginnt mit der Frage, welche Designentscheidungen Nutzer:innen einschließen oder ausschließen — bevor eine Zeile Code geschrieben wird. Kontrastverhältnisse, Focus States, Keyboard-Interaktionsmuster und Formularstrukturen sind Designaufgaben. Wer sie als Systemstandard behandelt statt als Compliance-Schritt, baut Interfaces, die für alle funktionieren; und Entwickler:innen eine klare Spezifikation übergeben, statt nachträgliche Korrekturen zu produzieren.