Auf dem Weg zur Barrierefreiheit

Freitag ist Feierabend. Schlechte Nachrichten kommen immer am Ende des Arbeitstages am Freitag.

Sie sind dabei, das Büro zu verlassen, gerade ist ein neuer Brief über eine weitere Umstrukturierung mit der Post eingetroffen.

Danke xxxx, yyy ab heute wirst du zzzz berichten
...
Und Hughs Team wird dafür sorgen, dass unsere Produkte für Menschen mit Behinderungen zugänglich sind.

Oh nein! Warum habe ich das verdient? Wollen sie, dass ich gehe? Machen Sie sich bereit für undankbare harte Arbeit und den Versuch, die Fehler anderer Menschen zu korrigieren. Das ist definitiv ein Misserfolg...

Dies war die Verfügbarkeit vor einigen Jahren. Einige arme Seelen erhielten die Aufgabe, die Benutzeroberfläche „aufzuräumen“, um sie für Menschen mit Behinderungen zugänglich zu machen.

Was dies tatsächlich bedeutete, war ziemlich vage – wenn Sie vermutlich einen Fokusindikator sehen und durch die Felder scrollen könnten, etwas Alternativtext und ein paar Feldbeschreibungen hätten, würde man davon ausgehen, dass Ihre Anwendung barrierefrei ist ...

Doch plötzlich begannen sich die „Käfer“ mit Lawinengeschwindigkeit zu vermehren.

Verschiedene Screenreader (Engl. Screenreader) und Browser verhielten sich völlig unterschiedlich.

Benutzer haben sich darüber beschwert, dass die App unbrauchbar ist.

Sobald an einer Stelle ein Fehler behoben wurde, tauchte an einer anderen ein anderer auf.

Und allein das Ändern und Korrigieren von Fehlern in der Benutzeroberfläche erforderte Herkulesanstrengungen.

Ich war dort. Ich habe überlebt, aber wir hatten keinen „Erfolg“ – technisch gesehen haben wir viel aufgeräumt, viele Feldbeschreibungen und Rollen hinzugefügt und ein gewisses Maß an Compliance erreicht, aber niemand war zufrieden. Benutzer beschwerten sich immer noch darüber, dass sie nicht in der Anwendung navigieren konnten. Der Manager beklagte sich dennoch über die ständige Fehlerflut. Ingenieure beschwerten sich darüber, dass das Problem falsch gestellt worden sei und es keine klar definierte „richtige“ Lösung gebe, die in allen Fällen funktionieren würde.

Auf meinem Weg zum Verständnis der Barrierefreiheit gab es einige ausgesprochen augenöffnende Momente.
Das erste war vielleicht die Erkenntnis, dass es schwierig war, einem fertigen Produkt Barrierefreiheitsfunktionen hinzuzufügen. Und es ist noch schwieriger, Manager davon zu überzeugen, dass es unglaublich schwierig ist! Nein, es geht nicht nur um „ein paar Tags hinzufügen“, und die Benutzeroberfläche wird einwandfrei funktionieren. Nein, das kann nicht in drei Wochen erledigt werden, selbst drei Monate werden nicht ausreichen.
Der nächste Moment der Wahrheit kam, als ich aus erster Hand sah, wie blinde Benutzer unsere App tatsächlich nutzten. Das unterscheidet sich VIEL von der Betrachtung von Fehlermeldungen.

Ich werde immer wieder darauf zurückkommen, aber fast alle unsere „Annahmen“ darüber, wie die Leute unsere App nutzen, waren falsch.

Navigieren in einer komplexen Benutzeroberfläche mithilfe von Tastenanschlägen Tab/Shift+Tab – Das ist scheiße! Wir brauchen etwas Besseres. Tastaturkürzel, Kopfzeilen.

Den Fokus zu verlieren, wenn man die Benutzeroberfläche ändert, ist doch kein großes Problem, oder? Denken wir noch einmal darüber nach – das ist unglaublich verwirrend.

Ich machte weiter, arbeitete eine Weile an verschiedenen Projekten und dann starteten wir ein neues Projekt mit einer komplexen Benutzeroberfläche und einer klaren Installation, um dieses Mal endlich die Barrierefreiheit zu erreichen.

Also traten wir einen Schritt zurück und überlegten, wie wir dies anders und erfolgreich umsetzen und den Prozess weniger langweilig gestalten könnten!

Ziemlich schnell kamen wir zu einigen Schlussfolgerungen:

