So haben wir getestet und ausgewertet

Die Datenerhebung und -auswertung der «Schweizer Accessibility Studie 2023 – Mobile Apps» wurde mit der nachfolgend beschriebenen Methodik durchgeführt.

Prüfobjekte

Getestet wurden 46 Apps nach den Prüfkriterien der WCAG 2.1, Konformitätsstufe AA. Dieser Standard wurde ursprünglich für Webseiten konzipiert. Im Rahmen der Entwicklung der App-Zertifizierung der Stiftung «Zugang für alle» (Link öffnet in einem neuen Tab) wurden die Testmethoden an die Besonderheiten von mobilen Apps angepasst. Dies beinhaltet unter anderem, dass einzelne Testkriterien anders interpretiert werden oder Kriterien wie die Überprüfung des Quellcodes keine Anwendung finden.

Als Prüfobjekte wurden in der Schweiz beliebte Mobile Apps ausgewählt, die zur Bewältigung des privaten oder beruflichen Alltags relevant sind. Eine detaillierte Dokumentation des Auswahlverfahrens findet sich im Bereich «So haben wir die Apps ausgewählt».

Die getesteten Apps wurden aus den offiziellen App Stores von iOS und Android bezogen. Eine Reihe der getesteten Apps erforderte zur vollständigen Nutzung ein Anwendungskonto. Hierbei ist zu unterscheiden zwischen einfachen Anwendungskonten, bei denen die Angaben einer E-Mail und eines Passworts ausreicht und solchen Konten, die eine Identifizierung respektive Verifizierung der nutzenden Person erfordern. Für Apps, welche verifizierte Konten erfordern, wurde im Vorfeld abgeklärt, ob die Testenden bereits einen solchen Zugang hatten. Falls diese nicht über ein persönliches Konto verfügten, wurden die Herausgeber um die Möglichkeit eines Testzugangs gebeten. Freundlicherweise wurden uns für die «ePost App», «MySwisscom», und «Well» entsprechende Zugänge ermöglicht. Im Falle der Apps «ePost App» und «Well» wurden uns von den Herausgebern noch unveröffentlichte App-Versionen zur Verfügung gestellt, damit wir gefahrlos die gesamte App testen konnten.

Die Tests wurden im Zeitraum von Juni bis August 2023 durchgeführt.

Prüfkriterien

Kriterienbasiert (quantitativ)

Die Erfolgskriterien der WCAG 2.1 auf Konformitätsstufe AA setzen sich zusammen aus 50 Erfolgskriterien, wovon 30 der Konformitätsstufe A und 20 der Konformitätsstufe AA zugeordnet sind. Jedes Erfolgskriterium kann eine oder mehrere Anforderungen umfassen. Insgesamt ergeben sich so 58 Anforderungen. Nicht alle Anforderungen sind jedoch auf Mobile Apps übertragbar. Deshalb haben wir mit einem Set von 46 Anforderungen gearbeitet.

Im ganzen Testsetting stand einzig die Accessibility im Fokus. Das heisst, unsere Fachpersonen für Accessibility bewerteten nicht die Qualität der Apps bezüglich Nutzungsumfang, technischen Merkmalen oder Nutzungserfahrung (Usability respektive User Experience). Der Fokus aller Beurteilungen im Rahmen der Accessibility-Studie lag immer ausschliesslich auf der Prüfung der Barrierefreiheit.

Szenarienbasiert (qualitativ)

Die Tests wurden entlang definierter Szenarien durchgeführt. Je nach Komplexität der App waren es drei bis sechs Szenarien. Ein gemeinsames Szenario über alle Apps war die Nutzung und Überprüfung der Einstellungsseite. Ähnliche Apps in bestimmten Kategorien wie zum Beispiel Chat- oder Einkaufs-Apps wurden für eine bessere Vergleichbarkeit mit (möglichst) identischen Szenarien getestet. Die Szenarien bilden typische Nutzungsfälle der entsprechenden App ab. Beispielsweise umfassten die Testszenarien für die Einkaufs-Apps von «Coop», «Lidl» und «Migros» eine Filialsuche, das Durchstöbern des Angebots, das Studieren von Produktdetails, die Nutzung und Verwaltung der Einkaufsliste und die Kontrolle des Einkaufszettels.

