Plattformmechanismen und Ausnahmen (Teil 5)

Mechanismus

In mehreren Erfolgskriterien verwendet die WCAG den Ausdruck „ein Mechanismus ist verfügbar“. Diese Formulierung drückt lediglich aus, dass ein Mechanismus vorhanden sein muss; sie gibt jedoch nicht an, wo Nutzende ihn finden sollten: Das kann in der Ansicht selbst, in den Einstellungen einer App oder sogar in den Plattformeinstellungen der Fall sein (bei Webinhalten finden Sie diese in den User-Agent-Einstellungen – also in den Browsereinstellungen).

Beispielsweise verlangt das Erfolgskriterium 2.2.2 Pause, Stop, Hide, dass Nutzende die Möglichkeit haben, bewegte Inhalte wie ein sich automatisch aktualisierendes Karussell oder ein automatisch abspielendes Video anzuhalten, zu stoppen oder auszublenden:

“For any moving, blinking or scrolling information (…) there is a mechanism for the user to pause, stop, or hide it.”

Dieser Wortlaut lässt offen, ob der Mechanismus vom Betriebssystem bereitgestellt werden kann.

Die folgenden Beispiele veranschaulichen, wie ein solcher Mechanismus vom Betriebssystem und nicht von der Anwendung selbst bereitgestellt werden kann:

• Bewegungen reduzieren: Bei iOS gibt es die Einstellung „Bewegungen reduzieren“ und bei Android die Einstellung „Animationen entfernen“ – und sofern der Inhalt diese Einstellung berücksichtigt und die Bewegung tatsächlich stoppt, hört die Bewegung auf.
• Kontrast erhöhen: iOS verfügt über die Einstellung „Kontrast erhöhen“ unter „Barrierefreiheit“ > „Anzeige und Textgröße“. Aktivieren Sie diese, und native iOS-Schaltflächen, die im Standardzustand die Anforderung 1.4.11 Kontrast von Nicht-Text-Elementen nicht erfüllen, werden diese nun erfüllen.

Man kann argumentieren, dass in Fällen, wo das Betriebssystem einen solchen Mechanismus bereitstellt, die normative Anforderung erfüllt ist – natürlich nur, solange die App die gewählte Einstellung in der Darstellung auch tatsächlich berücksichtigt. Dies ist jedoch eine Grauzone, und unter Barrierefreiheitsfachleuten herrscht noch kein klarer Konsens darüber, ob ein solcher plattformseitiger Mechanismus ausreicht, die Anforderung zu erfüllen. Schließlich ist der Mechanismus nicht unmittelbar im oder neben dem Inhalt zu finden, wie beispielsweise eine in ein Video oder ein animiertes Karussell integrierte Pause-Schaltfläche.

Vor- und Nachteile beim Sich-Verlassen auf Plattformmechanismen

Ein großer Vorteil von Mechanismen, die von der Plattform bereitgestellt werden, besteht darin, dass sie – sobald sie einmal eingestellt sind – die Barrierefreiheit für die Nutzenden insgesamt verbessern, unabhängig von der jeweiligen App. Bei korrekter Umsetzung sollten alle Apps die Benutzereinstellungen wie „Bewegungen reduzieren“ berücksichtigen und keine bewegten Inhalte oder automatisch abspielenden Videos mehr anzeigen. Das Argument lautet: Wenn Nutzende generell Anpassungen wie reduzierte Bewegungen, größeren Text oder besseren Kontrast benötigen (Display-Zoom oder fetter Text sind weitere solche allgemeinen Einstellungen), ist es sinnvoll, diese Anpassungen auf Plattformebene vorzunehmen, anstatt die Entwicklerinnen und Entwickler zu zwingen, solche Elemente in die App selbst einzubauen, mit dem Risiko, dass solche Custom-Funktionen ggf. bei dem nächsten Plattform-Update nicht mehr funktionieren oder nicht mehr den jeweiligen Systemkonventionen entsprechen.

Diejenigen, die die Erfüllung von Anforderungen über einen Plattformmechanismus für unzureichend halten, argumentieren, dass viele Nutzende, die von Problemen wie ablenkenden Bewegungen oder geringem Kontrast betroffen sind, schlichtweg nicht wissen, dass es eine Plattformeinstellung gibt, mit der sich die Situation verbessern lässt.

Ältere Nutzende sind von diesen Problemen überproportional betroffen und oft nicht technisch versiert. Sie sind mit den Feinheiten der Plattform und ihren zahlreichen Einstellungen häufig nicht vertraut. Zudem sind diese Einstellungen in der Regel nicht standardmäßig aktiviert.

2.2.2 „Pause, Stop, Hide“ ist nicht das einzige WCAG-Erfolgskriterium, in dem die Wendung “Es gibt einen Mechanismus” vorkommt. Sie findet sich in folgenden Kriterien auf den WCAG-Stufen A und AA, die für Software gelten (für Erfolgskriterium 3.3.8 erst nach Inkrafttreten der EN 301 549 v.4.1.0):

• 1.4.2 Audio-Steuerelement
• 1.4.13 Eingeblendeter Inhalt bei Darüberschweben (Hover) oder Fokus
• 2.1.4 Tastaturkürzel
• 2.2.2 Pausieren, Stoppen, Ausblenden
• 2.5.2 Abbruch der Zeigeraktion
• 3.3.8 Zugängliche Authentifizierung

Native Ausnahmen

Wird kein Mechanismus erwähnt, gibt es noch eine weitere Möglichkeit, wie Inhalte ein Erfolgskriterium erfüllen können – selbst wenn sie auf den ersten Blick nicht den Eindruck machen: die Ausnahme „nicht vom Autor verändert“. Sie greift, wenn eine native Komponente unverändert verwendet wird, also beispielsweise ohne Änderungen an ihrer Darstellung oder Farbgebung. 

In einer Reihe von WCAG-Erfolgskriterien wird der Ausdruck „nicht vom Autor verändert“ ausdrücklich zur Definition von Ausnahmen erwähnt. Der Kürze halber führe ich erneut nur entsprechende Kriterien der Stufen A und AA auf:

• 1.4.11 Nicht-Text Kontrast: Diese Ausnahme gilt sowohl für native Komponenten (wie die nicht kontrastreichen iOS-Umschalter) als auch für die Plattform-eigene Tastaturfokus-Hervorhebung.
• 1.4.13 Eingeblendeter Inhalt bei Darüberschweben (Hover) oder Fokus: Native Ausnahmen spielen für mobile Apps eigentlich keine Rolle, da Titel-Attribute weder bei Hover (bei Verwendung einer angeschlossenen Maus) noch beim Erhalt des Tastatur-Fokus eingeblendet werden.
• 2.5.7 Ziehbewegungen: Diese Ausnahme gilt, wenn das Verhalten über eine Plattformfunktion bereitgestellt wird.
• 2.5.8 Zielgröße (Minimum): Auch hier gelten ggf. Ausnahmen für native Komponenten.

Aus Sicht der Nutzenden bedeutet dies, dass eine native Komponente einen offensichtlichen Mangel aufweisen kann, wie beispielsweise einen unzureichenden Kontrast, diese jedoch die Prüfung besteht, da die Gestaltung der Komponente nicht von der Autorin oder dem Autor bestimmt wird.

Ein gutes Beispiel hierfür ist die schlechte Sichtbarkeit des Tastaturfokus in nativen mobilen Apps. Sowohl unter iOS als auch unter Android weist die Standard-Tastaturfokus-Hervorhebung einen zu geringen Kontrast auf: Es handelt sich lediglich um einen hellgrauen oder hellblauen Farbton mit einem Kontrastverhältnis von etwa 1,2:1, die bei manchen Elementen schwer zu erkennen oder fast unsichtbar ist. Die Plattformeinstellungen können hier jedoch zum Teil Abhilfe schaffen: Die iOS-Einstellung „Vollständiger Tastaturzugriff“ versieht den Tastaturfokus mit einem dicken schwarzen Umriss (für Android gibt es derzeit keine entsprechende Option).

Bei  der Anforderung 2.5.8 Zielgröße ist zu beachten, dass die Anforderung eigentlich nicht darin besteht, dass ein Ziel eine bestimmte Mindestgröße haben muss; vielmehr muss um das Ziel herum genügend Platz (eine Fläche von 24 x 24 Pixel) vorhanden sein, um es von benachbarten Zielen abzugrenzen.

Es könnte beispielsweise Fälle geben, in denen Checkboxen, die als vertikale Liste angeordnet sind, zu dicht beieinander liegen und damit von der Ausnahme erfasst wären.

Im Allgemeinen sind Verstöße gegen 2.5.8 Zielgröße in mobilen Apps jedoch recht selten. Dies liegt unter anderem daran, dass die empfohlene Zielgröße im mobilen Design deutlich größer ist als das in den WCAG festgelegte Minimum: 44 x 44 pt unter iOS und 48 x 48 dp unter Android. Für eine eingehende Betrachtung können Sie das GitHub-Issue zu 2.5.8 Target Size der Mobile Accessibility Task Force lesen.

Fazit

Selbst wenn Plattformmechanismen oder native Ausnahmen als ausreichend angesehen werden könnten, um die Anforderungen zu erfüllen, sollten Autorinnen und Autoren den Nutzenden die bestmöglichen Erfahrungen im Ausgangszustand bieten. In manchen Fällen ist die Schlussfolgerung einfach: Spielen Sie Audio oder Video nicht automatisch ab und verwenden Sie keine automatisch aktualisierenden Karussells. Überlassen Sie dem Nutzenden die Kontrolle und ersparen Sie ihnen die Suche nach der Pausetaste oder der entsprechenden Systemeinstellung.

In anderen Fällen ist die Situation nicht ganz so eindeutig. Viele Fachleute empfehlen die Verwendung von Systemkomponenten auch dann, wenn diese bekannte Probleme aufweisen, wie beispielsweise Kontrastmängel bei den iOS-Umschaltern, bei systemeigenen Widgets für die Datums- oder Zeitauswahl, oder bei Schiebereglern.

Der große Vorteil der Verwendung von Standardkomponenten gegenüber der Entwicklung eigener, vermeintlich barrierefreierer Elemente besteht darin, dass die Nutzenden diese Komponenten oft bereits aus anderen Anwendungskontexten in anderen Apps kennen. Funktionalität und Verhalten sind fester Bestandteil dieser nativen Komponenten und in der Regel wesentlich robuster als das, was Entwickelnde hinbekommen, wenn sie ihre eigenen Widgets entwickeln. Un dann kommen Verbesserungen der Barrierefreiheit, die durch ein Update auf Plattformebene vorgenommen werden, allen Apps zugute, die native Komponenten anstelle von „optimierten“ benutzerdefinierten Komponenten verwenden.