Barrierefreie App-Entwicklung Der Sinn barrierefreier Progressive Web Apps

Öffentliche Stellen des Bundes sind seit September 2016 gesetzlich dazu verpflichtet, barrierefreie Apps einzusetzen. Die Programmiersprachen Java und Swift sind grundsätzlich dafür geeignet. Dieser Artikel soll aber darlegen, warum es Sinn ergibt, barrierefreie Apps als progressive Web Apps zu entwickeln.

Warum ist barrierefreie App-Entwicklung wichtig?

Bereits seit dem 1. Mai 2002 gibt es ein Behindertengleichstellungsgesetz, kurz BGG. Dieses Gesetz wurde im Jahr 2016 überarbeitet und im September 2016 neu verabschiedet. Seit September 2016 sind öffentliche Stellen des Bundes nach § 12a Barrierefreie Informationstechnik Absatz 1 zur Barrierefreiheit bei Apps verpflichtet.

Richtlinien zur barrierefreien App-Entwicklung finden sich auch bei den wichtigen kommerziellen Betriebssystem-Anbietern Google, Apple und Microsoft. Bei der Überlegung, wie viele Menschen von barrierefreier App-Entwicklung profitieren, sind es nicht nur die 7,8 Millionen schwerbehinderter Menschen in Deutschland. Von den 18,3 Millionen Senioren können ebenfalls einige davon profitieren, wenn Apps barrierefrei entwickelt werden.

Native Apps vs. Progressive Web Apps

Zunächst einmal wollen wir aber einen allgemeinen Vergleich zwischen native Apps und progressive Web Apps anstellen. Da wären zunächst einmal die gängigsten Programmiersprachen und Plattformen: Native Apps werden mit Java, Kotlin, Swift, Objective C, React Native, Flutter oder Xamarin entwickelt. Progressive Web Apps werden mit HTML, CSS und Javascript entwickelt.

Vorteile von Native Apps

Leistung und Geschwindigkeit: Native Apps werden speziell für das Betriebssystem des jeweiligen Geräts entwickelt. Da sie direkt auf die Hardware und Funktionen des Geräts zugreifen können, bieten sie in der Regel eine bessere Leistung und Geschwindigkeit im Vergleich zu progressive Web Apps.

Zugriff auf Gerätefunktionen: Wie erwähnt greifen native Apps direkt auf die Hardware- und Software-Funktionen des Geräts zu. Hierzu gehören Kamera, Mikrofon, GPS, Bluetooth und mehr. Dies ermöglicht es Entwicklern, Funktionen zu erstellen, die tief in das Betriebssystem verankert sind.

Bessere Integration mit dem Betriebssystem: Da native Apps speziell für das jeweilige Betriebssystem entwickelt werden, können sie nahtlos in die Benutzeroberfläche und das Design des Systems integriert werden. Dies führt zu einer konsistenten Benutzererfahrung.

Vorteile von progressive Web Apps

Plattformübergreifende Kompatibilität: Progressive Web Apps funktionieren auf verschiedenen Geräten und Betriebssystemen, darunter Desktops, Tablets und Smartphones. Dies ermöglicht eine breite Reichweite, ohne separate Versionen für jedes Betriebssystem entwickeln zu müssen.

Keine Installation erforderlich: Progressive Web Apps werden über den Webbrowser aufgerufen und erfordern keine Installation aus einem App Store. Benutzerinnen und Benutzer können einfach die URL der App aufrufen, um sie zu verwenden. Dies vereinfacht Zugang und Verbreitung.

Aktualisierungen ohne App Store: Entwickler können Progressive Web Apps einfach aktualisieren, indem sie Änderungen am Webserver vornehmen. User erhalten automatisch die neueste Version, ohne die App manuell aktualisieren zu müssen. Dies erleichtert die Wartung und ermöglicht schnelle Verbesserungen.

Suchmaschinenfreundlichkeit: Progressive Web Apps lassen sich indexieren und von Suchmaschinen durchsuchen. Dies verbessert die Sichtbarkeit in den Suchergebnissen und ermöglicht eine einfachere Auffindbarkeit für Benutzer. Um eine bestimmte App zu finden, müssen nicht drei App Stores (Windows, Android und iOS) durchsucht werden.

