🥇Auf dem Weg zur Barrierefreiheit

Freitag – das Ende des Arbeitstags. Schlechte Nachrichten kommen immer freitags zum Ende des Arbeitstags.

Sie sind dabei, das Büro zu verlassen, und plötzlich kommt eine neue E-Mail über eine weitere Umstrukturierung.

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

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

So war die Zugänglichkeit vor ein paar Jahren. Einige Unglückliche bekamen die Aufgabe, die Benutzeroberfläche "aufzuräumen", um sie für Menschen mit Behinderungen zugänglicher zu machen.

Was das tatsächlich bedeutete, war ziemlich vage – wahrscheinlich, wenn man den Fokusindikator sehen konnte und mit der Tabulatortaste durch die Felder navigieren konnte, und wenn es irgendeinen alternativen Text und ein paar Beschreibungen für die Felder gab, wurde das als Zugänglichkeit der Anwendung betrachtet …

Aber plötzlich begannen die "Bugs" wie eine Lawine zu sprießen.

Verschiedene Bildschirmlesegeräte (engl. Screen Readers) und Browser verhielten sich völlig unterschiedlich.

Benutzer klagten darüber, dass die Anwendung unbrauchbar war.

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

Die bloße Änderung und Korrektur von Benutzeroberflächenfehlern erforderte titanische Anstrengungen.

Ich war dort. Ich habe überlebt, aber wir haben nicht ‹erfolgreich› abgeschnitten – technisch haben wir viel bereinigt, viele Beschreibungen für Felder hinzugefügt, Rollen und einen gewissen Grad 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 den ständigen Fehlerfluss. Die Ingenieure beklagten sich über die ungenaue Aufgabenstellung, ohne eine klar definierte ‹richtige› Lösung, die in allen Fällen funktioniert hätte.

Auf meinem Weg zum Verständnis der Zugänglichkeit gab es einige offensichtlich aufschlussreiche Momente.
Es war vielleicht das erste Verständnis, dass es schwierig ist, Barrierefreiheit über ein vorhandenes Produkt zu addieren. Und noch schwieriger ist es, die Manager davon zu überzeugen, dass es unglaublich komplex ist! Es ist nicht einfach, "einige Tags hinzuzufügen" und der Benutzeroberfläche wird perfekt funktionieren. Nein, es ist unmöglich, das in drei Wochen abzuschließen, selbst drei Monate sind nicht genug.
Mein nächster Wendepunkt kam, als ich tatsächlich sah, wie blinde Benutzer unsere Anwendung verwenden. Das unterscheidet sich SO sehr vom bloßen Überfliegen von Fehlermeldungen.

Ich werde immer wieder darauf zurückkommen, aber fast all unsere „Annahmen“ darüber, wie Menschen unsere Anwendung genutzt haben, waren falsch.

Navigation durch eine komplexe Benutzeroberfläche mit Tasten Tab/Shift+Tab ist einfach frustrierend! Da muss es etwas Besseres geben: Tastenkombinationen, Überschriften.

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

Ich habe eine Zeitlang an verschiedenen Projekten gearbeitet, bevor wir ein neues Projekt gestartet haben, mit einer komplexen Benutzeroberfläche und klaren Vorgaben, um diesmal die richtige Barrierefreiheit zu gewährleisten.

Also haben wir einen Schritt zurück gemacht und überlegt, wie wir das anders umsetzen und erfolgreich sein können, damit der Arbeitsprozess nicht langweilig ist!

Relativ schnell sind wir zu einigen Ergebnissen gekommen:

