Barrierefreies Design für Apps – Was du wissen solltest

Veröffentlicht am 31. Januar 2024
Eine Illustration von einem iPhone. Auf dem Bildschirm steht Swipe links oder rechts. Dann ein Bild eines unseres Maskottchens als attraktive Frau. Eine Anspielung auf eine Dating-App.

Digitale Barrierefreiheit auf mobilen Endgeräten bringt einiges an Probleme mit sich – zumindest für die Entwicklung. Für Designer*innen ändert sich tatsächlich gar nicht so viel. Trotz dessen gibt es einige Feinheiten und Problematiken im Designen von Apps und mobilen Anwendungen, die dir bekannt sein sollten, wenn du effektiv und effizient designen willst.

Hinweis 1: Auf die Größe kommt es an!

Wir starten einfach: Deine Bedienelemente (Buttons, Icons, Inputs) brauchen die richtige Größe. Auf Touchscreen-Geräten wie Tablets und Handy sollten deine Bedienelemente mindestens 24×24 Pixel groß sein (WCAG Level AA) – noch besser 44×44 Pixel (Level AAA). Zum WCAG Kriterium über Mindestgrößen (englisch)

Es sind zwei Schaltflächen mit Icons zu sehen. Die Erste ist nur 16 mal 16 Pixel und damit zu klein. Die Zweite ist 24 mal 24 Pixel und damit groß genug.

Menschen mit zum Beispiel Tremor benötigen größere Elemente, damit sie die Dinge in deiner App auch mit ihrem Finger treffen! Wenn du schon mal versucht hast, zu kleine Icon-Buttons in einer App zu betätigen, weißt du, wie frustrierend das sein kann – besonders, wenn sie auch noch zu nah beieinander liegen. Falls du nicht weißt, wovon ich spreche, empfehle ich dir mal die Seite von Lichess.org (Schach spielen) auf dem Handy auszuprobieren. (Sorry, Lichess!)

Warum ich diesen Hinweis als besonders wichtig empfinde: Als Designer weiß ich, dass Designer*innen gerne Platz sparen. Vermutlich haben dir deine Professoren das Konzept von “Weißraum” auch tief in dein Unterbewusstsein eingepflanzt. Design braucht viel Platz zum Atmen! Und da sich meistens die Content-Ersteller*innen mit ihren Texten nicht daran halten (ja, ihr seid die Bösen!) müssen wir das ausbaden und verkleinern unsere Elemente.

Ich hoffe, mit der Barrierefreiheit habt ihr jetzt ein weiteres Argument, um Texter*innen zu sagen, dass ihre Texte weniger werden müssen, weil eure Bedienelemente Platz brauchen!

Hinweis 2: Zoomen wird dir Albträume machen

Falls du ein iPhone hast:

  1. Öffne Safari
  2. Gehe auf eine beliebige Seite
  3. Klicke unten Links auf das Symbol mit den zwei A
  4. Vergrößere den Text auf 200 %
  5. Fange an zu weinen

Deine Webseite muss Texte auf 200 % Zoom unterstützen – auch auf mobile!

Muss mein Layout dann auch gleich aussehen? Zum Glück nicht. Das ist einfach nicht möglich. Dein Layout wird umbrechen und sich verändern. Allerdings darf dabei Folgendes nicht passieren:

  1. Es sollte keine horizontale Scrollbar entstehen. Formal ist ein horizontaler Scrollbalken bei 200% Vergrößerung kein Fehler. Zumindest nicht ausgehend von den Mindestanforderungen. Er ist nicht sonderlich schön, aber nicht “verboten”.
  2. Texte dürfen nicht von anderen Elementen verdeckt werden
  3. Texte dürfen nicht abgeschnitten werden (Durch einen Container mit overflow: hidden zum Beispiel)
  4. Alle Elemente müssen erreichbar und bedienbar sein

Hier ein Beispiel, wie schön 200 % Zoom aussehen kann. Einmal ist die mobile Ansicht, die Seite der Bundesagentur der Arbeit zu sehen und einmal von Google. Man sieht, wie schön das Layout wirkt! Ob der Button von Google, der über das Logo ragt, so barrierefrei ist, ist fragwürdig.

Zwei Screenshots von der Seite von Google und der Bundesagentur für Arbeit auf 200 % Zoom in der mobilen Ansicht.

Auf IOS gibt es explizit für Apps noch eine andere Methode, um Texte zu vergrößern: In den Barrierefreiheits-Einstellungen unter dem Punkt Anzeige & Textgröße kannst du einschalten, dass Apps größeren Text unterstützen sollen.

Auf dem Bild unten siehst du, dass du in den Systemeinstellungen “Größere dynamische Texte” mit einem Toggle anstellen kannst. Danach kannst du über den Slider unten einstellen, wie groß du den Text haben willst.

Wie zuvor erwähnt: Diese Einstellung verändert nur Schriften in Apps und nicht im Browser auf mobile.

Zwei Screenshots von den Barrierefreiheits-Einstellungen auf dem iPhone. Ein mal die Übersicht und ein mal die Einstellungen der Textgröße

IOS hat sogar eine eigene Design-Library mit Textgrößen für Barrierefreiheit, um dich beim Designen zu unterstützen.

Hier geht es zur IOS-Figma-Bibliothek

Hinweis 3: Bleibe bei nativen Elementen

Als Designer*in in Bezug auf digitale Barrierefreiheit hast du viel Macht! Und mit großer Macht kommt große Verantwortung, Peter.

Als Designer*in entscheidest du, welche UI-Komponenten du wählen willst. Und je nachdem, welche du wählst, kannst du Entwickler*innen damit ziemlich viel Freude oder ziemlich viel Ärger bereiten.