Kostenersparnis: Die Entwicklung einer einzigen Progressive Web App kann kosteneffizienter sein als die Entwicklung separater nativer Apps für verschiedene Plattformen. Dieser Punkt ist sehr wichtig. Eine progressive Web App kann in den Betriebssystemen Windows, Linux, MacOS, Android und IOS eingesetzt werden. Dies spart richtig viel Geld.

Körperliche Einschränkungen und ihre Barrieren beim Bedienen von Apps

Wer barrierefreie Apps entwickeln möchte oder muss, sollte sich bewusst machen, für welche Menschen mit Behinderungen bzw. körperlichen Einschränkungen das Bedienen von Apps hinderlich sein kann.

Blinde Menschen

Wenn ein Mensch blind ist, dann weiß er nicht, wie eine App-Oberfläche aufgebaut ist. Blinde oder stark fehlsichtige Menschen nutzen einen Screenreader , eine Vorlesefunktion für blinde Menschen.

Da progressive Web Apps plattformunabhängig sind, gibt folgende Tabelle einen Überblick, welche Betriebssysteme welchen Screenreader bieten und wie dieser sich aktivieren lässt.

Der Screenreader liest die App-Oberfläche vor, wenn der App-Entwickler Texte hinterlegt hat.

Blinde Menschen können auch keine Computermaus bedienen, da sie den Mauszeiger nicht wahrnehmen. Damit eine progressive Web App auch auf einem Computer oder Laptop genutzt werden kann, muss sie deshalb zwangsläufig auch per Tastatur bedienbar sein.

Menschen mit einer Sehbehinderung

Für Menschen mit einer Sehbehinderung ist es problematisch, wenn nicht deutlich zu erkennen ist, welches Bedienelement den Eingabefokus hat. Bei Eingabefeldern wird der Textcursor als schmaler senkrechter Strich dargestellt. Dies ist für Menschen mit Sehbehinderung eine Barriere. Sehr klein geschriebener Text auf einer App-Oberfläche der nicht vergrößert, im Fachchinesisch „gezoomt“ werden kann, ist ebenfalls hinderlich für sehbehinderte Menschen.

Menschen mit Farbfehlsichtigkeit

Menschen mit einer Farbfehlsichtigkeit können nicht immer einer Farbe den richtigen Farbnamen zuordnen. Ebenso fehlt ihnen das Wissen, welche Farben zusammenpassen und welche Farben nicht. Eine Barriere bei App-Oberflächen besteht für diese Menschen, wenn zu wenig Farbkontrast zwischen Schriftfarbe und Hintergrundfarbe vorhanden ist.

Menschen mit motorischen Einschränkungen in den Händen

Kleine Schaltflächen sind für Menschen mit motorischen Einschränkungen der Hände eine Barriere. Sie können die Hand oder den Finger nicht an eine bestimmte Position auf dem Display bewegen oder den Mauszeiger auf dem Monitor richtig positionieren.

Richtlinie EN 301 549 –a Erklärung und Überblick

Die Web Content Accessibility Guidelines, bekannt als WCAG, wurden im Jahr 1999 vom W3C, sprich World Wide Web Consortium eingeführt und sind seitdem weltweit ein anerkannter Maßstab für die Barrierefreiheit von Webinhalten. Im Jahr 2018 erhielten sie ihre letzte Aktualisierung mit der Einführung der WCAG 2.1. Diese Richtlinie wird kontinuierlich weiterentwickelt.

Die aktuelle Ausführung der WCAG bildet die Grundlage für die europäische Norm EN 301 549. Doch die EN 301 549 geht über die reine Barrierefreiheit im Web hinaus. Sie erstreckt sich ebenso auf Barrieren in Bezug auf:

• Technische Geräte

• Dokumente außerhalb des Webkontextes

• Softwareanwendungen

• Dokumentation und unterstützende Dienstleistungen

Die EN 301 549 markiert einen bedeutenden Fortschritt, da sie die vielschichtige Thematik der digitalen Barrierefreiheit umfassend berücksichtigt. In dieser Hinsicht ist sie umfangreicher als die WCAG 2.1.

Ein Vergleich verdeutlicht den Unterschied zwischen der EN 301 549 und der WCAG 2.1: Wenn eine Website in Frankreich barrierefrei gestaltet werden soll, findet die EN 301 549 Anwendung. Hingegen greift in den USA die WCAG 2.1, wenn eine barrierefreie Webseite erstellt wird.

