Menschen mit Behinderungen nutzen häufig Hilfsmittel, sogenannte assistive Technologien, um auf digitale Inhalte zuzugreifen.
Spezielle Programme und Eingabegeräte ermöglichen es, digitale Inhalte auch dann zu nutzen, wenn die üblichen Formen der Eingabe und Ausgabe über Maus, Touch oder Tastatur nicht geeignet sind. In diesen Fällen helfen assistive Technologien.
Sowohl iOS (iPhone) als auch Android bieten integrierte Funktionen, um das Display in eine Braille-Tastatur zu verwandeln.
Die autorisierte Übersetzung der Web Content Accessibility Guidelines (WCAG) 2.2 definiert „Assistierende Technik“ (so wird in der autorisierten Übersetzung assistive Technologie genannt) wie folgt:
„Assistierende Technik (wie in diesem Dokument benutzt): Hardware und/oder Software, die als Benutzeragent fungiert oder die mit einem gängigen Benutzeragenten zusammenarbeitet, um Funktionalität zur Verfügung zu stellen, damit die Anforderungen von Benutzern mit Behinderungen erfüllt werden, die über jene hinausgehen, die von gängigen Benutzeragenten angeboten werden.“
Diese Definition ist etwas sperrig. Zur Erklärung: Bei Web-Inhalten ist der typische „gängige Benutzeragent“ der Browser. Ein Screenreader, ein Spracherkennungsprogramm oder eine Vergrößerungssoftware sind demnach zusätzliche Benutzeragenten, die mit dem Browser zusammenarbeiten. Wir nutzen dafür den allgemeinen Begriff assistive Technologien.
In der Welt des Desktop-Computings wurden (und werden) viele dieser assistiven Technologien als Desktop-Anwendung bereitgestellt, die zum Teil zusammen mit einem speziellen Ein- oder Ausgabegerät funktionieren, etwa einer Schaltersteuerung, einer Mund-Maus oder einer Braillezeile bzw. einem Braille-Notizgerät.
Schon im Desktop-Computing gab es den Trend, Barrierefreiheitsfunktionen zunehmend in das Betriebssystem zu integrieren: etwa Seitenzoom, kontrastreicher Modus, großer Cursor oder deutlicherer Tastaturfokus. Auch die Sprachausgabe und -eingabe sowie Screenreader sind heute schon systemseitig vorhanden, leisten allerdings oft weniger als dezidierte Software. Auf den mobilen Plattformen Android und iOS ist dagegen keine zusätzliche assistive Technologie erforderlich, um Menschen mit Behinderungen die Nutzung zu ermöglichen. Es gibt natürlich eine Reihe von assistiven Apps, die man zusätzlich installieren kann und die spezielle Funktionen bieten, zum Beispiel Text- oder Bilderkennung für blinde Nutzende, optische Vergrößerung bzw. digitale Lupen für Nutzende mit Seheinschränkungen, oder Apps für nonverbale Nutzende, die über Bilder kommunizieren. Dagegen sind die meisten grundlegenden Hilfs-Funktionen, die traditionell durch extern installierte assistive Technologien bereitgestellt wurden, in die mobile Plattform eingewandert und direkt über die Einstellungen verfügbar.
Die wichtigsten mobilen Betriebssysteme, Android und iOS, verfügen inzwischen über eine breite und ständig wachsende Palette von Barrierefreiheitseinstellungen. Hardware-Eingabegeräte wie Braillezeilen, Tastaturen oder Schaltersteuerungen können auch an Smartphones oder Tablets angeschlossen werden, normalerweise über USB C oder Bluetooth, ohne dass eine spezielle Software dafür erforderlich wäre. In einigen Fällen gibt es sogar alternative Eingabemöglichkeiten für den Touchscreen, für die früher physische Geräte erforderlich waren, z. B. die Braille-Eingabe (siehe Foto).
Beim Testen der Barrierefreiheit von mobilen Apps ist die Nutzung (und Kenntnis) der eingebauten Screenreader TalkBack (Android) und VoiceOver (iOS, iPadOS) weitaus wichtiger als beim Test von Websites und -Anwendungen. Der Grund: Während die Prüfenden beim Web-Test mit Hilfe der Developer Tools des Browsers „unter die Haube“ schauen, also den Quelltext der Seite analysieren und das DOM – das Document Object Model, dass den jeweiligen Zustand der Seite im Browser abbildet – sogar ändern kann, sind Apps für die Prüfenden in der Regel nicht quelloffen. Erst die Nutzung mit eingeschaltetem Screenreader zeigt wirklich, ob alle Texte ausgegeben werden, ob interaktive Elemente fokussierbar und mit angeschaltetem Screenreader aktivierbar sind, und ob die zugänglichen Namen und wechselnden Zustände von interaktiven Elementen wie Schaltern richtig ausgegeben werden.
Wie man „assistive Technologien“ genau definiert, scheint weitgehend irrelevant zu sein, bis man auf ein WCAG-Erfolgskriterium (auch in der europäischen Norm verwendet) stößt, bei dem es von dieser Definition abhängt, ob die Anforderung überhaupt zur Anwendung kommt. Ich beziehe mich auf 1.4.4 Resize Text. Das Erfolgskriterium fordert, dass Text ohne assistive Technologie auf bis zu 200 Prozent vergrößert werden kann, und zwar ohne Verlust von Inhalten oder Funktionalität (meine Hervorhebung). Diese Anforderung, die für Webinhalte erstellt wurde, noch bevor es Browser-Zoom gab, ist auch in den Erfolgskriterien für Software enthalten.
Angesichts dieser Situation stellt sich die Frage, ob ins mobile Betriebssystem integrierte Funktionen unter assistive Technologien fallen. Einstellungen für Textgröße, vergrößertes Display, fettgedruckten Text oder Dunkelmodus finden sich als Standardeinstellungen für Nutzende, sie sind also nicht versteckt in den Bedienungshilfen-Einstellungen. Und Funktionen der Bedienungshilfen wie Screenreader, Zoom usw. werden bei jedem regelmäßigen Systemupdate automatisch mit aktualisiert. Diese integrierten Barrierefreiheitsfunktionen fungieren nicht als Benutzeragenten oder arbeiten „mit einem Benutzeragenten“ zusammen. Für native Apps gibt es keinen Benutzeragenten; die zugrunde liegende Plattform ist das mobile Betriebssystem.
Während Browser beim Zoomen der Seite nicht nur die Größe des Textes ändern, sondern üblicherweise auch einen Umbruch der Inhalte auslösen, gibt es in mobilen Apps selbst normalerweise keine Textvergrößerung. Mobile Browser unterstützen in der Regel das Vergrößern von Inhalten über eine zwei-Finger Pinzetten-Geste, native Apps jedoch meist nicht. Es gibt jedoch sowohl in Android als auch in iOS eine Zoomfunktion, die in den Bedienungshilfen aktiviert werden kann. Sie funktioniert auf etwas andere Weise, aber in beiden Betriebssystemen ist es möglich, jeden Inhalt auf dem Display auf 500 % zu vergrößern.
Ist dies eine ideale Erfahrung für sehbehinderte Nutzende, die großen Text brauchen? Definitiv nicht. Aufgrund der kleinen Bildschirmgröße des Smartphones wird gezoomter Text abgeschnitten, und das Lesen erfordert das dauernde Verschieben des sichtbaren Ausschnitts. Es funktioniert etwas besser, wenn das Gerät ins Querformat gedreht wird, weil dann mehr Platz für die Textzeile vorhanden ist. Dennoch ist die Erfahrung dem Textumbruch in einem mobilen Browser weit unterlegen.
Aus diesem Grund neigen viele Fachleute zu der Ansicht, dass die systemseitige Zoom-Funktion unter die Rubrik „assistive Technologie“ fallen sollte und damit als nicht ausreichend zur Erfüllung der Anforderung an Textgröße angesehen werden sollte (siehe etwa die Diskussion der Mobile Accessibility Task Force in System settings as sufficient techniques?). Stattdessen argumentieren sie, dass Textinhalte in mobilen Apps auf Änderungen in den Textgrößeneinstellungen des Betriebssystems reagieren sollten. Wenn dies gut implementiert ist, bricht der vergrößerte Text um und bietet so eine bessere Nutzbarkeit. Das Erfolgskriterium 1.4.4 Resize Text schreibt jedoch keinen Umbruch vor. Das gehört in ein anderes Erfolgskriterium, 1.4.10 Reflow, das auch schwierig auf native mobile Apps anzuwenden ist (dazu ein anders Mal mehr).
Die Unterstützung von Textvergrößerung über OS-Textgrößeneinstellungen ist eine empfohlene Praxis. Sie ist jedoch nicht vorgeschrieben, wenn man sich die Formulierung der normativen Anforderung ansieht. Da sich die Textänderung auf alle Inhalte ausdehnen würde, führt die Größenänderung des gesamten Textes auf einem kleinen Display auf 200 % auch zu Problemen für Inhalte mit begrenztem Platz. Denken Sie an die typischen Tab-Leisten, die eine Navigation mit etwa 4-5 Tabs am unteren Bildschirmrand bieten. Viele davon haben Textlabel, die bei Verdoppelung der Textgröße entweder das Design aufbrechen oder abgeschnitten würden, was das Lesen erschwert.
Die neueste Version der europäischen Norm, EN 301 549 V4.1, erkennt an, dass das Erfolgskriterium 1.4.4 Resize Text bei Anwendung auf Software wie mobile Apps problematisch ist, und fordert, dass „die Nicht-Web-Software mit den Textvergößerungsfunktionen in dem Maße arbeiten sollte, wie es die Plattform zur Verfügung stellt“ (siehe WCAG2ICT Applying SC 1.4.4 Resize Text to Non-Web Software).
NOTE 2 in Understanding 1.4.4 Resize Text (WCAG2ICT) verdeutlicht, dass zur Erfüllung der Anforderung die Plattformfunktionen (wie iOS Zoom und Android Vergrößerung sie bieten) als ausreichend angesehen werden.
Der Abschnitt „Intent" bezieht sich auf die Möglichkeit, Nutzenden zu erlauben, den Text auf dem Display um mindestens 200 % zu vergrößern, ohne dass assistive Technologien verwendet werden müssen. Dies bedeutet, dass die Nicht-Web-Software Mittel zur Vergrößerung des Textes um 200% (Zoom oder anderweitig) ohne Verlust von Inhalt oder Funktionalität bietet oder dass die Nicht-Web-Software mit den Plattformfunktionen arbeitet, um dieses Erfolgskriterium zu erfüllen (meine Hervorhebung).
Hier wie in vielen anderen Fällen gehen Empfehlungen (best practices) über die normativen Anforderungen hinaus. Testverfahren wie der BIK-BITV-Test (App), die sich an den Vorgaben des Standards orientieren, müssen sich jedoch an den begrenzteren normativen Wortlaut der Anforderungen halten.
Im Fall von 1.4.4 Resize Text (in der EN mit 11.1.4.4 nummeriert) bedeutet dies, dass mobile Apps 1.4.4 automatisch erfüllen, wenn Inhalte mithilfe von Plattformfunktionen vergrößert werden können. Für Bewertungen auf Basis der WCAG, die auf IKT angewendet werden, wie im WCAG2ICT-Dokument beschrieben, ist die Sache damit erledigt.
Wenn jedoch die Europäische Norm (EN) 301 549 (Abschnitt 11 Software) als Grundlage der Prüfung dient, gibt es zusätzliche Anforderungen. Hier verlangt 11.7 Benutzerpräferenzen, dass „die Benutzeroberfläche den Werten der Benutzereinstellungen folgen muss, die Benutzer für die dokumentierten Barrierefreiheitsfunktionen der Plattform festgelegt haben“. Wenn Nutzende in ihren Einstellungen eine größere Schriftgröße wählen, sollte der Text in der App darauf reagieren. Dies kann als Gewinn für Nutzende angesehen werden, deren Apps unter die EU-Gesetzgebung fallen (auch wenn es das Leben für App-Entwickler erschweren mag).
Kommentare
Alle Felder sind Pflichtfelder