Wir wollten nicht, dass die Leute, die die Benutzeroberfläche entwickeln, mit aria-Beschriftungen/Rollen und der HTML-Struktur der Komponenten herumschlagen. Wir mussten sie mit den richtigen Komponenten versorgen, in denen die Barrierefreiheit direkt ab Werk implementiert ist.
Zugänglichkeit == Benutzerfreundlichkeit – das heißt, es ist nicht nur eine technische Aufgabe. Wir mussten den gesamten Designprozess überdenken und sicherstellen, dass die Zugänglichkeit berücksichtigt und diskutiert wird, bevor das Design der Benutzeroberfläche beginnt. Es ist notwendig, zunächst darüber nachzudenken, wie Benutzer eine Funktionalität entdecken können, wie sie sich bewegen und wie das "Rechtsklicken" von der Tastatur funktionieren wird. Zugänglichkeit sollte ein integraler Bestandteil des Designprozesses sein – für einige Benutzer ist es weit mehr als nur das Aussehen der Anwendung.
Von Anfang an wollten wir Feedback von blinden und anderen Benutzern mit Einschränkungen zur Benutzerfreundlichkeit der Anwendung erhalten.
Wir benötigten wirklich gute Möglichkeiten, um Regressionen in der Zugänglichkeit zu erfassen.

Nun, aus ingenieurtechnischer Sicht klang der erste Teil ziemlich unterhaltsam – die Entwicklung der Architektur und die Implementierung der Komponentenbibliothek. Und das war es auch wirklich.

Wenn man einen Schritt zurücktritt und betrachtet Beispiele für ARIA Und indem wir dies als ein Designproblem und nicht als ein 'Anpassungs'-Problem betrachten, haben wir einige Abstraktionen eingeführt. Die Komponente hat eine ‚Struktur‘ (bestehend aus HTML-Elementen) und ein ‚Verhalten‘ (wie sie mit dem Benutzer interagiert). Zum Beispiel haben wir in den folgenden Fragmenten eine einfache ungeordnete Liste. Wenn wir ‚Verhalten‘ zur Liste hinzufügen, werden die entsprechenden Rollen hinzugefügt, damit sie als Liste fungiert. Das Gleiche machen wir für das Menü.

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

Das sieht bereits viel ordentlicher aus. Wenn wir eine klare Trennung zwischen ihnen erreichen könnten, wäre es nicht wichtig, wie die Struktur erstellt wurde; wir könnten Verhaltensweisen (Behaviours) darauf anwenden und die richtige Zugänglichkeit erhalten.

In Aktion kann dies unter https://stardust-ui.github.io/react/ – der UX-Bibliothek React, die von Anfang an mit Blick auf die Zugänglichkeit gestaltet und implementiert wird, gesehen werden.

Der zweite Teil – die Veränderung der Herangehensweise und der Prozesse rund um das Design – hat mich anfangs eingeschüchtert: bescheidene Ingenieure, die versuchen, organisatorische Veränderungen voranzutreiben, enden nicht immer gut, aber es stellte sich als eines der interessantesten Gebiete heraus, in dem wir einen bedeutenden Beitrag zum Prozess geleistet haben. Kurz gesagt, wir hatten den folgenden Prozess: Neue Funktionen wurden von einem Team entwickelt, danach analysierte und iterierte unsere Gruppe von Führungskräften das Angebot. Nach der Genehmigung wurde das Design in der Regel an das Ingenieurteam übergeben. In diesem Fall hatte das Ingenieurteam tatsächlich die „Verantwortung“ für die Zugänglichkeitsfunktionen, da es alle damit verbundenen Probleme beheben musste.

Anfangs war es ziemlich schwierig, zu erklären, dass Zugänglichkeit und Benutzerfreundlichkeit untrennbar miteinander verbunden sind und dass dies bereits in der Entwurfsphase berücksichtigt werden muss, da sonst erhebliche Änderungen und Neudefinitionen einiger Rollen erforderlich wären. Dennoch haben wir mit Unterstützung des Managements und wichtiger Akteure diese Idee vermittelt und dafür gesorgt, dass die Designs auf Zugänglichkeit und Benutzerfreundlichkeit geprüft werden, bevor sie dem Management präsentiert werden.