Vorgehen in der Testphase

Testumgebung

Auf eine standardisierte Testumgebung wurde verzichtet, weil wir mit der Studie möglichst die Realität einer App-Nutzung testen wollten und nicht das Verhalten unter «Laborbedingungen». Jedoch alleine durch den Umstand, dass alle Apps durchgehend auf der iOS-Plattform getestet wurden, sorgte für eine gewisse Konstanz der Testumgebung. Um die Situation auf Android-Smartphones ebenfalls zu berücksichtigen, wurden fünf Apps zusätzlich unter Android getestet (Details zur Auswahl finden sich im Bereich «So haben wir die Apps ausgewählt»).

Testvorgehen

Jede App wurde von drei unterschiedlichen Fachpersonen für Accessibility beurteilt: Eine sehende Person testete die Anforderungen vollständig. Eine blinde Person testete alle Anforderungen, die ohne Augenlicht überprüfbar sind. Die dritte Person übernahm den Teil der Anforderungen, die zur Überprüfung Augenlicht erfordern (beispielsweise die Beurteilung von Kontrastanforderungen, Zoombarkeit von Textgrössen oder die Sichtbarkeit des Tastaturfokus). Jede Anforderung bekam auf diesem Weg zwei unabhängige Beurteilungen. Die szenarienbasierten Tests wurden von allen drei Testenden vollständig durchgeführt.

Kriterienbasierte Tests

Die kriterienbasierten Tests erfolgten anhand des definierten Sets von 46 Anforderungen. Die Accessibility-Fachpersonen gaben für jede der geprüften Anforderung unabhängig voneinander eine Erfüllungseinschätzung ab. Dabei wurde eine Skala von 0 (nicht erfüllt) bis 10 (vollständig erfüllt) verwendet. Wenn die Differenz zwischen zwei Beurteilungen einer Anforderung mehr als 3 Skalenpunkte betrug, analysierten die zwei involvierten Testenden im Rahmen eines Abgleichs ihre Beurteilungen. Hatte eine Person eine Beobachtung gemacht, die der anderen Person entgangen war, glich die andere Person ihre Beurteilung entsprechend an. Wenn spezifisch zu prüfende Anforderungen wie z.B. Multimediainhalte oder Formulare in den definierten Szenarien nicht anzutreffen waren, wurden Teile der App untersucht, die solche Elemente enthielten.

Szenarienbasierte Tests

In den szenarienbasierten Tests wurde die Durchführbarkeit von typischen Nutzungsszenarien einer App oder App-Gruppen wie z.B. Kommunikations-Apps beurteilt. Hierbei stand nicht das subjektive Nutzungserlebnis der Testenden im Vordergrund, sondern eine Beurteilung nach den Gesichtspunkten einer barrierefreien Nutzung. Dementsprechend wurden auch bei den szenarienbasierten Tests von allen Testenden assistierende Technologien wie Screenreader und alternative Eingabemethoden wie eine Tastatur eingesetzt und verschiedene Konfigurationen wie zum Beispiel Textvergrösserung, Quer-/Hochformat und Farbumkehr genutzt. Die Ergebnisse wurden für jedes Szenario festgehalten und benotet. Es stand hierfür eine vereinfachte Skala mit folgenden drei Noten zur Verfügung:

  • Note 6: Das Szenario kann barrierefrei durchgeführt und abgeschlossen werden.
  • Note 4: Barrieren behindern die Durchführung. Ein Abschluss des Szenarios ist möglich.
  • Note 1: Barrieren verhindern die Durchführung. Ein Abschluss des Szenarios ist nicht möglich.

Nicht beurteilbare Anforderungen

Grundsätzlich wurden nur diejenigen Anforderungen beurteilt, die in der entsprechenden App überhaupt erfüllbar sind. So bringt zum Beispiel nicht jede App Videoinhalte mit und nicht jede App verwendet tabellarische Daten oder bietet Dokumente im PDF-Format an. Konnte eine solche Anforderung nicht beurteilt werden, wurde dies entsprechend im Testprotokoll vermerkt.

