Barrierefreiheitstests

Barrierefreiheit in mobilen Apps bedeutet, dass Assistenzsysteme wie VoiceOver oder Talkback technischen Zugang zu allen Bedienelementen bekommen. Die Herausforderung beim Testen liegt darin, dass Einstellungen für verschiedene Behinderungsgruppen, also Blinde, Sehbehinderte und motorisch Eingeschränkte, sich gegenseitig behindern können. Eine einheitliche Testmatrix existiert bislang nicht.

Das Wichtigste in Kürze

• Assistenzsysteme für verschiedene Behinderungsarten schließen sich auf mobilen Geräten gegenseitig aus: Talkback hilft Blinden, verhindert aber gleichzeitig die sinnvolle Tastaturnutzung für motorisch Eingeschränkte.
• Eine Testmatrix für Barrierefreiheit auf mobilen Geräten muss hunderte Schalter-Kombinationen berücksichtigen, weshalb Teams genau dokumentieren müssen, welche Einstellungen aktiv waren und welche absichtlich deaktiviert blieben.
• Barrierefreie IT ist kein reines Technikproblem: Fehler entstehen bereits beim Designer und beim Dokumentenersteller, nicht erst in der Entwicklung.
• Der Curb-Cut-Effekt macht Barrierefreiheits-Features für alle nützlich: Hochkontrast-Modus und assistiver Touch helfen auch Menschen ohne Behinderung, etwa bei Sonnenlicht oder starker Ablenkung.
• PDF-Dokumente barrierefrei bereitzustellen ist technisch lösbar, scheitert in der Praxis aber an der schieren Menge bestehender Dokumente in Organisationen.

Barrierefreiheit auf Mobilgeräten ist ein anderes Spiel als am PC

Wer Software auf Barrierefreiheit testet, kennt das Setup am Desktop: Tastatur, Maus, vielleicht eine Kamera. Sobald die zu testende Anwendung aber auf einem iPad oder einem Android-Gerät läuft, ändern sich die Spielregeln grundlegend. Die assistiven Systeme sind hier bereits Teil des Betriebssystems.

Thorsten Schröder und Dirk Haas prüfen Anwendungen im Kontext der deutschen Rentenversicherung, unter anderem eine mobile Patientenakte auf dem iPad. Schon das Drehen des Geräts vom Hochformat ins Querformat veränderte das Verhalten der App. Einzelne Elemente wurden beim Wischen über VoiceOver nicht mehr fokussiert und damit für blinde Nutzer unerreichbar.

Auf dem Mobilgerät schaltest du Funktionen wie VoiceOver auf iOS oder Talkback auf Android ein, um dir Inhalte vorlesen zu lassen. Das Standardverhalten der App, Wischen und Tippen, soll dann plötzlich über eine Tastatur funktionieren. Genau an dieser Stelle beginnt die Anwendung, sich ungewohnt zu verhalten.

Warum sich Assistenzfunktionen gegenseitig blockieren

Das größte Problem beim Test mobiler Barrierefreiheit ist, dass sich Einstellungen für verschiedene Behinderungsarten gegenseitig ausschließen. Was einer Gruppe hilft, sperrt eine andere aus.

Ein konkretes Beispiel: Für motorisch eingeschränkte Menschen gibt es die Schaltersteuerung. Bei einem iPhone kann die Kamera auf Kopfbewegungen reagieren und so von Element zu Element navigieren, ausgelöst etwa durch ein Geräusch. Diese Steuerung lässt sich aber nicht gleichzeitig mit VoiceOver betreiben. Ein blinder Mensch hätte mit dieser Kombination keine Chance.

Für den Prüfbericht ist das ein Dilemma. Die Prüfkriterien stehen alle gleichberechtigt nebeneinander. Es gibt kein Kriterium, das festlegt, ob eine Anforderung nur für blinde oder nur für motorisch eingeschränkte Nutzer gilt. Der Satz ist immer derselbe. Die Einschränkung muss der Tester selbst dokumentieren.

Wer trägt die Barrierefreiheit, das Gerät oder die Software?

Mobilgeräte bieten immer mehr alternative Eingabemöglichkeiten an, und das wirft eine harte Bewertungsfrage auf. Ein Beispiel zeigt das Problem präzise.

Die WCAG enthält ein Prüfkriterium für Gesten- und Bewegungssteuerung: Eine Aktion wie das Schütteln des Geräts, um Daten zu verwerfen, muss alternativ auch mit einem Finger ausführbar sein. Eigentlich müsste die Software diese Alternative selbst anbieten. Auf einem iOS-Gerät kannst du jedoch den AssistiveTouch aktivieren. Damit simuliert das Betriebssystem das Schütteln per Fingertipp.

Ist die Software damit barrierefrei oder nicht? Sie liefert die Alternative nicht selbst, doch im konkreten Umfeld funktioniert die Aufgabe trotzdem. Dem Menschen, der das Gerät bedient, ist die Quelle der Hilfe egal. Hauptsache, es geht.

