Dieser Artikel ist entstanden in Zusammenarbeit mit folgenden Personen, die sich für ein Experten-Interview zur Verfügung gestellt haben: Diane Illi und Patrick Mukherjee (SwissSign), Marcel Belz (MeteoSwiss), Guido Riedweg und Christian Rudolf von Rohr (Well), Sandro Lüthi (Apfelschule).

Webseiten bestehen heutzutage universell aus HTML, JavaScript und CSS (bei Bedarf angereichert mit ARIA). Diese Sprachen sind standardisiert und es liegt in der Verantwortung der Browserhersteller, sie entsprechend den Spezifikationen umzusetzen. Dies gelingt mittlerweile deutlich besser als in der Vergangenheit. Die Webstandards werden fortlaufend weiterentwickelt und erweitert. Das professionelle Umfeld der Webentwicklung hat ein Gespür dafür entwickelt, welche Funktionalitäten und Elemente von allen Browsern jeweils unterstützt werden. Die deutlichen Fortschritte bei der Standardisierung sowie die Reduktion auf zwei zentrale Basisplattormen für Webbrowser – WebKit von Apple und Chromium von Google – haben in der Webentwicklung einiges vereinfacht. Im Kern sind wir im Bereich der Webentwickung nahe am Ideal, für ein einziges, einheitliches Ökosystem zu entwickeln: das «Web». Von dieser Vereinheitlichung profitieren auch assistierende Technologien wie etwa Screenreader, die auf validen und semantisch korrekten Code im Browser angewiesen sind.

In der Welt von Mobile Apps sieht die Situation eines einheitlichen Ökosystems anders aus: Hier existieren zwei komplett verschiedene Plattformen, nämlich iOS von Apple und Android von Google. Obwohl die beiden Plattformen nach aussen in vielen Belangen ähnlich aussehen mögen, so unterscheiden sie sich hinter den Kulissen doch grundlegend: Unterschiedliche Programmiersprachen kommen zum Einsatz, und obwohl die Paletten an Standard-Funktionalitäten und Elementen der Benutzerschnittstelle deutliche Gemeinsamkeiten haben, so haben sie dennoch spezifische Eigenheiten, um das Look and Feel hervorzubringen, welches für die jeweilige Plattform typisch ist. Um ein und dieselbe App auf Android und iOS anzubieten, müssen bei der App-Entwicklung zwei komplett unterschiedliche Ökosysteme verinnerlicht werden. Dieselbe App muss somit quasi zweifach produziert werden.

Diverse Programmier-Frameworks versprechen, diesen Doppel-Aufwand zu minimieren, indem sie die App-Versionen für iOS und Android aus einer einzigen Code-Quelle generieren. Dabei übersetzen einige Frameworks ihren Code in die nativen Programmiersprachen der jeweiligen Plattform; andere wiederum generieren HTML-Code, welcher von beiden Plattformen geladen werden kann (sogenannte Hybrid-Apps). Bei den bekanntesten Vertretern solcher Frameworks (z.B. Flutter und React Native) scheint man sich der Wichtigkeit von Barrierefreiheit bewusst zu sein: Die generierten Apps werden als barrierefrei angepriesen! Entweder weil sie in native Apps übersetzt werden, deren Barrierefreiheit das Betriebssystem garantiert; oder weil eine hybride App erstellt wird, welche sich an die traditionellen Vorgaben von HTML (und ARIA) hält. Flutter geht einen Mittelweg: Die Apps werden in nativen Code des Betriebssystems umgesetzt, jedoch nutzt das Framework nicht die Palette des Betriebssystems, sondern «malt» seine eigenen entwickelten Elemente, die laut Hersteller auch barrierefrei sein sollen. Trotz dieser Vereinfachungen liegt es weiterhin in der Verantwortung des Entwicklungsteams, über die entsprechenden Funktionalitäten Bescheid zu wissen und sie konsequent umzusetzen. Auch wenn der Übersetzungs-Algorithmus der genannten Frameworks sehr sauber sein sollte und theoretisch alles anbietet, was Expertinnen und Experten für Barrierefreiheit das Herz höherschlagen lässt, so nützt dies wenig, wenn der Bauplan fehlerhaft ist, aus welchem die Apps generiert werden. Hier gilt der alte Grundsatz: «Garbage in, garbage out».

Und selbst wenn auf höchstem Niveau designt und programmiert wird, so ist eine regelmässige Qualitätssicherung unumgänglich. Erst wenn der Screenreader gestartet ist, der systemweite Zoom aktiviert und eine physische Tastatur angeschlossen ist, zeigt sich, ob die Gesamtheit an Funktionalitäten und Elementen in einer App sinnvoll zusammenspielt. Diesbezüglich ist es angezeigt, Barrierefreiheit fest im Entwicklungsprozess zu verankern. Um geregelte Verantwortlichkeiten zu haben, sollten im Team Positionen mit klaren Aufträgen definiert werden. Damit ist sichergestellt, dass das Thema «Barrierefreiheit» während dem gesamten Entwicklungszyklus nicht aus dem Fokus gerät.

Über den Autor

Josua Muheim ist Accessibility Consultant bei der Stiftung «Zugang für alle». Josua Muheim ist gelernter Applikations-Entwickler. Er stiess 2014 zur Stiftung und lernte dort bis 2018 alles über Barrierefreiheit. Nach einigen Jahren des Reisens und des Freelancings kehrte er 2023 zurück zum Team und ist nun u.a. für die Ausbildung der Praktikant:innen zuständig.