Berechnung und Darstellung der Resultate

In diesem Kapitel werden die Berechnungen der Resultate dokumentiert.

Einleitung: Accessibility-Profil als zentrales Instrument

Das Accessibility-Profil ist ein zentrales Instrument zur Beurteilung der Barrierefreiheit einer App. Durch Gruppierung der 46 Erfolgskriterien in zwölf thematische Kategorien ergibt sich ein differenziertes Bild über die spezifischen Stärken und Schwächen einer geprüften App. Das Accessibility-Profil umfasst folgende zwölf thematische Kategorien:

  • Mobile Bedienbarkeit: Bedienbarkeit und vollständige Anzeige von Inhalten im Hoch- und Querformat, Zeigergesten und Funktionalitäten durch Gerätebewegung sind mit konventionellen Eingabemethoden nutzbar.
  • Tastaturbedienbarkeit: Interaktive Elemente sind nur mit Tastatur bedienbar und werden bei Fokus hervorgehoben.
  • Sprachsteuerung: Bedienelemente verfügen über eine zugängliche, exakt der visuellen Beschriftung entsprechenden Bezeichnung.
  • Kompatibilität mit Benutzeragenten: Benutzeragenten und assistive Technologien werden über Zustandsänderungen der Benutzerschnittstelle sowie Statusmeldungen informiert.
  • Hilfestellung bei Interaktionen: Interaktion mit Formularen, Zeigereingaben können abgebrochen oder rückgängig gemacht werden.
  • Konsistenz/Vorhersehbarkeit: Gleichbleibende Navigation, Kontext bleibt bei Fokus oder Eingabe bestehen.
  • Semantische Struktur: Inhalte sind mit strukturellen Elementen wie Überschriften, Listen und Labels ausgezeichnet, die den Bedeutungszusammenhang abbilden.
  • Verständlichkeit: Überschriften, Formularbeschriftungen und Linktexte sind verständlich, es wird eine korrekte Sprachdeklaration verwendet.
  • Flexibilität der Anzeige: Die Präsentation der Inhalte kann an die Anforderungen der Nutzenden angepasst werden: Textgrösse, Kontrolle über animierte Elemente und Medien.
  • Kontrast und sensorische Eigenschaften: Ausreichend Kontraste, keine Ausdrücke wie «im Bild rechts» oder «den roten Schalter klicken», Information wird nicht ausschliesslich durch Farbe vermittelt.
  • Nicht-Text-Inhalte (Grafiken): Informative grafische Elemente verfügen über sinnvolle Alternativtexte.
  • Multimedia/2-Sinne-Prinzip (Audio/Video): Multimediainhalte sind für mindestens einen alternativen Sinneskanal aufbereitet.

Übersicht

Erhobene Kennwerte

Während der Tests wurden folgende Kennwerte erhoben:

KennwertQuelleZweck
ErfüllungsgradKriterienbasierte TestsErreichter Erfüllungsgrad für jeden der untersuchten 46 WCAG-Anforderungen (sofern anwendbar)
DurchführbarkeitSzenarienbasierte TestsInformation über die barrierefreie Durchführbarkeit eines Szenarios

In den folgenden Kapiteln werden die Berechnungen der aus diesen Kennwerten gewonnenen Ergebnisse aufgezeigt.

Berechnete Resultate

Anhand der erhobenen Kennwerte wurde eine Reihe von Resultaten berechnet:

  • Detailauswertungen einer App
  • Durchführbarkeit von Nutzungsszenarien
  • Zugänglichkeit nach Einschränkungsart (experimentell)
  • Accessibility-Profil mit zwölf Einzelaspekten
  • Gesamturteil der Barrierefreiheit einer App
  • Positionierung einer App im Gesamtfeld

Detailauswertungen einer App

Accessibility-Profil