Das Feedback war für alle äußerst wertvoll – es war fantastisch, wie eine Übung im Wissensaustausch / in der Informationsweitergabe darüber, wie Benutzer mit Webanwendungen interagieren. So konnten wir zahlreiche Problembereiche der Benutzeroberfläche identifizieren, noch bevor sie umgesetzt wurden. Die Entwicklerteams haben jetzt viel bessere Spezifikationen, nicht nur für die visuellen, sondern auch für die verhaltensbezogenen Aspekte des Designs. Echte Diskussionen sind lebhafte, energiegeladene und leidenschaftliche Debatten über technische Aspekte und Interaktionen.

Wir könnten diese Arbeit noch besser machen, wenn blinde Nutzer und Menschen mit Behinderungen an diesen (oder zukünftigen) Treffen mit uns teilnehmen würden. Das war schwer zu organisieren, aber inzwischen arbeiten wir tatsächlich sowohl mit lokalen Organisationen für Blinde als auch mit Unternehmen zusammen, die externes Testing anbieten, um die Benutzererfahrung in den frühen Entwicklungsphasen zu überprüfen – sowohl auf Komponenten- als auch auf Prozessebene.

Jetzt haben die Ingenieure recht detaillierte Spezifikationen und verfügbare Komponenten, die sie für die Implementierung nutzen können, sowie eine Möglichkeit, den Ablauf zu überprüfen. Teilweise hat uns die Erfahrung gelehrt, was wir ständig ü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 den Interaktionen und Abläufen zu erkennen – sowohl visuell als auch verhaltensbezogen.

Die Definition von visueller Regression ist eine ziemlich spezifische Aufgabe, und es kann nur sehr wenig zu diesem Prozess hinzugefügt werden, außer möglicherweise zu überprüfen, ob der Fokus beim Navigieren mit der Tastatur sichtbar ist. Zwei relativ neue Technologien zur Arbeit mit Barrierefreiheit sind jedoch interessanter.

Accessibility Insights ist ein Set 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 anspruchsvolle Aufgabe. Mit dem Zugang zu Accessibility DOM, haben wir endlich die Möglichkeit, App-Screenshots aus der Sicht der Barrierefreiheit zu erstellen, sehr ähnlich wie bei visuellen Tests, und diese auf Regressionen zu überprüfen.

In der zweiten Phase der Geschichte sind wir also von der Bearbeitung des HTML-Codes zur Arbeit auf einer höheren Abstraktionsebene übergegangen, haben den Designentwicklungsprozess verändert und strenge Tests eingeführt. Neue Prozesse, neue Technologien und neue Abstraktionsniveaus haben das Verständnis von Barrierefreiheit und dessen, was es bedeutet, in diesem Bereich zu arbeiten, vollständig verändert.
Aber das ist erst der Anfang.

Das nächste „Verständnis“ besteht darin, dass sehbehinderte Benutzer moderne Technologien vorantreiben – sie profitieren nicht nur von den zuvor beschriebenen Veränderungen, sondern auch von neuen Ansätzen und Ideen, die durch ML/AI möglich werden. Zum Beispiel ermöglicht die Technologie Immersive Reader den Benutzern, Texte einfacher und klarer darzustellen. Der Text kann laut vorgelesen werden, die Satzstruktur wird grammatikalisch aufgeteilt und sogar die Bedeutungen von Wörtern werden grafisch angezeigt. Dies passt überhaupt nicht in das alte Verständnis von „Zugänglichkeit“ – es ist eine benutzerfreundliche Funktion, die allen helfen wird.

Mit ML/AI entstehen völlig neue Wege der Interaktion und Arbeit, und wir freuen uns, Teil der nächsten Schritte auf diesem innovativen Weg zu sein. Innovationen sind das Ergebnis eines Perspektivwechsels – die Menschheit existiert seit Jahrtausenden, Maschinen seit Hunderten von Jahren, Websites seit einigen Jahrzehnten und Smartphones noch weniger; Technologie muss sich an die Menschen anpassen und nicht umgekehrt.

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

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte melden Sie sich an.Sind Sie an Contour interessiert?