Native Apps barrierefrei gestalten

Zusammenfassung

Über barrierefreie Websites und PDFs wird viel gesprochen. Native Apps spielen bei dem Thema bisher keine Schlüsselrolle. Das wird sich allerdings sehr schnell ändern. Schon das Barrierefreiheitsstärkungs-Gesetz verpflichtet private Unternehmen, die durch das Gesetz erfassten Apps barrierefrei zu gestalten. Der öffentliche Sektor und die Sozialversicherungen sind ebenfalls dazu verpflichtet, ihre Apps barrierefrei zu gestalten. Bislang gibt es in dem Bereich allerdings noch nicht so viele Apps. Das könnte sich allerdings durch die Digitalisierung ändern.

Es gibt Probleme, die man in der digitalen Barrierefreiheit praktisch immer findet: Fehlerhafte Kontraste, fehlende Bildbeschreibungen oder Placeholder-Texte statt korrekter Labels. Darauf möchte ich in diesem Beitrag nicht eingehen. Hier soll der Fokus auf Fehlern liegen, die für native Apps typisch sind.

Ausrichtung

Viele Apps verfehlen  die Anforderung 11.1.3.4 Orientation. Sie fordert, dass keine Einschränkung der App auf eine bestimmte Ausrichtung festgelegt werden soll.

Das erfordert in der Regel, dass ein spezifisches Layout für das Querformat angelegt wird. Es bringt wenig, wenn die App zwar ins Querformat wechselt, aber man links und rechts leere Flächen hat.

Der Hintergrund ist, dass manche Personen gezwungen sind, Apps in einer bestimmten Ausrichtung zu nutzen oder die Ausrichtung ihres Geräts nicht selbständig ändern können.

Pfad-basierte Gesten

Ebenfalls eine Anforderung, die selten erfüllt wird ist der Verzicht auf Pfad-basierte Gesten bzw. das Anbieten von Alternativen zu solchen Gesten. Stellen wir uns einen typischen Kartendienst vor. Wir vergrößern die Karte, indem wir zwei Finger spreizen und schwenken den Karten-Ausschnitt, indem wir die Karte mit dem Finger in die gewünschte Richtung ziehen.

Für Personen mit motorischen Einschränkungen funktioniert das nicht. Damit sie die Karte trotzdem nutzen können, werden UI-Elemente zum Zoomen und Schwenken der Karte angeboten. Ebenso sollten für alle Aktionen, die eine komplexe Geste oder Gesten mit mehreren Fingern erfordern UI-Elemente als Alternative angeboten werden.

Anpassung an Benutzer-Einstellungen

Die Anforderung 11.7 fordert, dass sich Apps an benutzerdefinierte Einstellungen anpassen. Auch wenn die konkrete Auslegung teils umstritten ist, gibt es doch zwei Anforderungen, die erfüllt sein sollten:

• Die im Betriebssystem eingestellte Schriftgröße sollte übernommen werden. Hier wird empfohlen, dass der höchste Grad an Schrift-Vergrößerung, der durch das Betriebssystem möglich ist, auch von der App übernommen wird. Oft wird die Schriftgröße nicht übernommen oder das Layout passt sich nicht entsprechend an.
• Wenn die nutzende Person das Farbschema über Betriebssystem-eigene Funktionen verändert, zum Beispiel die Farben invertiert, sollten trotzdem alle Texte und UI-Elemente der App immer noch identifizierbar sein. Oftmals sind einzelne UI-Komponenten nicht mehr erkennbar.

Bedienbarkeit per Tastatur

Auch Apps müssen vollständig per Tastatur bedienbar sein. Diese Anforderung wird selten erfüllt. Oft sind bestimmte UI-Elemente nicht per Tastatur erreich- oder bedienbar.

Auch ist die Position des Fokus oft nicht stark genug hervorgehoben oder erkennbar.

Selbstgebaute Komponenten

Auch selbstgebaute Komponenten sind oft nicht barrierefrei: Sie verfehlen die Anforderung 11.4.1.2 Name, Rolle, Wert. Die Elemente können von assistiven Technologien nicht korrekt identifiziert werden, man kann nicht mit ihnen interagieren, wenn der Screenreader aktiviert ist, ihr Status kann nicht ausgelesen oder verändert werden. Oft gibt die assistive Technologie gar keine Information zu dem Element oder nur „anklickbar“, was aber nicht sehr hilfreich ist.

Probleme kann es bei UI-Komponenten auch geben, wenn sie nicht in den Flow der assistiven Technologie integriert sind. Ein gutes Beispiel sind „Floating Action Buttons“. Sie werden etwa bei LinkedIn oder Twitter/X eingesetzt, um neu eintreffende Inhalte zu laden. Sie sind mit assistiven Technologien nicht erreichbar, weil sie dynamisch eingefügt werden und über dem Inhalt schweben.

Native Komponenten vs. Frameworks

Ähnlich wie beim Web wird auch bei Apps diskutiert, ob native Komponenten oder Frameworks die besten Möglichkeiten bieten. Bei digitaler Barrierefreiheit ist es aber eindeutig: Bei Websites bietet natives HTML die besten Chancen auf ein barrierefreies Produkt. Bei Apps sind es native Komponenten. Frameworks erfordern teils komplexe Nacharbeiten, welche das Zeit-Ersparnis komplett auffressen können, was man sich durch die Frameworks erhofft hat. Einen strukturierten Vergleich von Frameworks gibt es bei Appt.org.

Besonderheiten von Apps

Die WCAG sind, wie der Name schon sagt, besonders auf Websites und Web-Anwendungen ausgelegt. Einige Anforderungen können von Apps nicht erfüllt werden. Die Anforderungen von Apps werden speziell im Kapitel 11 Software der EN 301549 beschrieben.

Die Web Accessibility Initiative (WAI) hat eine Hilfe erstellt, wie sich die WCAG auf mobile Anwendungen anwenden lässt. Das Dokument ist aktuell noch ein Entwurf.

Appt.org ist aktuell die beste Quelle zum Thema App-Barrierefreiheit.