Berechnung
SchrittWertBerechnung
1.1Erfüllungsgrad einer AnforderungDurchschnittswert der Erfüllungseinschätzungen je Anforderung
1.2Erfüllungsgrad eines Aspekts des Accessibility-ProfilsGesamtsumme der Anforderungs-Durchschnittswerte, die demselben Aspekt zugeordnet sind
1.3Normalisierter Erfüllungsgrad eines Aspekts des Accessibility-ProfilsNormalisierung der GesamtsummeErklärung: Nicht jeder Aspekt des Accessibility-Profils setzt sich aus der gleichen Anzahl Anforderungen zusammen. Damit die verschiedenen Aspekte miteinander verglichen werden können, muss der Erfüllungsgrad jedes Aspekts normalisiert werden.
1.4Erfüllungsgrad eines Einzelaspekts im Accessibility-ProfilDer normalisierte Erfüllungsgrad eines Einzelaspekts (Schritt 1.3) wird in eine Skala von 1 bis 5 umgewandelt und danach auf das Vielfache von 0.5 gerundet.Eine Aufrundung fand dann statt, wenn der Rest der Division «Zahl durch Vielfaches» grösser oder gleich der «Hälfte von Vielfaches» ist.
Darstellung
Beispiel-Darstellung des Erfüllungsgrades eines Aspekts im Acessibility-Profil

Die Darstellung der maximal fünf erreichbaren Punkte erfolgt auf einer Skala von fünf Kreisen. Ein ganzer Wert wird als ausgefüllter Kreis dargestellt; ein halber Wert mit einem halb ausgefüllten Kreis. So ergibt sich für jeden Aspekt eine Art Füllstandsmesser: Je mehr Kreise ausgefüllt sind, desto mehr Anforderungen an die Barrierefreiheit konnten erfüllt werden.

Die Bedeutung der Werte entspricht folgender Skala:

WertebereichBedeutung
4.5 bis 5 PunkteGute Zugänglichkeit
4 PunkteBedingte Zugänglichkeit
3 bis 3.5 PunkteUngenügende Zugänglichkeit
0 bis 2.5 PunkteSchlechte Zugänglichkeit

Benotung der Durchführbarkeit

Berechnung
SchrittWertBerechnung
2.1Notendurchschnitt eines SzenariosDurchschnittswert der von den Fachpersonen veranschlagten Note
2.2Gesamtnote aller Szenarien einer AppBerechnung des Gesamtdurchschnitts anhand der Notendurchschnitte im Schritt 2.1
Darstellung

Die Durchführbarkeit der Nutzungsszenarien einer App wird als Gesamtnote dargestellt. Die Note «6» ist die Höchstnote, die Note «1» die tiefste Note.

Zugänglichkeit nach Einschränkungsart (experimentell)

Für ein klareres Verständnis, welche Personengruppen eine App in welchem Umfang nutzen können, haben wir eine experimentelle Darstellung der Zugänglichkeit nach Einschränkungsart eingeführt. Diese umfasst die vier Dimensionen «Motorik», «Augenlicht», «Gehör» und «Kognition».

Zur Bildung der Kategorien haben wir die 46 von uns untersuchten WCAG-Anforderungen den jeweiligen Dimensionen der Einschränkungsart zugeordnet. So wurde beispielsweise die Anforderung «Der Tastaturfokus ist genügend sichtbar» sowohl der Gruppe «Augenlicht» wie auch «Motorik» zugeordnet, weil beide Nutzungsgruppen auf einen gut sichtbaren Fokus angewiesen sind. Dieses Beispiel verdeutlicht auch, dass die Einschränkungsart «Augenlicht» alle Menschen mit Einschränkungen im Bereich des Augenlichts umfasst und nicht etwa ausschliesslich blinde Menschen.

Berechnung

Die Berechnung der Zugänglichkeit nach Einschränkungsart funktioniert identisch wie für die Werte-Berechnung der Einzelaspekte des Accessibility-Profils. Der einzige Unterschied besteht in der andersartigen Gruppierung der 46 geprüften Anforderungen.

SchrittWertBerechnung
3.1Erfüllungsgrad einer AnforderungDurchschnittswert der Erfüllungseinschätzungen je Anforderung
3.2Erfüllungsgrad einer EinschränkungsartGesamtsumme der Anforderungs-Durchschnittswerte, die derselben Einschränkungsart zugeordnet sind
3.3Normalisierter Erfüllungsgrad einer EinschränkungsartNormalisierung der GesamtsummeErklärung: Nicht jeder Aspekt des Accessibility-Profils setzt sich aus der gleichen Anzahl Anforderungen zusammen. Damit die verschiedenen Aspekte miteinander verglichen werden können, muss der Erfüllungsgrad jedes Aspekts normalisiert werden.
Darstellung

