Barrierefreiheit im digitalen Produktdesign

Wussten Sie, dass rund 40 % aller Probleme im Zusammenhang mit Barrierefreiheit bereits in der Designphase erkannt werden können?

Das ist eine beeindruckende Zahl, die verdeutlicht, wie wichtig die Designphase für die Entwicklung barrierefreier digitaler Produkte ist. Dennoch wird die Barrierefreiheit allzu oft erst während der Entwicklung oder sogar später berücksichtigt – wenn es möglicherweise schon zu spät oder zu kostspielig ist, um das Problem einfach zu beheben.

Bei Spaceteams erstellen wir zwar selbst keine visuellen Designs, arbeiten aber eng mit Designern aus internen Teams und externen Agenturen zusammen. Unsere Engineering-Teams sind in Best Practices für Barrierefreiheit geschult und in der Lage, Designentwürfe unter dem Gesichtspunkt der Barrierefreiheit zu bewerten. Unsere Erfahrung hat gezeigt, dass eine Übersicht der kritischen Punkte dabei hilft, potenzielle Probleme frühzeitig zu erkennen, bevor sie zu kostspieligen technischen Mängeln werden.

In diesem Artikel stellen wir unsere Übersicht für barrierefreies Design vor, die auf den Web Content Accessibility Guidelines (WCAG) und den W3C-Tipps für barrierefreies Webdesign basiert und durch praktische Erkenntnisse aus unserer eigenen Arbeit ergänzt wurde.

Hinweis: Diese Übersicht ist keine vollständige oder absolute Garantie für die Einhaltung der Barrierefreiheit, sondern ein Leitfaden, der Teams dabei helfen soll, gängige Probleme frühzeitig im Designprozess zu erkennen.

Warum Barrierefreiheit beim Design beginnt

Bevor wir uns mit den konkreten Themen befassen, möchten wir noch einmal betonen, warum das Design eine so wichtige Rolle für die Barrierefreiheit spielt:

• Designentscheidungen bestimmen die Benutzerfreundlichkeit: Farben, Schriftarten, interaktive Elemente – all dies bestimmt, wie Menschen mit einem digitalen Produkt interagieren.
• Frühzeitiges Beheben von Problemen spart Zeit und Kosten: Werden Barrieren bereits in der Designphase erkannt, lassen sich komplexe Korrekturen in der Umsetzung vermeiden. Neben den höheren Kosten führen späte Änderungen oft zu unnötigem Hin und Her zwischen Design- und Entwicklungsteams auf der Suche nach dem vermeintlich besten Kompromiss.
• Inklusives Design hilft allen: Barrierefreiheit verbessert die Benutzerfreundlichkeit für Menschen mit Behinderungen, kommt aber auch allen anderen Nutzern in unterschiedlichen Situationen zugute (z. B. bei hellem Sonnenlicht, langsamen Verbindungen oder an kleinen Screens).

Schauen wir uns nun die spezifischen Bereiche an, die wir bei der Überprüfung von Designs bewerten.

Die Basis: Farben, Schriftarten und Kontraste

