Barrierefreiheit im Design-Prozess verankern

1. Warum nachträgliches Fixen teurer ist als Design-first

In der Softwareentwicklung gilt seit Jahrzehnten eine Faustregel für Fehlerkosten: Ein Fehler, der in der Konzeptionsphase entdeckt wird, kostet ein Vielfaches weniger als derselbe Fehler nach dem Launch. Bei Barrierefreiheit gilt dieselbe Logik, wird in der Praxis aber häufig ignoriert. Ein Kontrastproblem, das im Mockup mit einem Klick auf einen anderen Grauton behoben werden kann, wird nach der Entwicklung zu einer Suche durch Dutzende Templates, CSS-Dateien und Komponenten, in denen die Farbe fest verdrahtet wurde. Was im Design fünf Minuten kostet, kostet im Code oft mehrere Personentage, weil jede Verwendungsstelle einzeln gefunden, geändert und erneut getestet werden muss.

Noch teurer wird es, wenn strukturelle Probleme erst nach dem Launch auffallen, etwa eine fehlende Fokusreihenfolge in einem mehrstufigen Checkout oder ein Formular ohne semantische Struktur. Solche Mängel lassen sich selten mit einem CSS-Patch beheben, sie erfordern eine Überarbeitung der HTML-Struktur, erneute Tests mit Screenreadern und oft eine komplette Regressionsprüfung des betroffenen Flows. Für Magento- und Hyvä-Shops in Deutschland kommt seit dem Barrierefreiheitsstärkungsgesetz (BFSG) noch ein rechtliches Risiko hinzu: Nachbesserungen unter Zeitdruck, weil eine Prüfstelle oder ein Nutzer eine Barriere gemeldet hat, sind teurer und stressiger als geplante Qualitätssicherung im Design-Prozess.

2. Shift-Left: Barrierefreiheit ab der Wireframe-Phase mitdenken

Shift-Left stammt ursprünglich aus dem Testing und beschreibt, Qualitätssicherung so früh wie möglich im Entwicklungsprozess zu verankern, statt sie ans Ende zu schieben. Auf Barrierefreiheit übertragen bedeutet das: Bereits beim ersten Wireframe wird die Frage gestellt, in welcher Reihenfolge Informationen für einen Screenreader-Nutzer sinnvoll sind, nicht erst beim HTML-Markup. Designer, die Überschriftenhierarchie, Landmark-Bereiche und Lesereihenfolge schon in der Skizze mitdenken, liefern Entwicklern eine Vorlage, die sich direkt in semantisches HTML übersetzen lässt, statt nachträglich interpretiert werden zu müssen.

In der Praxis heißt das konkret: Design-Tools wie Figma erlauben es, Frames mit Annotationen für Layer-Reihenfolge, Kontrastwerte und ARIA-Rollen zu versehen, bevor ein einziger Entwickler involviert ist. Design-Tokens, also die zentral gepflegten Werte für Farben, Abstände und Typografie, sollten von Anfang an kontrastsicher definiert werden, damit jede Komponente, die auf diese Tokens zugreift, automatisch WCAG-konform bleibt. Das folgende Beispiel zeigt, wie ein Farbtoken-Set als CSS-Custom-Properties exportiert wird, inklusive Kommentar zum geprüften Kontrastverhältnis.

/* Design tokens exported from Figma variables */
/* Each color pair is pre-validated against its intended background */
:root {
  /* Text on white background, contrast ratio 7.2:1 (AAA) */
  --color-text-primary: #27272a;

  /* Secondary text on white background, contrast ratio 4.6:1 (AA) */
  --color-text-secondary: #52525b;

  /* Placeholder text, informational only, not required to meet 4.5:1 */
  --color-text-placeholder: #a1a1aa;

  /* Primary button background, white text on top, contrast ratio 8.1:1 */
  --color-button-primary-bg: #18181b;
  --color-button-primary-text: #ffffff;

  /* Error state, text on white background, contrast ratio 5.9:1 */
  --color-error: #b91c1c;
}

/* Component consuming the tokens automatically stays WCAG-compliant */
.form-label {
  color: var(--color-text-primary);
}
.form-hint {
  color: var(--color-text-secondary);
}

3. Kontrastprüfung bereits im Mockup durchführen

Farbkontrast ist der am einfachsten im Design zu prüfende Barrierefreiheitsaspekt und gleichzeitig einer der häufigsten Verstöße in Live-Shops. WCAG 2.2 verlangt für normalen Text ein Kontrastverhältnis von mindestens 4,5:1 gegenüber dem Hintergrund auf Level AA, für großen Text ab 18pt oder 14pt fett mindestens 3:1. Plugins wie Stark, Able oder die eingebauten Kontrastwerkzeuge moderner Design-Tools berechnen dieses Verhältnis direkt im Mockup, während die Farbe noch änderbar ist, nicht erst nachdem sie in dreißig Templates verbaut wurde.