Die Darstellung nach Einschränkungsart erfolgt in einem Radardiagramm. Die Form ist kreisförmig und sie hat Achsen wie die Speichen eines Rades. Als Skala wurde ein Wert von 0 Prozent bis 100 Prozent gewählt. Dieser Wert steht für den Erfüllungsgrad der Barrierefreiheit. Jeder Aspekt ist einem Viertelkreis zugeordnet und die Werte werden vom Zentrum des Kreises bis an die Peripherie abgebildet. Der tiefste Wert befindet sich im Zentrum, der höchste Wert auf dem äussersten Kreis. Wenn die vier Wertepunkte miteinander verbunden werden, ergibt sich eine Viereckfläche, die für jede App typisch ist und die Abdeckung der Einschränkungsarten visuell greifbar macht: Je grösser die Vierecksfläche, desto umfassender ist eine Erfüllung der Barrierefreiheit bei allen Einschränkungsarten gegeben. Je regelmässiger die Vierecksfläche ist, d.h. einem Quadrat gleicht, desto ausgeglichener werden Personengruppen berücksichtigt.

Eine Bemerkung zu den Werten in der Dimension «Gehör»: Die meisten relevanten Kriterien im Bereich «Gehör» beziehen sich auf Multimedia-Inhalte. Die meisten untersuchten Apps enthalten jedoch keine solchen Inhalte. Deshalb war für eine Mehrzahl der Apps im Bereich «Gehör» einzig die Anforderung «Inhalte werden nicht nur mit sensorischen Eigenschaften vermittelt» anwendbar. Im Erfolgskriterium 1.3.3 der WCAG 2.1 wird Ton explizit als sensorisches Merkmal einbezogen. Ein Anwendungsfall könnte zum Beispiel sein, wenn in einer App eine Benachrichtigung oder eine Rückmeldung rein akustisch erfolgt. Die Umsetzung dieses Kriteriums wurde meist erfüllt. Aus diesem Grund zeigen die meisten Apps 100 Prozent Erfüllungsgrad.

Gesamturteil der Barrierefreiheit einer App

Die Berechnung der Gesamtbeurteilung einer App basiert auf folgenden zwei Kennzahlen:

  • Gesamtwert der kriterienbasierten Beurteilung
  • Gesamtwert der szenarienbasierten Beurteilung

Methodische Überlegungen

Die Verletzung einer einzigen WCAG-Anforderung kann in der Praxis für Betroffene bedeuten, dass die gesamte App oder Teile davon nicht mehr nutzbar sind (zum Beispiel, wenn keine alternative Eingabemethode wie eine Tastatur oder ein Controller verwendet werden kann oder wenn ein Smartphone im Querformat in einer Halterung fixiert ist, aber die App nicht im Querformat ausgeführt werden kann). Mit der Aufsummierung von Einzelkriterien zu einem Gesamtwert werden solch gravierende Einzelverletzungen im Gesamtergebnis jedoch unsichtbar. So können Apps trotz punktuell schweren Verletzungen der Barrierefreiheit einen soliden Gesamtwert erreichen, obwohl sie für bestimmte Personengruppen in der Praxis kaum nutzbar sind. Eine rein kriterienbasierte Beurteilung kann also eine Zugänglichkeit suggerieren, die in der Praxis so nicht gegeben ist. Um solchen Verzerrungen entgegenzuwirken, haben wir die szenarienbasierte Beurteilung als Korrektiv in das Gesamturteil einbezogen.

Berechnung

Die Berechnungen wurden auf einer normalisierten Skale im Wertebereich von 0 bis 1 durchgeführt. In der nachfolgenden Tabelle werden die einzelnen Schritte zur Berechnung der Gesamtbeurteilung aufgezeigt.