1. Wir wollten nicht, dass Leute, die die Benutzeroberfläche entwickeln, sich mit Arienbezeichnungen/-rollen und natürlich der HTML-Struktur der Komponenten herumschlagen. Wir mussten ihnen die richtigen Komponenten zur Verfügung stellen, die eine sofortige Zugänglichkeit ermöglichen.
2. Zugänglichkeit == Benutzerfreundlichkeit – d.h. Dies ist nicht nur eine technische Herausforderung. Wir mussten den gesamten Designprozess ändern und sicherstellen, dass die Barrierefreiheit berücksichtigt und besprochen wurde, bevor mit dem UI-Design begonnen wurde. Sie müssen frühzeitig darüber nachdenken, wie Benutzer die Funktionalität entdecken, wie sie navigieren und wie das Klicken mit der rechten Maustaste auf der Tastatur funktioniert. Barrierefreiheit sollte ein integraler Bestandteil des Designprozesses sein – für manche Benutzer ist sie weit mehr als nur das Erscheinungsbild der Anwendung.
3. Von Anfang an wollten wir Feedback von blinden und anderen behinderten Benutzern zur Benutzerfreundlichkeit der Anwendung einholen.
4. Wir brauchten wirklich gute Möglichkeiten, um Regressionen bei der Barrierefreiheit zu erkennen.

Nun, aus technischer Sicht klang der erste Teil recht unterhaltsam – die Entwicklung einer Architektur und die Implementierung einer Komponentenbibliothek. Und tatsächlich war es so.

Einen Schritt zurücktreten und schauen ARIA-Beispiele Und indem wir dies als Designproblem und nicht als „Einpassungsproblem“ betrachteten, führten wir einige Abstraktionen ein. Eine Komponente hat eine „Struktur“ (besteht aus HTML-Elementen) und ein „Verhalten“ (wie sie mit dem Benutzer interagiert). In den folgenden Ausschnitten haben wir beispielsweise eine einfache ungeordnete Liste. Durch das Hinzufügen von „Verhalten“ werden die entsprechenden Rollen zur Liste hinzugefügt, sodass sie sich wie eine Liste verhält. Dasselbe machen wir auch für das Menü.

Tatsächlich werden hier nicht nur Rollen hinzugefügt, sondern auch Event-Handler für die Tastaturnavigation.

Das sieht ordentlicher aus. Wenn wir eine saubere Trennung zwischen ihnen erreichen könnten, wäre es egal, wie die Struktur erstellt wurde, wir könnten Verhaltensweisen darauf anwenden und die Zugänglichkeit richtig gestalten.

Sie können dies in Aktion sehen unter https://stardust-ui.github.io/react/ – UX-Bibliothek Reagieren, das von Anfang an unter dem Gesichtspunkt der Barrierefreiheit konzipiert und umgesetzt wird.

Der zweite Teil – die Änderung des Ansatzes und der Prozesse rund um das Design – hat mir zunächst Angst gemacht: Der Versuch bescheidener Ingenieure, organisatorische Veränderungen durchzusetzen, endet nicht immer gut, aber es stellte sich heraus, dass es sich um einen der interessantesten Bereiche handelte, in denen wir wesentliche Beiträge zum Prozess geleistet haben . Kurz gesagt, unser Prozess war wie folgt: Neue Funktionen wurden von einem Team entwickelt, dann überprüfte/wiederholte unser Führungsteam den Vorschlag, und nach der Genehmigung wurde der Entwurf normalerweise an das Engineering-Team übergeben. In diesem Fall war das Technikteam praktisch „Eigentümer“ der Barrierefreiheitsfunktion, da es in seiner Verantwortung lag, alle damit verbundenen Probleme zu beheben.

Am Anfang 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 erfolgen musste, da es sonst zu großen Änderungen und Neudefinitionen einiger Rollen führen würde. Mit der Unterstützung des Managements und wichtiger Akteure haben wir die Idee jedoch aufgegriffen und in die Tat umgesetzt, sodass die Entwürfe auf Zugänglichkeit und Benutzerfreundlichkeit getestet wurden, bevor sie dem Management präsentiert wurden.

Und dieses Feedback war für alle äußerst wertvoll – es war eine fantastische Übung zum Wissensaustausch/ zur Kommunikation darüber, wie Benutzer mit Webanwendungen interagieren. Wir haben zahlreiche UI-Problembereiche identifiziert, bevor sie erstellt wurden. Die Entwicklungsteams verfügen jetzt über viel bessere Spezifikationen als nicht nicht nur visuelle, sondern auch verhaltensbezogene Aspekte des Designs. Echte Diskussionen sind unterhaltsame, energiegeladene und leidenschaftliche Diskussionen über technische Aspekte und Interaktionen.