Die EN 301 549 ist primär auf die Barrierefreiheit von Web-Programmierung ausgerichtet. Daher ist es nicht empfehlenswert, native Apps, die in Java oder Swift entwickelt werden, nach den Vorgaben der EN 301 549 zu gestalten. Für Progressive Web Apps hingegen ist die Umsetzung nach EN 301 549 ideal, da sie mit HTML, CSS und Javascript realisiert werden.

Einzelne Kriterien der EN 301 549 umgesetzt

Im Folgenden zeigen wir Anleitungen, wie bestimmte Prüfungsschritte ganz praktisch umgesetzt werden.

Screenreader-Tauglichkeit

Screenreader-Tauglichkeit bedeutet, dass eine App-Oberfläche so entwickelt ist, dass sie von Screenreadern vorgelesen werden kann. Um einen Text festzulegen, der von Screenreadern vorgelesen wird, muss das Attribut aria-label verwendet und ihm einen Wert (= Text ) zugewiesen werden. Hier ein HTML-Beispiel:

Tastaturbedienbarkeit

Menschen mit motorisch eingeschränkten Händen und blinde Menschen können den Anspruch haben, eine progressive Web App auf einem Computer oder Laptop bedienen zu können. Sobald eine PWA auf einem Computer ausgeführt wird, ist es wichtig, dass sie komplett ohne Maus, also nur per Tastatur bedienbar ist . Deswegen sollten alle Bedienelemente per Tabulatortaste erreichbar sein.

Dem Button wird aus diesem Grund das Attribut „tabindex“ hinzugefügt. Wiederum ein HTML-Beispiel:

Nach dem Hinzufügen des Attributs ist der Button per Tabulatortaste erreichbar und somit ist die Grundvoraussetzung des Tastaturbedienbarkeit erfüllt. Zur Tastaturbedienbarkeit gehört aber auch, dass wichtige Funktionen per Tastenkürzel ausgeführt werden können.

Tastenkürzel lassen sich in Javascript wie folgt realisieren:

Der Javascript-Code sorgt dafür, dass der Schalter „Start“ durch Drücken des Buchstaben „S“ und der Schalter „Weiter“ mit durch drücken des Buchstabens „W“ ausgeführt werden kann.

Sichtbarkeit des Tastaturfokus für Ausführung auf Computer bzw. Laptop

Dieses Thema wird besonders relevant, wenn eine progressive Web App auf einem Desktop-Computer oder Laptop verwendet wird. Eine bedeutsame Herausforderung besteht für Menschen mit Sehbeeinträchtigungen darin, die aktuell fokussierten Bedienelemente zu identifizieren.

Oftmals wird in Eingabefeldern lediglich ein schmaler, vertikaler Strich als Textcursor dargestellt, was für Menschen mit Sehbeeinträchtigungen vor erhebliche Probleme stellt. Microsoft hat innerhalb des Betriebssystems Windows 11 eine Lösung für dieses Problem gefunden. Unter dem Pfad "Einstellungen" > "Barrierefreiheit" > "Textcursor" kann der Darstellungsstil des Textcursors individuell angepasst werden.

Bei progressive Web Apps kann der Entwickler gezielt dafür sorgen, dass aktive Bedienelemente eine gelbe Hintergrundfarbe erhalten. Diese visuelle Anpassung stellt sicher, dass Menschen mit Sehbeeinträchtigungen sofort erkennen können, welches Bedienelement gerade aktiv ist. Indem ein Bedienelement bei Aktivierung eine gelbe Hintergrundfarbe annimmt, wird die Sichtbarkeit für diese Zielgruppe erheblich verbessert.

Dies lässt sich mit CSS sehr einfach lösen:

Barrierefreier Farbkontrast

Für Menschen mit Farbfehlsichtigkeit ist es eine Barriere, wenn Texte mit einer dunklen Schriftfarbe auf dunklem Hintergrund oder eine helle Schriftfarbe auf hellem Hintergrund, dargestellt werden. Für diese Personengruppe ist es von besonderer Bedeutung, dass die Benutzeroberfläche einer App einen barrierefreien Farbkontrast zwischen der Schrift- und Hintergrundfarbe aufweist.