SchrittWertBerechnung
4Gesamtwert der kriterienbasierten BeurteilungDurchschnittswert der normalisierten Erfüllungsgrade (Schritt 1.3) aller zwölf Aspekte des Accessibility-Profils
5Gesamtwert der szenarienbasierten BeurteilungUmrechnung der Gesamtnote in eine Skala von 0 bis 1, damit die Notenskala im selben Format ist wie die normalisierten Werte des Accessibility-Profils (vgl. Schritt 1.3).
6Gesamtbeurteilung einer AppDer Gesamtwert aus der kriterienbasierten Beurteilung (Schritt 4) und der Gesamtwert der szenarienbasierten Beurteilung (Schritt 5) werden zu je 50% zusammengezählt.

Um sicherzustellen, dass die szenarienbasierte Beurteilung ausschliesslich als Korrektiv wirkt, durfte im Rechnungsschritt Nr. 6 die szenarienbasierte Beurteilung maximal so viel zählen wie die kritierenbasierte Beurteilung. Das heisst, wenn der Anteil für die szenarienbasierte Beurteilung beispielsweise 0.47 Punkte betrug, der Anteil für die kriterienbasierte Beurteilung mit 0.41 Punkten aber tiefer war, wurde der Wert für die szenarienbasierte Beurteilung auf den Wert von 0.41 Punkten beschnitten. Mit diesem Vorgehen wird die methodisch ungewollte Aufwertung des Gesamturteils durch die szenarienbasierte Beurteilung verhindert.

Darstellung

Beispiel-Darstellung einer Gesamtbeurteilung

Die Gesamtbeurteilung zeigt in einer Art Gradmesser auf neun horizontal angeordneten Feldern den aktuellen Stand der Zugänglichkeit einer App an. Für die Prozentskala von zehn bis neunzig Prozent wird der berechnete Wert für die Gesamtbeurteilung direkt abgebildet. Die Interpretation der Werte ist identisch wie für das Accessibility-Profil. Die Wertebereiche und Bedeutungen sind wie folgt:

WertebereichBedeutung
ab 90%Gute Zugänglichkeit
ab 80%Bedingte Zugänglichkeit
60-79%Ungenügende Zugänglichkeit
0 bis 59%Schlechte Zugänglichkeit

Positionierung im Gesamtfeld

Die Positionierung der untersuchten Apps im Gesamtfeld ermöglicht eine Einordnung, wie die Apps mit Bezug auf die Barrierefreiheit zueinander stehen. Auf eine explizite Rangfolge wurde verzichtet.

Berechnung

SchrittWertBerechnung
7Erfüllungsgrad im GesamturteilDie Gesamtbeurteilung einer App (Schritt 6) wurde in eine Skala von 1 bis 5 umgewandelt und danach auf das Vielfache von 0.5 gerundet.Eine Aufrundung fand dann statt, wenn der Rest der Division «Zahl durch Vielfaches» grösser oder gleich der «Hälfte von Vielfaches» ist.

Darstellung

Das Gesamtfeld der Apps wird tabellarisch dargestellt: Die oberste Position nimmt die App mit dem höchsten Gesamturteil ein, die unterste Position ist von der App mit dem tiefsten Gesamturteil belegt. Das Gesamturteil jeder App wird in der zweiten Spalte mit der vereinfachten Skala von fünf Kreisen dargestellt. Ein ganzer Wert wird als ausgefüllter Kreis abgebildet; ein halber Wert mit einem halb ausgefüllten Kreis. So ergibt sich für jeden Aspekt eine Art Füllstandsmesser: Je mehr Kreise ausgefüllt sind, desto mehr Anforderungen an die Barrierefreiheit konnten von dieser App erfüllt werden.

Externe Validierung der Resultate

Im Rahmen einer Evaluationsstudie wurden unsere berechneten Resultate extern evaluiert. Das Institut für Datenanalyse und Prozessdesign der Zürcher Hochschule für Angewandte Wissenschaften (ZHAW) überprüfte die beschriebenen Methoden und replizierte die Ergebnisse unabhängig von unseren eigenen Berechnungen. Die Parallelberechnung durch die ZHAW ergab dieselben Ergebnisse wie unsere interne Berechnung.