Für Design-Systeme lohnt sich zusätzlich eine automatisierte Prüfung der Farbpalette, sodass neue Farbkombinationen nicht versehentlich unter den Grenzwert rutschen. Die Berechnung basiert auf der relativen Luminanz beider Farben nach der WCAG-Formel. Ein kleines Skript, das diese Prüfung als Teil der Design-Token-Pipeline ausführt, verhindert, dass ein neuer Grauton für sekundären Text unbemerkt unter 4,5:1 fällt, lange bevor ein Entwickler die Farbe in Code übernimmt.

// Contrast validation script, run against design tokens before export
// Implements the WCAG relative luminance formula

function relativeLuminance(hex) {
  const [r, g, b] = hexToRgb(hex).map((channel) => {
    const c = channel / 255;
    return c <= 0.03928 ? c / 12.92 : Math.pow((c + 0.055) / 1.055, 2.4);
  });
  return 0.2126 * r + 0.7152 * g + 0.0722 * b;
}

function contrastRatio(hexForeground, hexBackground) {
  const l1 = relativeLuminance(hexForeground);
  const l2 = relativeLuminance(hexBackground);
  const lighter = Math.max(l1, l2);
  const darker = Math.min(l1, l2);
  return (lighter + 0.05) / (darker + 0.05);
}

function hexToRgb(hex) {
  const value = hex.replace('#', '');
  return [0, 2, 4].map((i) => parseInt(value.substring(i, i + 2), 16));
}

const tokens = {
  textSecondary: '#52525b',
  background: '#ffffff',
};

const ratio = contrastRatio(tokens.textSecondary, tokens.background);
if (ratio < 4.5) {
  throw new Error(`Token textSecondary fails AA: ${ratio.toFixed(2)}:1`);
}
console.log(`textSecondary passes AA: ${ratio.toFixed(2)}:1`);

4. Fokusreihenfolge im Design annotieren

Die visuelle Reihenfolge in einem Mockup entspricht nicht automatisch der Reihenfolge, die ein Tastaturnutzer beim Durchtabben erlebt, besonders bei mehrspaltigen Layouts, Karten-Rastern oder Formularen mit nebeneinander angeordneten Feldern. Ohne explizite Annotation entscheidet der Entwickler die Fokusreihenfolge nach eigenem Ermessen, oft einfach in der Reihenfolge, in der die Elemente im Quellcode landen, was nicht zwingend der beabsichtigten Lesereihenfolge des Designs entspricht. Eine nummerierte Overlay-Annotation direkt auf dem Frame, die die intendierte Tab-Reihenfolge zeigt, beseitigt diese Unsicherheit vollständig.

Besonders wichtig ist diese Annotation bei Modals, mehrstufigen Formularen und Custom-Komponenten wie Datepickern oder Comboboxen, bei denen die DOM-Reihenfolge stark von der visuellen Anordnung abweichen kann. Entwickler sollten die Reihenfolge dabei primär über die Quellcode-Reihenfolge im DOM lösen, nicht über positive tabindex-Werte, die schwer wartbar sind und leicht zu Inkonsistenzen führen. Das folgende Beispiel zeigt, wie eine im Design nummerierte Reihenfolge in eine natürliche DOM-Reihenfolge übersetzt wird, mit Kommentaren, die auf die jeweilige Design-Annotation verweisen.

<!-- Focus order annotated in the design frame as 1-5, mapped here via DOM source order -->
<!-- WRONG: relying on positive tabindex to force an order -->
<div class="checkout-summary">
  <input type="text" name="promo-code" tabindex="3">
  <button type="submit" tabindex="1">Bestellung abschließen</button>
  <a href="/warenkorb" tabindex="2">Zurück zum Warenkorb</a>
</div>

<!-- RIGHT: source order matches the intended focus order from the design annotation -->
<div class="checkout-summary">
  <!-- design annotation #1 -->
  <a href="/warenkorb" class="checkout-summary__back">Zurück zum Warenkorb</a>

  <!-- design annotation #2 -->
  <label for="promo-code">Gutscheincode</label>
  <input type="text" id="promo-code" name="promo-code">

  <!-- design annotation #3 -->
  <button type="submit">Bestellung abschließen</button>
</div>

5. Touch-Target-Größen und Abstände festlegen