Um die Farbkontraste in einer App-Oberfläche auf Barrierefreiheit zu prüfen, bietet sich die kostenlose Software „Color Contrast Checker“ an. Bezüglich der Farbgestaltung von Oberflächen für Progressive Web Apps kann man generell inspirierende Ideen aus dem Material Design von Google schöpfen.

Motorische Einschränkungen

Motorische Einschränkungen betreffen „kleine Bewegungen“ (Feinmotorik) und „große Bewegungen“ (Grobmotorik). Menschen mit motorischen Einschränkungen der Hände können Probleme haben, Schaltflächen anzutippen, die zu klein sind. In Googles Richtlinien zur barrierefreien App-Entwicklung findet sich deshalb das Kriterium „Use large, simple controls“ .

Für Schaltflächen empfiehlt Google eine Mindestgröße von 48x48dp. Bei der Entwicklung von progressive Web Apps wird empfohlen, diese Mindestgröße umzusetzen, weil sie auch von dem Accessibility Scanner – so heißt das Überprüfungstool von Google – kontrolliert wird.

Menschen mit motorischen Einschränkungen können auf die Idee kommen, eine progressive Web App auf einem Tablet, iPad oder Computer zu bedienen – in der Hoffnung, dass dort die Schaltflächen größer dargestellt werden. Über Media-Queries, sie gehören zu Cascading Style Sheets, lässt sich dafür Sorge tragen, dass bei einer Displaygröße von 768x1024 die Schaltflächen größer dargestellt werden. Folgender CSS-Code zeigt, wie es geht:

Es wird die Displaygröße 1024 × 768 abgefragt, die bei Tablets und iPads oft anzutreffen sind. Die Abfrage funktioniert ebenfalls bei Bildschirmauflösungen von Computern und Laptops. Wenn die Displaygröße zutrifft, werden die HTML-Buttons, welche eine CSS-Klasse „Schalter“ besitzen, in der Höhe auf 6.0rem („root em“, eine Schriftgrößeneinheit) angepasst. Somit werden die Schaltflächen größer dargestellt, so dass sie sich einfacher mit dem Finger oder der Computermaus antippen lassen.

Übernahme von Einstellungen des Betriebssystems

Bestimmte Personengruppen mit körperlichen Einschränkungen nehmen grundsätzliche Anpassungen im Betriebssystem vor mit der Erwartung, dass die Apps diese Einstellungen übernehmen. Sehbehinderte Menschen passen im Betriebssystem die Schriftgröße an. Menschen mit einer Farbfehlsichtigkeit können im Betriebssystem den hohen Kontrast aktivieren.

PWAs sollen, wenn installiert, so plattformnah wie möglich aussehen und sich entsprechend verhalten. Deswegen ist dieses Thema etwas komplex. Für Menschen mit einer Sehbehinderung ist es wichtig, dass die App-Oberfläche vergrößert bzw. gezoomt werden kann. Wie dies auf unterschiedliche Betriebssysteme umgesetzt wird, zeigt folgende Tabelle:

Am Beispiel des Heranzoomens der App-Oberfläche zeigt sich, dass es keine einheitliche Regel gibt. Bei drei Betriebssystemen wird das Zoomen in der App-Oberfläche umgesetzt und bei zwei Betriebssystemen wird die Einstellung des Betriebssystems übernommen. Dieses Wissen ist wichtig, wenn App-Entwickler bestimmte Barrierefreiheitsfunktionen auf unterschiedlichen Betriebssystemen testen möchten.

Progressive Web Apps validieren auf Barrierefreiheit

Nachdem ein Developer eine barrierefreie App verwirklicht hat, gilt es zum Schluss herauszufinden, ob alles wie gewünscht funktioniert. Es gibt zwei grundsätzliche Methoden, progressive Web Apps auf Barrierefreiheit zu testen. Ein automatisierter Test oder ein Test von Hand aufgrund der Richtlinien EN 301 549.

Zunächst wird der automatisierte Test mit Googles Accessibility Scanner betrachtet. Der Accessibility Scanner ist für Smartphones und Tablets ab Android 6.0. Auf einem Tablet mit Android 12 ist er erfreulicherweise schon vorinstalliert. Mit dem Accessibility Scanner können native Apps und progressive Web Apps auf Barrierefreiheit überprüft werden.