Mit jedem Release kommen neue Bedienhilfen, und jedes Mal müssen wir neu gucken, weil es da wirklich sehr viel Neues gibt. Dirk Haas

Wie man eine Testmatrix für hunderte Kombinationen aufbaut

Der praktische Weg führt über systematisches Ausprobieren und lückenlose Dokumentation der jeweiligen Konstellation. Eine fertige Lösung für alle Fälle gibt es nicht.

Schröder und Haas setzen sich mehrfach hin, testen Tasten- und Schalterkombinationen und prüfen die Konsequenzen. Wenn ein bestimmter Schalter nicht gesetzt ist und ein blinder Mensch damit alles bedienen kann, gilt das Kriterium für diese Behinderungsart als bestanden. Aber genau diese Bedingung muss explizit vermerkt werden, denn der nächste Nutzer aktiviert die Schaltersteuerung womöglich nicht und kommt keinen Schritt weiter.

Das macht den Geltungsbereich eines Prüfberichts sehr eng. Es existieren mittlerweile hunderte Kombinationen von Schaltermöglichkeiten, die sich unmöglich alle abbilden lassen. Dokumentiert wird deshalb beides: die aktivierten Einstellungen und ausdrücklich auch jene, die zu Fehlern führen.

Eine feste Regel grenzt den Aufwand ein. Innerhalb eines Use Cases wird nicht zwischendurch die Bedienart gewechselt.

Entweder es klappt mit der einen Einstellung, oder es klappt mit der anderen. Aber dass man mittendrin umstellen muss, das ist nicht zumutbar. Thorsten Schröder

Die relevanten Use Cases liefert der Auftraggeber. Ein Tester kann nicht beurteilen, ob ein Blutdruckwert, der täglich fünfmal eingetragen wird, eine andere Relevanz hat als eine Zahl, die nur einmal beim Aufnahmebeginn erfasst wird.

Warum sich Barrierefreiheit kaum automatisiert testen lässt

Barrierefreiheitstests für Assistenzsysteme laufen rein manuell, und das hat einen logischen Grund. Geprüft wird, ob die assistive Technologie überhaupt Zugang zu den Inhalten bekommt.

Ein Screenreader braucht Zugriff auf ein Element, seine Eigenschaften und seinen Status, um es vorlesen zu können. Eine Testsoftware bräuchte denselben Zugang. Wenn ein Feld nicht angesteuert werden kann, lässt sich auch kein automatischer Test dafür schreiben. Genau diese fehlende Ansteuerbarkeit ist aber oft der Mangel, den der Test aufdeckt.

Viele verbreitete Testtools prüfen Dinge wie valides HTML oder das Parsen von HTML. Für einen Menschen mit Behinderung, der mit der Anwendung arbeitet, hat das oft keine Relevanz. Moderne Browser interpretieren auch nicht-valides HTML zuverlässig.

Diese Verschiebung zeigt sich an einer regulatorischen Premiere. Mit der WCAG 2.2 wurde erstmals ein Prüfkriterium aus dem Register gelöscht, das Kriterium zum Parsen von HTML. Tools, die genau darauf spezialisiert sind, würden damit einen erheblichen Teil ihrer Findings verlieren.

Praktisch wirksam ist diese Änderung allerdings noch nicht. Geltende Gesetze und Normen verweisen auf die WCAG, nicht auf einzelne Anpassungen. Erst wenn die europäische Norm EN 301549 nachgezogen ist und der entsprechende Punkt gestrichen wird, ändert sich die Rechtslage. Auf europäischer Ebene dauern solche Anpassungen lange.

iOS und Android nähern sich an, aber Gewohnheit bindet

Der frühere Vorsprung von Apple bei Assistenzsystemen ist heute weitgehend aufgeholt. Die Funktionalitäten finden sich mittlerweile fast eins zu eins in beiden Systemen.

Apple hat Screenreader und assistive Systeme von Anfang an integriert. Mit jeder neuen iOS-Version kommen weitere Features hinzu, etwa eine Tür- oder Objekterkennung über die Lupe, die per Kamera Menschen oder Gegenstände identifiziert. Für Tester bedeutet das nicht weniger, sondern mehr Aufwand, weil jede neue Möglichkeit die Testmatrix vergrößert.

Ein praktischer Faktor bleibt: Wer sich einmal an ein Gerät und seine Bedienung gewöhnt hat, wechselt selten. Das gilt für alle Nutzer und besonders für jene, die auf Assistenzsysteme angewiesen sind.

Was für Behinderte gebaut wird, nützt allen

Funktionen für Menschen mit Behinderung sind für alle anderen ebenfalls nützlich. Dieser Curb-Cut-Effekt beschreibt genau das Phänomen.

Ein hoher Kontrast oder ein Schwarz-Weiß-Modus hilft nicht nur sehbehinderten Menschen. Sobald du draußen in der Sonne stehst und die Oberfläche deines Handys spiegelt, ist ein hoher Kontrast oft die einzige Chance, überhaupt noch etwas zu erkennen. Bei rosa auf grün siehst du dann gar nichts mehr.