WCAG 2.2 hat mit Erfolgskriterium 2.5.8 "Target Size (Minimum)" auf Level AA eine Mindestgröße von 24 mal 24 CSS-Pixeln für interaktive Elemente eingeführt, mit definierten Ausnahmen etwa für Inline-Links in Fließtext oder wenn ein gleichwertiges größeres Ziel an anderer Stelle verfügbar ist. Das strengere Erfolgskriterium 2.5.5 "Target Size (Enhanced)" auf Level AAA empfiehlt sogar 44 mal 44 Pixel. Wenn diese Maße nicht im Design-System als Mindestwert für Buttons, Icons und interaktive Karten festgelegt sind, entscheidet am Ende jeder Entwickler individuell, wie groß ein Klickbereich sein muss, mit entsprechend uneinheitlichen Ergebnissen.

In der Praxis betrifft das besonders kompakte UI-Elemente wie Icon-Buttons in Filterleisten, Paginierungspfeile oder Schließen-Symbole in Modals, die im Desktop-Mockup ausreichend groß wirken, in der mobilen Ansicht aber unter die Mindestgröße rutschen, wenn Breakpoints nicht separat geprüft werden. Neben der reinen Zielgröße ist der Abstand zwischen benachbarten Touch-Targets entscheidend, um versehentliches Antippen des falschen Elements zu vermeiden. Ein Design-System sollte deshalb sowohl Mindestgrößen als auch Mindestabstände als wiederverwendbare Spacing-Tokens definieren.

/* Touch target tokens, enforced across every interactive component */
:root {
  --target-size-min: 24px;   /* WCAG 2.5.8 Level AA minimum */
  --target-size-comfort: 44px; /* WCAG 2.5.5 Level AAA recommended */
  --target-spacing-min: 8px;   /* minimum gap between adjacent targets */
}

/* Icon button, visually 20px icon, but the tappable area meets the minimum */
.icon-button {
  min-width: var(--target-size-comfort);
  min-height: var(--target-size-comfort);
  display: inline-flex;
  align-items: center;
  justify-content: center;
  padding: 0;
}
.icon-button svg {
  width: 20px;
  height: 20px;
}

/* Pagination links spaced to avoid accidental adjacent taps */
.pagination__item + .pagination__item {
  margin-left: var(--target-spacing-min);
}

6. Accessibility Acceptance Criteria im Design-Handoff verankern

Ein Design-Handoff, der nur visuelle Spezifikationen wie Farben, Abstände und Typografie enthält, lässt alle Fragen zu Tastaturbedienung, Screenreader-Verhalten und ARIA-Struktur offen, sie werden dann implizit vom Entwickler entschieden, meist unter Zeitdruck und ohne Rücksprache mit dem Design. Accessibility Acceptance Criteria sind explizite, testbare Anforderungen, die zusammen mit den visuellen Spezifikationen an jedes Ticket im Handoff angehängt werden: erwartetes Tastaturverhalten, sichtbare Fokus-Indikatoren, Screenreader-Ankündigungstext für dynamische Statusänderungen und die erwartete Semantik, etwa ob ein Element als Button oder als Link ausgezeichnet werden soll.

Der Effekt auf die Definition of Done ist erheblich: Ein Ticket gilt nicht mehr als fertig, wenn es "optisch passt", sondern erst, wenn die dokumentierten Accessibility-Kriterien nachweislich erfüllt sind. Das verschiebt auch Testfälle nach vorne, weil QA und Entwicklung die Kriterien bereits kennen, bevor die erste Zeile Code geschrieben wird, statt sie erst am Ende des Sprints zu improvisieren. Das folgende Beispiel zeigt ein JSON-Template für ein Handoff-Ticket mit expliziten Accessibility Acceptance Criteria.

{
  "ticket": "PDP-482",
  "component": "Produktbild-Galerie mit Miniaturansichten",
  "visualSpec": {
    "figmaFrame": "PDP / Gallery / v3",
    "breakpoints": ["mobile", "tablet", "desktop"]
  },
  "accessibilityAcceptanceCriteria": [
    "Miniaturansichten sind per Pfeiltasten navigierbar, wenn eine den Fokus hat",
    "Aktives Miniaturbild hat aria-current='true' und einen sichtbaren Fokusring",
    "Hauptbild-Wechsel wird per aria-live='polite' angekündigt: 'Bild 2 von 6'",
    "Jedes Miniaturbild hat ein alt-Attribut mit Produktdetail, nicht nur 'Bild 2'",
    "Touch-Target jeder Miniaturansicht mindestens 44 mal 44 CSS-Pixel",
    "Kontrastverhältnis des aktiven Rahmens mindestens 3:1 zum Hintergrund"
  ],
  "testMethod": "Tastaturtest + NVDA/VoiceOver + axe-core automatisiert",
  "status": "ready-for-development"
}

7. Designer und Entwickler: geteilte Verantwortung statt Silodenken