Der Accessibility Scanner wird aktiviert in Einstellungen > Bedienungshilfen > Accessibility Scanner. Er benötigt die Berechtigung, dass er über anderen Apps eingeblendet werden darf. In den Einstellungen kann das Textkontrastverhältnis, das Bildkontrastverhältnis und die Größe des Berührungsbereichs angepasst werden.

Es gibt zwei Möglichkeiten, mit dem Accessibility Scanner eine progressive Web App auf Barrierefreiheit zu überprüfen:

Die „Aufnehmen“-Funktion macht jedes Mal ein Screenshot, wenn sich die App-Oberfläche ändert. Mit dieser Methode geht es sehr schnell eine komplette PWA auf Barrierefreiheit zu überprüfen.

Unter „Snapshot“ kann der App-Entwickler festlegen, wann er die App-Oberfläche auf Barrierefreiheit überprüfen möchte. Wenn der Accessibility Scanner Probleme hinsichtlich der Barrierefreiheit findet, dann sind die Fehlermeldung leicht verständlich formuliert. Der App-Entwickler weiß nun, was er tun muss, um einen Fehler zu beheben.

Eine weitere Möglichkeit, die Barrierefreiheit einer progressive Web App zu überprüfen, ist das kostenlose Tool Google Lighthouse . Google Lighthouse ist im Browser Google Chrome in den Entwickler-Tools zu finden. Folgende Schritte müssen umgesetzt werden. um eine Progressive Web App mit Google Lighthouse auf Barrierefreiheit zu überprüfen.

• Die Progressive Web App im Browser Google Chrome öffnen.

• Die Entwickler-Tools öffnen über das Menü „Weitere Tools“, „Entwickler-Tools“ oder mit der Tastenkombination Strg + Umschalt + I.

• Jetzt das Menü „>>“ aktivieren und dann das Menü „Lighthouse“ auswählen.

• Hier den Modus auf „Navigation (Default)“ lassen. bei „Gerät“ die Option „Mobil“ auswählen.

• Bei Categories „Bedienungshilfen“ auswählen.

• Jetzt mit aktivieren des Schalters „Analyze page load“ die Analyse auf Barrierefreiheit starten.

• Wenn die Analyse beendet ist, wird ein Kreis mit einer Bewertungszahl angezeigt, im besten Fall ist das die Zahl 100. Als erstes werden Prüfungskriterien angezeigt, die nicht bestanden wurden. Weiter unten werden Elemente angezeigt die manuell geprüft werden müssen. Noch weiter unten werden „Bestandene Prüfungen“ und ganz unten „Nicht zutreffend“ angezeigt.

In der Kategorie „ZUSÄTZLICHE ELEMENTE ZUR MANUELLEN ÜBERPRÜFUNG“ gibt es noch einen Link zur Webseite „How To Do an Accessibility Review“. Hier gibt Google-Mitarbeiter Rob Dodson Tipps in Form eines YouTube-Videos und Text, wie eine Überprüfung auf Barrierefreiheit durchgeführt werden kann.

Die dritte Möglichkeit besteht darin, die PWA nach den 98 Prüfungsschritten der EN 301 549 von Hand zu prüfen. Zusätzlich ist es hilfreich, die App von Menschen mit Behinderungen testen zu lassen. Ob eine progressive Web App für blinde Menschen bedienbar ist, weiß ein blinder Mensch am besten. Menschen mit Sehbehinderung sind Experten, wenn es darum geht zu überprüfen ob eine progressive Web App für Sehbehinderte bedienbar ist.

Fazit

Die Entwicklung barrierefreier progressiver Web Apps eröffnet die Möglichkeit, Apps zu gestalten, die über sämtliche Betriebssysteme hinweg denselben Maßstab hinsichtlich Barrierefreiheit setzen. Das impliziert, dass keine Nutzergruppen von der Anwendung auf einem spezifischen Betriebssystem ausgeschlossen werden.

* Markus Lemcke ist selbstständig im Bereich „Digitale Barrierefreiheit“ tätig. Er programmiert barrierefreie Webseiten sowie barrierefreie Software mit den Programmiersprachen Java, C#, und Python. Ebenso entwickelt er barrierefreie progressive Web Apps und ist Dozent an Hochschulen und Universitäten.

(ID:49661438)