Solche Hilfen werden im Alltag genutzt, ohne dass die ursprüngliche Absicht bewusst wäre. Das ist eines der stärksten Argumente, um Barrierefreiheit zu vermitteln: Sie ist nicht nur für Behinderte, sie bringt einer breiten Nutzergruppe einen Vorteil.

Warum Tester mit Behinderung gezielt einbezogen werden, aber nicht für jeden Test

Menschen mit Behinderung werden punktuell einbezogen, ein vollständiger Test mit allen Behinderungsgruppen wäre aber nicht leistbar. Der Aufwand würde explodieren.

Ein blinder Mensch sieht nicht, was er nicht sieht. Wenn ein Element gar nicht angesteuert wird, kann er nicht beurteilen, ob es richtig oder falsch umgesetzt ist. Für einen umfassenden Test bräuchte man hörgeschädigte, motorisch eingeschränkte, stark sehbehinderte und blinde Personen in jeweils unterschiedlichen Ausprägungen.

Schröder und Haas decken mit ihrer eigenen Prüfung ein breites Portfolio ab und holen sich bei Unsicherheiten gezielt Expertise. Bei der Entwicklung eines neuen Designsystems ist ein blinder Mitarbeiter von Anfang an eingebunden, ein ehemaliger Softwareentwickler für Screenreader. Sein fachlicher Beitrag ist der eine Effekt.

Der andere Effekt ist die Kommunikation. Wer mit einem blinden Kollegen zusammenarbeitet, kann ihm nicht einfach einen Screenshot ohne Beschreibung schicken. Das Team wird dadurch gezwungen, selbst barrierefrei zu kommunizieren. Auch die eigenen Präsentationsunterlagen lässt das Team prüfen, denn wer über das Thema spricht, sollte seine Inhalte mindestens im selben Maß zugänglich machen.

Dabei zeigt sich, wie unterschiedlich Nutzer arbeiten. Es gibt blinde Menschen, die kein Braille beherrschen und nur mit Sprachausgabe arbeiten, und andere, die ausschließlich auf die Braillezeile setzen. Beide verstehen die Arbeitsweise des jeweils anderen kaum. Diese Vielfalt im Test vollständig abzugleichen, sprengt jeden realistischen Umfang.

Die Tester selbst gehen bewusst naiv vor und nutzen die Software so, wie sie es eben hergibt. Erfahrene Screenreader-Nutzer haben sich eigene Vorgehensweisen erarbeitet, kennen die Problemstellen und umgehen sie automatisch. Genau das kann aber nicht der Maßstab sein, denn dann müssten alle anderen es ebenso können.

Barrierefreiheit ist kein reines Technikthema

Die größte Fehlannahme ist, barrierefreie IT sei allein Sache der Technik. Stimmt die Struktur einer Anwendung nicht, hilft die beste technische Umsetzung nichts.

Wenn ein Design schlecht aufgebaut ist und die technische Struktur nicht der optischen Darstellung entspricht, findet sich ein blinder Mensch nie zurecht. Das passiert etwa, wenn jemand mit Layout-Tabellen arbeitet. Die Verantwortung liegt deshalb nicht beim Entwickler am Ende der Kette, sondern beim Designer, bei den Textern und bei den Erstellern der Dokumente.

Ein Dokument lässt sich technisch sofort scheinbar barrierefrei machen, indem man alle Inhalte als Artefakt kennzeichnet. Das Prüftool meldet dann grün, weil für den Screenreader nichts mehr drinsteht. Für den blinden Nutzer ist das Dokument damit aber leer. Barrierefreiheit muss von oben mitgedacht werden, bei der Programmgestaltung und beim Bereitstellen von Zeit und Ressourcen.

Die nächste große Baustelle sind barrierefreie Dokumente

Das Thema, das aktuell alle Beteiligten umtreibt, ist die Bereitstellung barrierefreier Dokumente und Formulare. Der Weg weg vom Papier hin zu elektronisch zugänglichen Inhalten ist riesig.

Der Aufwand pro Dokument ist nicht endlos, aber die Anzahl der Dokumente ist es fast. Wer in sein eigenes Unternehmen schaut, findet Dienstanweisungen, Formulare und Texte in einer Menge, die abschreckt. Jedes davon müsste einmal barrierefrei aufbereitet werden. Eine Teilautomatisierung über entsprechende Tools ist in Arbeit, ändert aber nichts daran, dass schlechter Inhalt auch barrierefrei schlecht bleibt.

Der Druck verteilt sich unterschiedlich. Öffentliche Träger wie die Rentenversicherung stehen ohnehin schon unter gesetzlicher Verpflichtung. Für den freien Markt wird es jetzt relevant: Wer einen Webshop in Europa etablieren will und keine Strafen der Marktaufsicht riskieren möchte, muss anfangen, Barrierefreiheit umzusetzen, sonst wird es teuer.