Das kannst du für die mobile Barrierefreiheit tun

Marcy Sutton ist eine Barrierefreiheit Ingeneurin bei Adobe in Seatle. Sie wünscht sich, dass wirklich alle Menschen ihr Software benutzen können. Sie möchte das Bewusstsein für die Accessibility verbreiten und die Qualität von mobilen Web-Applikationen in dieser Hinsicht auf den Stand von native Apps bringen. Deswegen informiert sie andere Entwickler darüber, welchen Beitrag sie für einen barrierefreien mobilen Web leisten können.

Mobiles Web versus Native Apps

Wie sehen die Voraussetzungen für die Barrierefreiheit in diesen zwei Welten aus?
Native Applikationen sind klar im Vorteil. Sie genießen all die ausgearbeiteten und funktionierenden Richtlinien. In mobilen Applikationen gibt es keine Richtlinien und keine einheitliche Qualitätskontrolle. Jeder macht praktisch das, was er will oder was er kann.
Marcy ist überzeugt, dass mobiles Web nicht immer so schlecht in Sachen Barrierefreiheit sein wird. Dafür muss man sich die Frage stellen, wie konkret jeder Entwickler auf dem Weg für ein besseres mobiles Web mitwirken kann?

Accessibility Funktionen – iOS versus Android

In ihrem Talk in Berlin in 2015 zeigte sie eine Statistik über die Verwendung von Bildschirmlesers. Sie demonstrierte, dass 70% von Screenreader-Benutzern arbeiten an iOS Betriebssystem und nur 21% nutzen Android. Daraus könnte man schließen, dass iOS sich am meisten Gedanken um Barrierefreiheit macht und deren Produkte und Software zugänglich gestalten. Dabei sieht das Set von Barrierefreiheit Funktionen an beiden Betriebssystemen ähnlich aus:

iOS Funktionen für die Barrierefreiheit:

• Voice-Over
• Diktiergerät
• Zoom
• Farbschema umstellen / Graustufen
• Schaltersteuerung

Android Funktionen für die Barrierefreiheit:

• TalkBack (Bildschirmleser)
• Schaltersteuerung
• Unterstützung der Braille-Geräte
• hoher Kontrast
• Vergrößerung

Der Unterschied dabei liegt darin, dass iOS Applikationen sind so ausgelegt, dass all diese Funktionen auch einsetzbar und sinnvoll sind. Bei Android gibt es keine Barrierefreiheit-Richtlinien und obwohl diese Funktionen prinzipiell zur Verfügung stehen, können diese über viele Barrieren bei den mobilen Applikationen nicht ‚drüberhupfen‘. Einfach gesagt, die Funktionen nutzen nichts, wenn deren Einsatz bei der Entwicklung von Apps nicht berücksichtigt bzw. ermöglicht wird.

Häufige Barrieren im Web

Entwickler sollen besser über die möglichen Barrieren im Web informiert werden. Nur dann können sie ihren Beitrag für die Accessibility leisten. Das sind die typischen Barriere:

• gesperrtes Zoom
• verhindertes Scrollen
• der Text ist zu klein
• visuelle Unordnung und Überlastung
• mehrdeutige Icons ohne begleitenden Text
• Berührung- und Wischen-lästige Designs (Können Bildschirmleser-User das benutzen?)
• versteckte Inhalte, die zu eine Falle werden

Die letzte Barriere ist ein extrem häufiges Problem, die man auch als eine Navigationsfalle bezeichnen kann.

Navigationsfalle: Popup, Overlay und versteckte Inhalte

Oft werden Popup-Fenster angewandt, welche ein standart Benutzer leicht bedienen bzw. schliessen kann. Für Screenreader-Benutzer kann so ein Overlay-Fenster zum Verhängnis werden. Der Grund dafür ist, dass die Inhalte, welche in der Hintergrund sind bzw. ausgeblendet sind, nicht wirklich versteckt sind. Das bedeutet, dass die Tastatur-Navigation durch das Popup-Fenster irgendwann das Fenster verlässt und durch die Inhalte vom Hintergrund navigiert. Da das Fenster aber nicht weggeklickt wurde und immer noch oben schwebt, ist keine weitere Interaktion im Hintergrund möglich. Der Screenreader kann dies aber nicht sehen und sitzt quasi in der Falle. Da der Grund dafür für ihn nicht nachvollziehbar ist, muss er gezwungenermaßen die Seite verlassen.

Auf dem Weg zur mobilen Barrierefreiheit

Es sind viele Kleinigkeiten, die man berücksichtigen soll, wenn man eine Accessibility gewährleisten will. Inzwischen gibt es viele Richtlinien für Entwickler, die helfen eine Standartisierung in Bezug auf Barrierefreiheit im mobilen Web zu erreichen. Der Weg dorthin ist dennoch lang, deswegen findest du hier die DOs und DONTs von Marcy Sutton’s Konferenzvortrag vor. Das sind konkrete Dinge, die du bei der Entwicklung berücksichtigen kannst.

DOs für Barrierefreiheit

• Zoom von der Seite und dem Text soll zu jederzeit ermöglichen. So können Menschen, die nicht so gut sehen können, die Applikation bedienen bzw. den Content konsumieren.
• Die Struktur und Layout von der Seite klar darstellen. Die kognitive Belastung durch visuelle und strukturelle Elemente soll bewusst reguliert werden. Sucht eine goldene Mitte zwischen zu leere Seite und eine mit Inhalten vollgestopfte Seite.
• Grafische Icons (als Buttons oder Links) zu jederzeit mit dem beschreibenden Text begleiten.
• Bei der Entwicklung eine Applikation, die sehr stark mit den Gesten wie wischen bedient werden soll,  Geste-Alternativen für Screenreader-Usern überlegen und zur Verfügung stellen.
• Im HTML jedes Element mit dem dafür vorgesehenen Semantik einsetzten. <button> für die Buttons usw. Nur so können Screenreader die Applikation verstehen und damit interagieren. <div> Elemente können sie nicht wahrnehmen.
• Touch Targets oder Berührungsflächen ausreichend Platz geben, damit man es auch leicht bedienen bzw. treffen kann.
• Versteckte Inhalte unerreichbar für Screenreader machen.

DONTs für Barrierefreiheit

• Scroll Hijacking immer vermieden. Dabei geht es um diverse Spielereien rund um Scroll Bar, welche die User Experience beeinträchtigen und eher schlecht von Benutzern angenommen werden.

Zusammenfassung

Als Entwickler können wir nicht wissen mit welchen Geräten und Funktionen Benutzer unserer Software einsetzten werden. Man kann nur loslassen und so entwickeln, dass unabhängig von all diesen Benutzer-spezifischen Faktoren der Inhalt der Applikation gut und leicht zugänglich ist. Auch wenn es nicht so schön aussieht, wie man es gern hätte.
Gerne bist du eingeladen dich in dieses Thema zu vertiefen. Hier findest du die empfohlenen BBC Richtlinien für mobile Barrierefreiheit und den Link zur Marcy Sutton’s Konferenzvortrag: ‚How to Win at Mobile Accessibility‘.