Wenn Menschen an Barrierefreiheit denken, kommen ihnen oft zuerst Farben und Kontraste in den Sinn, und das aus gutem Grund. Diese Elemente lassen sich vergleichsweise einfach mit den eigenen Augen oder mit Tools (wie dem WebAIM Contrast Checker überprüfen:

• Der Kontrast zwischen Vordergrund (in der Regel Text, Schaltflächen oder ähnliche Elemente) und Hintergrund muss mindestens 4,5:1 betragen. Bei großformatigem Text (18 pt+ oder 14 pt+ fett) beträgt das erforderliche Verhältnis 3:1.
• Darüber hinaus gibt es einige Farbkombinationen, wie Rot und Grün, die für Nutzer mit Farbsehschwäche schwer zu unterscheiden sind. Viele Tools, z. B. das Silktide-Browser-Plugin, simulieren diese Beeinträchtigungen.
• Ein weiterer wichtiger Aspekt bei der Arbeit mit Farben ist, dass man sich niemals allein auf Farben verlassen sollte, um Bedeutungen zu vermitteln. Beispielsweise sollte man eine Statusänderung nicht durch einen Wechsel von Rot zu Grün anzeigen, da dies für Menschen mit Farbsehschwäche möglicherweise nicht wahrnehmbar ist. Das Hinzufügen eines Symbols oder eines erklärenden Textes ist hierbei hilfreich.
• Obwohl die WCAG keine Mindestschriftgröße vorschreibt, empfehlen bewährte Verfahren mindestens 14 pt für Fließtext und mindestens 18 pt für Überschriften.
• Wir empfehlen die Verwendung klarer, gut lesbarer Schriftarten mit unterscheidbaren Buchstabenformen und ausreichendem Abstand. Auch wenn serifenlose Schriftarten nicht vorgeschrieben sind, sind sie aufgrund ihrer Einfachheit oft eine gute Wahl.

Von oben betrachtet: Überschriften und ihre Struktur

Auch wenn sie nicht zu den klassischen visuellen Designelementen gehören, sind die Seitennavigation und die Überschriftenstruktur entscheidende Komponenten, die bereits in der Designphase berücksichtigt werden sollten – und nicht erst im Nachhinein.

Neben der Unterstützung assistiver Technologien bringt ein gut strukturiertes Überschriften-System weitere Vorteile mit sich: Es verbessert die Suchmaschinenoptimierung (SEO), erleichtert das schnelle Erfassen von Inhalten für sehende Nutzer:innen und reduziert die kognitive Belastung:

• Es sollte immer eine Hauptüberschrift (h1) geben, die das Hauptthema oder den Zweck der Seite definiert.
• Unterüberschriften sollten in einer sinnvollen Reihenfolge (h2 unter h1, h3 unter h2 usw.) angewandt werden und möglichst keine Ebenen übersprungen werden. Ein Sprung von h2 zu h4 sollte nur in Ausnahmen erfolgen, wenn die visuelle und strukturelle Hierarchie dies klar rechtfertigt.

Komplex, aber entscheidend: Interaktionen und Kontextwechsel

Einige Problemstellungen im Zusammenhang mit Interaktionen lassen sich in funktionierender Software leichter erkennen als in Designs – viele können und sollten jedoch bereits in der Designphase berücksichtigt werden:

• Interaktive Elemente benötigen klare, eindeutige Designs. Sie sollten sich immer deutlich von statischem Text abheben und im gesamten Produkt einheitlich gestaltet sein.
• Eine der häufigsten Interaktionen auf Websites betrifft Formulare, wobei mehrere wichtige Aspekte der Barrierefreiheit zu berücksichtigen sind:
  • Verwenden Sie deutlich sichtbare und beschreibende Beschriftungen, anstatt sich ausschließlich auf Platzhaltertext zu verlassen (dieser verschwindet in der Regel beim Tippen und ist nicht zuverlässig zugänglich).
  • Stellen Sie sicher, dass aktive Felder deutlich hervorgehoben sind und dass klare, dauerhafte Fehlermeldungen angezeigt werden.
• Ändern Sie den Benutzerkontext nicht automatisch! Das Design sollte keine Änderungen auslösen (z. B. Navigation, Öffnen von Modulen), es sei denn, der Benutzer interagiert ausdrücklich mit dem fokussierten Element. Plötzliche Kontextwechsel können Benutzer, die auf assistive Technologien angewiesen sind, verwirren.
  • Dies gilt auch für zeitlich begrenzte Elemente: Vermeiden Sie automatisch verschwindende Meldungen oder Inhalte, die zu schnell verstreichen, als dass Benutzer sie lesen oder darauf reagieren könnten.

Kritische Muster meistern: Gibt es einen besseren Weg?

Tastaturnavigation ist eine zentrale Anforderung an die Barrierefreiheit und wird häufig während der Entwicklungsphase berücksichtigt. Bestimmte Muster sollten jedoch bereits in der Designphase hinterfragt werden. Obwohl es technisch möglich ist, sie konform umzusetzen, führt ein Neudenken dieser Interaktionen oft zu besseren Gesamtergebnissen:

• Akkordeons oder ausblendbare Abschnitte: Wenn alle Inhalte wichtig sind, sollten Sie in Betracht ziehen, sie offen anzuzeigen, anstatt sie hinter Schaltflächen zu verstecken.
• Drag & Drop: Komplex für Nutzer, die nur die Tastatur verwenden. Wenn diese Funktion unbedingt verwendet werden soll, bieten Sie Alternativen wie Pfeile zum Neuanordnen an.
• Überlagerungen und Pop-Ups: Vermeiden Sie mehrere Überlagerungsebenen, da diese die Navigation erschweren und den Fokus beeinträchtigen können.

Weniger ist mehr: Bewegungen, Blinken, Animationen

Während sich manche Nutzer an ausschweifenden visuellen Effekten erfreuen, empfinden andere diese als überwältigend – und für manche sind sie sogar gefährlich. Wenn es um Bewegungen, Blinken und Animationen geht, bedeutet eine inklusive Erfahrung in der Regel: Weniger ist mehr.

• Vermeiden Sie schnell blinkende Elemente: Elemente, die mehr als dreimal pro Sekunde blinken, können bei Personen mit lichtempfindlicher Epilepsie Anfälle auslösen.
• Im Allgemeinen lenken bewegliche Elemente die Nutzer ab, was beispielsweise für Nutzer mit ADHS problematisch ist. Verwenden Sie Animationen sparsam und stellen Sie sicher, dass Nutzer Bewegungen bei Bedarf deaktivieren können.
• Dies gilt auch für Videos: Vermeiden Sie automatisch abspielende Videos oder Audiodateien. Nutzer sollten die Möglichkeit haben, die Wiedergabe zu pausieren, zu stoppen oder zu steuern.

Flexibles Design: Für alle Bildschirmgrößen mitgedacht

Design für mehrere Viewports (insbesondere für mobile Bildschirme) ist entscheidend! Das Gestalten für kleine Bildschirme hilft, häufige Probleme bei der Barrierefreiheit zu vermeiden, wie z. B. überlaufende Inhalte, unbrauchbare interaktive Elemente und schwer lesbare Textpassagen. Dabei achten wir insbesondere auf folgende Aspekte:

• Ausreichende Größe und Tippfläche: Touch-Targets (insbesondere auf Mobilgeräten) sollten groß genug sein, um bequem mit ihnen interagieren zu können.
• Horizontales scrollen vermeiden: Dies führt häufig zu einer schlechten Benutzererfahrung auf kleinen Bildschirmen. Layouts sollten nach Möglichkeit vertikal verlaufen.
• Zoomfaktor: Alle Schriftarten müssen bis zu 200 % vergrößerbar sein, ohne dass das Layout oder die Lesbarkeit beeinträchtigt wird (dies gilt für alle Viewports, nicht nur für mobile Geräte).

Fazit: „Shift Left“ – Zeit sparen und Vielfalt von Anfang an mitdenken

Genauso wie wir Software-Qualitätsprobleme frühzeitig erkennen wollen, sollte auch für die Barrierefreiheit im Entwicklungsprozess ein „Shift Left“ erfolgen. Eine späte Behebung von Barrieren – während der Entwicklung oder sogar nach der Produkteinführung – erhöht nicht nur die Kosten, sondern auch das Risiko, Nutzer zu verprellen, die auf inklusives Design angewiesen sind.

Bei Spaceteams betrachten wir Barrierefreiheit als gemeinsame Verantwortung. Auch wenn wir selbst keine Designer sind, überprüfen wir jedes Design, mit dem wir arbeiten, unter dem Gesichtspunkt der Barrierefreiheit.

Wir hoffen, dass diese Übersicht Designern, Entwicklern und Produktverantwortlichen hilft, inklusives Denken von Anfang an zu verankern.

Quellen:

MDN Web Docs - Web-Accessibility für Anfälle und körperliche Reaktionen

Mind the product - Why should we care about building accessible products

W3C - Designing for Web Accessibility

Jesse Hausler - 4 Major Patterns for Accessible Drag and Drop