Ein verbreitetes Organisationsmuster behandelt Barrierefreiheit als reine Entwickler-Aufgabe, die am Ende des Sprints von QA abgehakt wird. Dieses Muster übersieht, dass viele Barrieren bereits im Design entstehen und dort mit deutlich geringerem Aufwand vermieden werden können als im Code. Designer benötigen dafür ein Grundverständnis der WCAG-Prinzipien, nicht auf dem Niveau eines Entwicklers, aber ausreichend, um Kontrast, Fokusreihenfolge und Zielgrößen selbstständig zu beurteilen, bevor ein Mockup den Entwicklungsprozess erreicht.

Praktisch lässt sich das über feste Rituale verankern: eine Accessibility-Prüfung als fester Bestandteil jedes Design-Reviews, bevor die Entwicklung beginnt, gemeinsame Pairing-Sessions, in denen Designer und Entwickler gemeinsam einen Screenreader ausprobieren, und eine geteilte Checkliste, die nicht nur der QA gehört, sondern von beiden Rollen gepflegt wird. Ein benannter Accessibility-Champion pro Team, der nicht zwingend Entwickler sein muss, hält das Thema sichtbar und verhindert, dass Verantwortung zwischen Design und Entwicklung diffundiert.

8. Barrierefreie Design-Systeme und Komponenten-Bibliotheken

Der größte Hebel für Barrierefreiheit im Design-Prozess liegt in der Komponenten-Bibliothek selbst. Wird Barrierefreiheit einmal korrekt in der Basis-Komponente eines Buttons, Formularfelds oder Modals im Design-System verankert, inklusive Kontrast, Fokus-Zustand und erwarteter ARIA-Semantik, profitiert jede einzelne Verwendung dieser Komponente automatisch davon, ohne dass jedes Team die gleiche Prüfung wiederholen muss. Umgekehrt vervielfacht sich ein einziger Fehler in der Basis-Komponente über jede Stelle, an der sie eingesetzt wird, weshalb die Sorgfalt an dieser Stelle besonders hoch sein sollte.

Damit Design-System und Code-Komponenten nicht auseinanderdriften, sollte jede Figma-Komponente mit dem entsprechenden Hyvä- oder Alpine.js-Pattern in einer gemeinsamen Dokumentation, etwa über Storybook oder eine interne Pattern-Library, verknüpft sein. Änderungen an der Design-Komponente lösen dann eine Prüfung aus, ob die entsprechende Code-Komponente noch synchron ist. Eine kurze Accessibility-Checkliste pro Komponente, direkt in der Dokumentation, macht die Anforderungen für jedes Team nachvollziehbar, statt sie in einem separaten, selten gelesenen WCAG-Dokument zu verstecken.

9. Design-Phase vs. nachträgliche Fixes im Vergleich

Die folgende Übersicht stellt typische Barrierefreiheits-Aufgaben gegenüber, einmal gelöst in der Design-Phase und einmal nachträglich nach dem Launch behoben. Der Aufwandsunterschied macht deutlich, warum sich die Investition in frühe Prüfungen auszahlt.

In allen fünf Fällen liegt der Unterschied nicht an der fachlichen Schwierigkeit der Lösung selbst, sondern am Zeitpunkt, an dem sie einfließt. Eine im Mockup falsch gewählte Farbe zu ändern kostet einen Klick, dieselbe Farbe in fünfzig ausgelieferten Templates zu finden und zu ersetzen kostet Tage und birgt zusätzliches Regressionsrisiko.

10. Zusammenfassung

Barrierefreiheit im Design-Prozess zu verankern ist kein Luxus, sondern die wirtschaftlich sinnvollste Reihenfolge, in der Accessibility-Arbeit stattfinden kann. Ein Kontrastfehler kostet im Mockup einen Klick, im Code oft Tage. Fokusreihenfolge lässt sich mit einer nummerierten Annotation im Frame festlegen, statt nachträglich per tabindex-Hacks im Markup gerettet zu werden. Touch-Target-Größen von mindestens 24 mal 24, besser 44 mal 44 CSS-Pixel gehören als Spacing-Token ins Design-System, nicht in die individuelle Entscheidung einzelner Entwickler.

Accessibility Acceptance Criteria im Design-Handoff machen aus impliziten Annahmen explizite, testbare Anforderungen und verschieben Testfälle an den Anfang des Prozesses. Der größte Hebel liegt in der Komponenten-Bibliothek: Einmal korrekt gelöst, profitiert jede Verwendung automatisch. Am Ende braucht es eine geteilte Verantwortung zwischen Design und Entwicklung, keine Silostruktur, in der Barrierefreiheit erst am Ende des Sprints als Nachbesserung auftaucht.

11. FAQ: Barrierefreiheit im Design-Prozess verankern