Wenn du eine Komponente wie ein Dropdown wählst und diese auf fancy Art und Weise stylen willst, kann dein Entwickler unter Umständen kein natives HTML mehr dafür verwenden. Das führt dazu, dass er die Komponenten selbst “bauen” muss. Das kostet ziemlich viel Zeit und Geld – besonders, weil so etwas extrem anfällig für Bugs bezüglich der Barrierefreiheit ist.

In dem folgenden Artikel unter dem Thema “Das Designprinzip der Robustheit” findest du detaillierte Informationen dazu, warum sich Designer*innen mit HTML auskennen sollten, wenn sie barrierefrei designen wollen. Zum Artikel über Designprinzipien der Barrierefreiheit

Wenn du eine Übersicht problematischer UI-Komponenten suchst, die du beim Designen vielleicht vermeiden solltest, muss ich hier frech Eigenwerbung für unseren Onlinekurs einstreuen: Kauf dir unseren Onlinekurs für Designer*innen, er ist gut! Zum Onlinekurs für Designer*innen

Native HTML-Elemente gibt es in Apps natürlich nicht. Hier gibt es aber native IOS oder Android-Komponenten, die du verwenden kannst oder sollst. Apple weist etwa explizit darauf hin, dass man die native Toggle-Komponente verwenden soll.

Auszug von der Apple-Seite über Barrierefreiheit: Nutze die vom System bereitgestellte Toggle-Switch-Komponenten von SwiftUI. Die Native-Komponente zeigt ihren Zustand durch die Position des Knopfes und durch die Füllfarbe an. Für einige Menschen ist es jedoch zusätzlich hilfreich, wenn eine weitere Beschriftung verdeutlicht, ob ein Schalter ein- oder ausgeschaltet ist. Wenn du den nativen Toggle von IOS verwendest, werden automatisch Ein-/Aus-Symbole angezeigt, wenn die Benutzer die Ein-/Aus-Etiketten in den Barrierefreiheits-Einstellungen angeschaltet haben.

Des Toggle von Apple. Ein mal mit zusätzlichen Icons und ein mal ohne.

Hinweis 4: Setze Animationen sparsam ein

Manchen Menschen wird von Animationen schwindlig oder übel! Deswegen solltest du Animationen vermeiden, es sei denn, sie sind für die User-Experience wirklich unerlässlich. Und selbst, wenn sie deiner Meinung nach unerlässlich sind, solle deine App auch ohne die Animationen funktionieren.

Apple bietet in den Barrierefreiheits-Einstellungen an, dass man “Animationen reduzieren” kann. Diese Einstellungen sollten bei deiner App dazu führen, dass Animationen abgeschaltet oder eben stark reduziert werden. Darum ist es besonders wichtig, dass es keine Animation gibt, die wichtige Informationen vermitteln. Wenn es sie gibt, sollte es eine nicht-animierte Alternative geben, um die gleichen Informationen zu erhalten.

Außerdem ist es nach der WCAG Pflicht, dass es eine Möglichkeit gibt, Animationen anzuhalten, die länger als 5 Sekunden dauern. Es muss also einen Pause-Knopf dafür geben. (Das gilt auch für Slider, die sich von selbst bewegen)

Eine Illustration von einem Slider auf einer Webseite. Der Slider hat ein Pause-Knopf, um ihn anzuhalten.

Zu Animationen ist noch zu sagen, dass du vorsichtig sein musst, wenn du sich bewegende oder blinkende Elemente einsetzt. Ich weiß, blinkende Dinge sind richtig dufte, um Aufmerksamkeit zu erhaschen, aber diese Effekte können im schlimmsten Fall sogar epileptische Anfälle auslösen. Wer das ganze mal in Aktion erleben will, für den ist die folgende Webseite ein Erlebnis: Zur Webseite mit ganz viel blinken (Achtung!)

Hinweis 5: Nicht jeder hat Hände!

Nun, irgendwann musste das auch mal gesagt werden: Es gibt Menschen, die ein Handy bedienen ohne Hände! Na gut, das heißt jetzt nicht zwangsweise, dass sie keine Hände haben. Eventuell gibt es andere Gründe, warum sie ein Handy mit bloßem Zwinkern, Switch-Schaltern oder Sip-And-Puff-Technologie bedienen. Nichtsdestotrotz: im Endeffekt heißt das, dass es Menschen gibt, die nicht mit ihren Fingern an einem Mobilgerät fummeln. Ergo, diese Menschen können keine Gesten ausführen. Sie können nicht pinchen, nicht swipen und ihr Handy nicht schütteln.

Wenn deine App Funktionen hat, die nur dadurch ausgelöst werden können (swipen nach links und rechts bei Dating-Apps zum Beispiel), dann hast du ein Problem mit der Barrierefreiheit. Darum haben Dating-Apps mittlerweile eingeführt, dass man nicht nur swipen, sondern auch einen Button klicken kann.

Jedes Mal, wenn du dir also als (Produkt-) Designer eine coole Art überlegst, wie man etwas mit den Händen in deiner App machen kann, musst du dir gleichzeitig eine klickbare Alternative ausdenken.

Fazit zum barrierefreien Design für Apps

Im Gegensatz zur Entwicklung ist barrierefreies Designen von Mobilen Anwendungen nicht so dramatisch unterschiedlich. Es gibt ein paar Dinge, die ihr berücksichtigen müsst, und die ihr jetzt hoffentlich kennt. Ansonsten solltet ihr die gleichen Standards einhalten, die eben generell für das barrierefreie Webdesign gelten.

Wenn du dich mit dem Thema bisher nicht wirklich auseinandergesetzt hast, empfehle ich dir diese beiden Beiträge: