🥇Auf dem Weg zur Verfügbarkeit

Freitag – das Ende des Arbeitstags. Schlechte Nachrichten kommen immer freitags kurz vor Feierabend.

Sie sind im Begriff, das Büro zu verlassen, als ein neues Schreiben zu einer erneuten Umstrukturierung just jetzt in Ihrem Postfach eingeht.

Danke xxxx, yyy, ab heute werden Sie an zzzz berichten.
…
Und das Team von Hugh wird die Verfügbarkeit unserer Produkte für Menschen mit Einschränkungen sichern.

Oh nein! Was habe ich getan, um das zu verdienen? Wollen die, dass ich gehe? Ich muss mich auf eine undankbare, harte Arbeit einstellen und versuchen, die Fehler anderer zu beheben. Das wird sicher ein Misserfolg...

So war die Verfügbarkeit vor einigen Jahren. Einige Arme hatten den Job, die Benutzeroberfläche zu "säubern", um sie für Menschen mit Einschränkungen zugänglich zu machen.

Was das tatsächlich bedeutete, war ziemlich vage – wahrscheinlich, wenn Sie den Fokusindikator sehen und sich mit der Tabulatortaste durch die Felder bewegen konnten, einen alternativen Text hatten und ein paar Beschreibungen zu den Feldern, dann galt Ihre Anwendung als zugänglich...

Aber plötzlich begannen sich die „Bugs“ wie eine Lawine zu vermehren.

Verschiedene Screen Reader und Browser verhielten sich absolut unterschiedlich.eng. Benutzer beschwerten sich, dass die Anwendung unbenutzbar sei.

Sobald ein Fehler an einer Stelle behoben war, trat an einer anderen ein neuer auf.

Und einfach nur Fehler in der Benutzeroberfläche zu ändern und zu beheben, erforderte titanische Anstrengungen.

Ich war dort. Ich habe überlebt, aber wir haben nicht "überlebt" – technisch haben wir viel bereinigt, viele Beschreibungen zu den Feldern hinzugefügt, Rollen vergeben und ein gewisses Maß an Konformität erreicht, aber niemand war glücklich. Die Benutzer beschwerten sich weiterhin, dass sie sich in der Anwendung nicht zurechtfanden. Der Manager beschwerte sich weiterhin über einen ständigen Strom von Fehlern. Die Ingenieure beschwerten sich über unklare Aufgabenstellungen ohne klar definierte "richtige" Lösungen, die in allen Fällen funktionierten.

Auf meinem Weg zum Verständnis von Zugänglichkeit gab es einige offensichtlich aufschlussreiche Momente.

Ich wusste, dass ich ein großes Problem lösen musste.
Möglicherweise war das erste Verständnis, dass es schwierig ist, Zugänglichkeitsfunktionen über ein bestehendes Produkt zu legen. Und es ist noch schwieriger, die Manager davon zu überzeugen, dass es unglaublich kompliziert ist! Es ist nicht einfach "ein paar Tags hinzuzufügen" und die Benutzeroberfläche wird großartig funktionieren. Nein, es ist unmöglich, das in drei Wochen abzuschließen, selbst drei Monate werden nicht ausreichen.
Mein nächster Moment der Wahrheit kam, als ich mit eigenen Augen sah, wie blinde Benutzer tatsächlich unsere Anwendung nutzen. Das ist SO anders, als nur Fehlermeldungen zu betrachten.

Ich werde immer wieder darauf zurückkommen, aber fast alle unsere "Annahmen" darüber, wie Menschen unsere Anwendung nutzen, waren falsch.

Die Navigation durch eine komplexe Benutzeroberfläche mit Tasten Tab/Shift+Tab – das ist frustrierend! Wir brauchen etwas Besseres. Tastenkombinationen, Überschriften.

Ein Verlust des Fokus beim Ändern der Benutzeroberfläche ist doch kein großes Problem? Lassen Sie uns noch einmal darüber nachdenken – das ist wahnsinnig verwirrend.

Ich arbeitete eine Weile an verschiedenen Projekten, und dann begannen wir ein neues Projekt mit einer komplexen Benutzeroberfläche und dem klaren Ziel, dieses Mal endlich die richtige Zugänglichkeit zu erreichen.

Also machten wir einen Schritt zurück und schauten, wie wir dies anders umsetzen und erfolgreich sein können, während der gesamte Arbeitsprozess nicht langweilig ist!

Relativ schnell kamen wir zu einigen Schlussfolgerungen:

Wir wollten nicht, dass die Leute, die die Benutzeroberfläche entwickeln, sich mit aria-Bezeichnungen/Rollen und natürlich mit der HTML-Struktur der Komponenten herumärgern. Wir mussten ihnen die richtigen Komponenten zur Verfügung stellen, bei denen die Zugänglichkeit direkt "out of the box" realisiert ist.
Zugänglichkeit == Benutzerfreundlichkeit – d.h. es ist nicht nur eine technische Aufgabe. Wir mussten den gesamten Designprozess ändern und sicherstellen, dass die Zugänglichkeit vor Beginn des Designs der Benutzeroberfläche berücksichtigt und diskutiert wird. Es muss von Anfang an überlegt werden, wie Benutzer eine Funktionalität entdecken können, wie sie navigieren und wie das "rechte Mausklicken" über die Tastatur funktionieren wird. Zugänglichkeit sollte ein integraler Bestandteil des Designprozesses sein – für einige Benutzer ist sie viel mehr als nur das Erscheinungsbild der Anwendung.
Von Anfang an wollten wir Feedback von blinden und anderen Nutzern mit Einschränkungen zur Benutzerfreundlichkeit der App erhalten.
Wir brauchten wirklich gute Möglichkeiten, um regressiv zugängliche Probleme zu erkennen.

Nun, aus ingenieurtechnischer Sicht klang der erste Teil ziemlich interessant – die Entwicklung der Architektur und die Implementierung der Komponentenbibliothek. Und tatsächlich war es genau so.

Wenn man einen Schritt zurücktritt und ARIA-Beispiele betrachtet und darüber nachdenkt, dass dies ein Designproblem und kein Anpassungsproblem ist, haben wir einige Abstraktionen eingeführt. Eine Komponente hat eine 'Struktur' (bestehend aus HTML-Elementen) und ein 'Verhalten' (wie sie mit dem Nutzer interagiert). Zum Beispiel haben wir in den folgenden Fragmenten eine einfache ungeordnete Liste. Durch das Hinzufügen von 'Verhalten' zur Liste werden die entsprechenden Rollen hinzugefügt, damit sie wie eine Liste funktioniert. Das Gleiche machen wir für Menüs.

Tatsächlich werden hier nicht nur Rollen hinzugefügt, sondern auch Ereignis-Handler für die Navigation mit der Tastatur.

Das sieht schon viel ordentlicher aus. Wenn wir eine klare Trennung zwischen ihnen erreichen könnten, wäre es unwichtig, wie die Struktur erstellt wurde, wir könnten Verhaltensweisen anwenden und die richtige Barrierefreiheit erreichen.

Dies kann man in Aktion unter der Adresse sehen https://stardust-ui.github.io/react/ – der UX-Bibliothek React, die von Anfang an mit Blick auf die Zugänglichkeit entworfen und umgesetzt wird.

Der zweite Teil – die Änderung des Ansatzes und der Prozesse rund um das Design – hat mich anfangs eingeschüchtert: bescheidene Ingenieure, die versuchen, organisatorische Veränderungen durchzusetzen, enden nicht immer gut, aber es stellte sich als einer der interessantesten Bereiche heraus, in denen wir einen bedeutenden Beitrag zu dem Prozess geleistet haben. Kurz gesagt, wir hatten den folgenden Prozess: Neue Funktionalitäten wurden von einem Team entwickelt, danach analysierte / iterierte unsere Gruppe von Führungskräften diesen Vorschlag, und nach der Genehmigung wurde das Design in der Regel an das Ingenieurteam übergeben. In diesem Fall hatte das Ingenieurteam tatsächlich die 'Besitz' über die Barrierefreiheit, da es alle damit verbundenen Probleme beheben musste.

Anfangs war es eine ziemlich schwierige Aufgabe – zu erklären, dass Zugänglichkeit und Benutzerfreundlichkeit untrennbar miteinander verbunden sind und dass dies bereits in der Entwurfsphase berücksichtigt werden muss, da es sonst zu größeren Änderungen und einer Neuinterpretation einiger Rollen kommt. Dennoch konnten wir mit Unterstützung des Managements und wichtiger Akteure diese Idee vermitteln und umsetzen, damit die Designs vor der Präsentation beim Management auf Zugänglichkeit und Benutzerfreundlichkeit überprüft werden.

Und dieses Feedback war für alle äußerst wertvoll – es war fantastisch, wie eine Übung zum Wissensaustausch und zur Informationsweitergabe darüber, wie Benutzer mit Webanwendungen interagieren; wir konnten zahlreiche Schwachstellen der Benutzeroberfläche identifizieren, bevor sie gebaut wurden. Die Entwicklerteams verfügen nun über viel bessere Spezifikationen, nicht nur für die visuellen, sondern auch für die verhaltensbezogenen Aspekte des Designs. Die echten Diskussionen sind lebhafte, energiegeladene, leidenschaftliche Gespräche über technische Aspekte und Interaktionen.

Wir könnten diese Arbeit noch besser machen, wenn bei diesen (oder zukünftigen) Treffen auch blinde Benutzer und Benutzer mit Einschränkungen anwesend wären – das war schwer zu organisieren, aber jetzt arbeiten wir tatsächlich mit lokalen Organisationen für Blinde sowie mit Unternehmen zusammen, die externes Testing für die Überprüfung des Nutzungspfades in den frühen Entwicklungsphasen anbieten – sowohl auf Komponenten- als auch auf Nutzungspfadebene.

Jetzt verfügen die Ingenieure über ziemlich detaillierte Spezifikationen, zugängliche Komponenten, die sie für die Implementierung verwenden können, und eine Möglichkeit, den Nutzungspfad zu überprüfen. Teilweise hat uns die Erfahrung gelehrt, dass wir ständig etwas übersehen – wie wir Regressionen verhindern können. In ähnlicher Weise können die Menschen Integrations- oder End-to-End-Tests verwenden, um die Funktionalitäten zu überprüfen, die wir benötigen, um Änderungen in Interaktionen und Nutzungspfaden zu erkennen – sowohl in visueller als auch in verhaltensbezogener Hinsicht.

Die Definition von visueller Regression ist eine ziemlich präzise Aufgabe, zu diesem Prozess lässt sich nur sehr wenig hinzufügen, außer vielleicht der Überprüfung, ob der Fokus bei der Navigation mit der Tastatur sichtbar ist. Zwei relativ neue Technologien, die sich mit der Barrierefreiheit beschäftigen, sind jedoch interessanter.

Accessibility Insights ist eine Sammlung von Werkzeugen, die sowohl im Browser als auch im Rahmen des Build-/Testzyklus ausgeführt werden können, um Probleme zu identifizieren.
Die Überprüfung der Funktionalität von Screenreadern war eine besonders schwierige Aufgabe. Mit dem Zugriff auf Accessibility DOM, haben wir endlich die Möglichkeit erhalten, Aufnahmen der Anwendung aus der Sicht der Barrierefreiheit zu machen, die sehr ähnlich sind, wie wir sie für visuelle Tests erstellen, und wir prüfen sie auf Regression.

Im zweiten Teil der Geschichte haben wir uns also von der Bearbeitung von HTML-Code zu einem höheren Abstraktionsniveau bewegt, den Designentwicklungsprozess verändert und umfassende Tests eingeführt. Neue Prozesse, neue Technologien und neue Abstraktionsniveaus haben unser Verständnis von Barrierefreiheit und davon, was es bedeutet, in diesem Bereich zu arbeiten, vollständig verändert.
Doch das ist erst der Anfang.

Das nächste Verständnis besteht darin, dass blinde Benutzer bahnbrechende Technologien vorantreiben – sie profitieren nicht nur am meisten von den zuvor beschriebenen Änderungen, sondern auch von der Tatsache, dass neue Ansätze und Ideen durch ML/AI möglich werden. Zum Beispiel ermöglicht die Immersive Reader-Technologie den Nutzern, Texte einfacher und verständlicher zu erfassen. Sie kann laut vorgelesen werden, die Satzstruktur wird grammatikalisch aufgeteilt und sogar die Bedeutungen von Wörtern werden grafisch dargestellt. Das passt absolut nicht in das alte Verständnis von "Barrierefreiheit schaffen" – es ist eine Funktion der Benutzerfreundlichkeit, die allen helfen wird.

Mit ML/AI entstehen völlig neue Interaktions- und Arbeitsweisen, und wir freuen uns, Teil der nächsten Schritte auf diesem fortschrittlichen Weg zu sein. Innovationen erfordern einen Wandel im Denken – die Menschheit existiert seit Jahrtausenden, Maschinen seit Hunderten von Jahren, Websites seit mehreren Jahrzehnten und Smartphones noch weniger; Technologie muss sich den Menschen anpassen und nicht umgekehrt.

P.S. Der Artikel wurde mit geringfügigen Abweichungen vom Original übersetzt. Als Mitautor dieses Artikels habe ich diese Abweichungen mit Hugh abgestimmt.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.