Wir könnten dies sogar noch besser machen, wenn wir bei diesen (oder nachfolgenden) Treffen blinde und behinderte Benutzer hätten – das war schwer zu organisieren, aber wir arbeiten jetzt sowohl mit lokalen Blindenorganisationen als auch mit Unternehmen zusammen, die externe Tests anbieten, um den Ausführungsfluss frühzeitig zu überprüfen Entwicklung – sowohl auf Komponenten- als auch auf Ausführungsflussebene.

Ingenieure verfügen nun über ziemlich detaillierte Spezifikationen, verfügbare Komponenten, die sie zur Implementierung verwenden können, und eine Möglichkeit, den Ausführungsablauf zu validieren. Die Erfahrung hat uns zum Teil gelehrt, was uns die ganze Zeit über entgangen ist – wie wir den Rückschritt stoppen können. Ebenso können Menschen Integrations- oder End-to-End-Tests verwenden, um die Funktionalität zu testen, die wir benötigen, um Änderungen in Interaktionen und Ausführungsabläufen zu erkennen – sowohl visuell als auch verhaltensmäßig.

Die Bestimmung der visuellen Regression ist eine ziemlich definierte Aufgabe. Dem Prozess kann nur sehr wenig hinzugefügt werden, außer vielleicht zu überprüfen, ob der Fokus beim Navigieren mit der Tastatur sichtbar ist. Interessanter sind zwei relativ neue Technologien für die Arbeit mit Barrierefreiheit.

1. Einblicke in die Barrierefreiheit ist eine Reihe von Tools, die sowohl im Browser als auch als Teil des Build-/Testzyklus ausgeführt werden können, um Probleme zu identifizieren.
2. Die Überprüfung, ob Screenreader korrekt funktionieren, war eine besonders anspruchsvolle Aufgabe. Mit der Einführung des Zugangs zu Barrierefreiheit DOMsind wir nun endlich in der Lage, Schnappschüsse der Barrierefreiheit der App zu erstellen, ähnlich wie wir es bei visuellen Tests tun, und sie auf Regression zu testen.

Deshalb sind wir im zweiten Teil der Geschichte von der Bearbeitung des HTML-Codes zur Arbeit auf einer höheren Abstraktionsebene übergegangen, haben den Designentwicklungsprozess geändert und gründliche Tests eingeführt. Neue Prozesse, neue Technologien und neue Abstraktionsebenen haben die Landschaft der Zugänglichkeit und was es bedeutet, in diesem Bereich zu arbeiten, völlig verändert.
Aber das ist nur der Anfang.

Die nächste „Einsicht“ besteht darin, dass blinde Benutzer die Spitzentechnologie vorantreiben – sie sind diejenigen, die nicht nur am meisten von den zuvor beschriebenen Veränderungen profitieren, sondern auch davon, dass neue Ansätze und Ideen durch ML/KI ermöglicht werden. Mit der Immersive Reader-Technologie können Benutzer beispielsweise Texte einfacher und klarer präsentieren. Es kann vorgelesen werden, der Satzbau wird grammatikalisch aufgeschlüsselt und sogar Wortbedeutungen werden grafisch dargestellt. Das passt überhaupt nicht in die alte „Barrierefrei machen“-Mentalität – es ist eine Usability-Funktion, die jedem hilft.

ML/KI ermöglicht völlig neue Arten der Interaktion und Arbeit, und wir freuen uns, Teil der nächsten Etappen dieser innovativen Reise zu sein. Innovation wird durch ein Umdenken vorangetrieben – die Menschheit existiert seit Jahrtausenden, Maschinen seit Hunderten von Jahren, Websites seit mehreren Jahrzehnten und Smartphones noch weniger, Technologie muss sich an den Menschen anpassen und nicht umgekehrt.

PS: Der Artikel wurde mit geringfügigen Abweichungen vom Original übersetzt. Als Co-Autor dieses Artikels habe ich diese Abschweifungen mit Hugh vereinbart.

An der Umfrage können nur registrierte Benutzer teilnehmen. Einloggenbitte.

Achten Sie auf die Barrierefreiheit Ihrer Anwendungen?

• Ja

• Nein

• Dies ist das erste Mal, dass ich von App-Barrierefreiheit höre.

17 Benutzer haben abgestimmt. 5 Benutzer enthielten sich der Stimme.

Source: habr.com