Wie wir die Barrierefreiheitsprüfung verbessert haben

Zu Beginn unserer Reise in Richtung Barrierefreiheit haben wir Barrierefreiheitstests im Allgemeinen in zwei Kategorien unterteilt: automatisiert und manuell. Die erste Methode, um schnell algorithmisch erkennbare, leicht zu behebende Probleme zu finden, und die zweite für alles andere, was mehr Zeit und Aufmerksamkeit erforderte. Automatisierte Tests passen gut zu schnellen Prozessen wie der kontinuierlichen Integration (CI), während manuelle Tests eine sorgfältige Koordination mit qualifizierten Testern erforderten, um alles abzudecken, was automatisierte Tools nicht konnten.

Auf dem Weg dorthin haben wir festgestellt, dass es tatsächlich einen guten Kompromiss zwischen diesen beiden Ansätzen gibt. In Zusammenarbeit mit Assistiv Labs haben wir bessere Prozesse mit End-to-End-Service-Tests zu einem Test-Workflow kombiniert, der automatisierte und manuelle Tests neu definiert. Es ist etwas dazwischen, ein hybrider Ansatz, der die automatisierte Abdeckung drastisch erhöht und den manuellen Koordinationsaufwand reduziert.

Jetzt erkennen wir klare, leicht zu behebende Probleme innerhalb von Stunden statt Wochen. Unsere neuen Prozesse erkennen automatisch, was dringend ist, und leiten Probleme an die richtigen Teams weiter, die sie in der Regel innerhalb weniger Tage lösen.

Die Ergebnisse waren sowohl technischer als auch kultureller Natur. Wir geben Feedback zur Barrierefreiheit viel schneller, Teams beheben Fehler schneller, und Entwickler bei Asana haben begonnen, anders über Probleme mit der Barrierefreiheit nachzudenken.

Erstellung von Prozessen zur Priorisierung von Barrierefreiheitsfehlern

In einem Unternehmen der Größe von Asana ist ein starkes Priorisierungs-Framework, das durch Prozesse und Governance-Prinzipien unterstützt wird, unerlässlich. Teams müssen wissen, was wann in ihren Backlogs eingeplant werden muss und was gerade jetzt Aufmerksamkeit erfordert.

Aber es ist leicht zu unterschätzen, wie schwierig es ist, Barrierefreiheits-Bugs zu priorisieren. Die Priorität basiert auf einer schwindelerregenden Matrix einzigartiger Faktoren, darunter unterstützende Technologien, Browser, betroffene Nutzergruppen, Nutzerfeedback, Produktbereich, Schwierigkeitsgrad der Fehlerbehebung, Workarounds, WCAG-Konformität und historischer Kontext. Einige Fehler existieren möglicherweise schon lange, wurden aber erst kürzlich entdeckt. Andere treten mit neuen Funktionen auf. Und einige sind Regressionen – Funktionen, die früher barrierefrei waren, es aber jetzt nicht mehr sind.

Um ein Framework zu erstellen, haben wir formell verschiedene Arten von Barrierefreiheits-Bugs definiert, damit wir für jeden davon optimierte Workflows entwerfen konnten. Ein wesentlicher Schritt war die Definition, was eine Regression darstellt und was nicht.

Regression (Subst.)

Ein dokumentiertes (gibt es eine Aufzeichnung darüber, dass dies funktioniert hat, wie frühere Fehler, Kommentar-Threads, Screenshots oder Bildschirmaufnahmen?), reproduzierbares (kann ein Kolleg*in das Problem anhand der beschriebenen Schritte reproduzieren?) Problem, das zuvor funktioniert hat und jetzt nicht mehr funktioniert.

Regressionen können natürlich eine hohe Priorität erhalten – schließlich will niemand, dass die Barrierefreiheit wieder schlechter wird. Dies kann die Priorisierung in vielen Fällen erheblich vereinfachen.

Es gibt jedoch einen Haken. Regressionen werden durch Vorher-Nachher-Snapshots definiert. Ein Vorher-Snapshot könnte beispielsweise ein Video sein, in dem die Funktion noch funktioniert, und ein Nachher-Snapshot könnte ein Video sein, in dem ein neues problematisches Ergebnis zu sehen ist. Bugs haben natürlich „Danach“-Snapshots. Aber um die Vorher-Momentaufnahme zu finden, muss man in der Regel tief graben.

Ohne eine zuverlässige Quelle für Vorher-Snapshots lohnte es sich oft nicht, zu untersuchen, ob ein Fehler als Regression priorisiert werden konnte. An dieser Stelle erwies sich eine neue Art der Automatisierung als äußerst hilfreich.

End-to-End-Automatisierung der Barrierefreiheit

Vollautomatisierte Tests sind weder für Barrierefreiheitstests noch für Asana neu. In der Vergangenheit boten uns axe DevTools und jsx-a11y für React eine breite, horizontale Abdeckung. Aber sie sind oberflächlich. Wir waren der Meinung, dass die Token-Schätzung von 30 % für automatisierte Tests in der gesamten Branche ziemlich nahe an den WCAG-Kriterien lag, die wir erreichten. Die begrenzte Abdeckung bedeutete, dass manuelle Tests immer noch Fehler fanden, die automatisierte Tools übersehen hatten.

Wir brauchten Tools, die tiefer gehen konnten. Tools, die stärker auf unsere Nutzerforschung und unsere Governance-Prinzipien abgestimmt sind. Und genau das haben wir mit Assistiv gefunden. Tests für den End-to-End-Service von Assistiv werden von Assistiv-Entwicklern von Grund auf neu geschrieben, basierend auf den von uns bereitgestellten User-Flows und Testparametern. Die Suiten umfassen Tastenkombinationen, echte Bildschirmleser (Screenreader), Browser und maschinelles Sehen, das von der Assistiv Labs-Cloud unterstützt wird. Das Ergebnis ist mehr als eine Simulation, bei der Ereignisse auf die gleiche Weise an eine Maschine übertragen werden, wie es ein menschlicher Nutzer tun würde, wodurch die Abdeckung der WCAG und umfassenderer Barrierefreiheitsaspekte maximiert wird.

Die End-to-End-Automatisierung der Barrierefreiheit unterscheidet sich grundlegend von der herkömmlichen Automatisierung und interagiert mit Asana, um Aufgaben auf dieselbe Weise zu erledigen, wie es ein manueller Tester tun würde. Je nach Testszenario ist es möglich, bis zu 75 % der WCAG-Kriterien abzudecken. Und es gibt immer noch Experten mit kritischem Denken, die alles live überwachen. Mitarbeiter von Asana und Assistiv sind an der Entwicklung repräsentativer Benutzeraktionen und der Überprüfung der Ergebnisse beteiligt, wodurch die automatisierten Tests in Bezug auf Umfang, Häufigkeit und Genauigkeit drastisch verbessert werden.

Kräfte bündeln

Mit einem soliden Priorisierungs-Framework und einer neuen Automatisierung, die von der Suche nach einer Minderheit von Fehlern zur Suche nach der Mehrheit übergegangen ist, haben wir einen leistungsstarken Priorisierungs-Workflow implementiert.

Zunächst werden automatisierte Tests mit der bestehenden Engineering-Pipeline von Asana synchronisiert. Neue Probleme werden nahezu in Echtzeit erkannt und mit den Code-Änderungen korreliert, die sie wahrscheinlich verursacht haben.

Als Nächstes führt ein Entwickler von Assistiv eine Überprüfung durch, um falsche Positive herauszufiltern, und erstellt ein Problem im Backlog von Asana mit kontextualisierten Angaben zu den Auswirkungen auf die Nutzer und Anweisungen zur Behebung. Da automatisierte Tests kontinuierlich ausgeführt werden, ist ein Snapshot des vorherigen Zustands jederzeit verfügbar und Regressionen können leicht klassifiziert werden. Wir pflegen automatisierte Asana-Workflows, die das Problem an das richtige Team weiterleiten.

In der Praxis bedeutet dies, dass Regressionen in der Regel innerhalb von 24 Stunden nach einer Bereitstellung gemeldet und so dokumentiert werden, dass sie für Entwickler ohne Erfahrung im Bereich Barrierefreiheit leicht verständlich sind. Das ermöglicht es unserem Team für Barrierefreiheit, ein SLA für die Behebung von Regressionen festzulegen und die Produktteams damit zu beauftragen. Niemand muss argumentieren, welche Regression an erster, zweiter oder letzter Stelle steht. Es sind einfach Fehler, die Aufmerksamkeit erfordern.

Diese Dezentralisierung führt direkt zu einem nachhaltigeren Programm und zu inklusiveren Endnutzererlebnissen. Wir haben viel mehr Handlungsfreiheit und Einfluss, viel Raum für Kreativität, weil wir nicht ständig Probleme beheben müssen. Und das bedeutet wiederum, dass wir zufriedener und effektiver sind.

Der ROI schnellerer Feedbackschleifen

Ein Fehler, der wochen- oder monatelang unentdeckt bleibt, ist teuer in der Behebung. Jemand muss ihn dem zuständigen Team zuweisen und sicherstellen, dass er priorisiert wird. Der Entwickler, dem er zugewiesen wird, ist wahrscheinlich nicht derselbe Entwickler, der ihn verursacht hat. Selbst wenn dies der Fall ist, ist es schwierig, den in Vergessenheit geratenen Kontext wieder auszugraben, umzuschalten oder sich mit anderen Teams abzustimmen, um die technischen Schulden zu beseitigen, die in den vergangenen Wochen und Monaten entstanden sind.

Eine viel zitierte IBM-Studie hat das Problem in Zahlen gefasst und festgestellt, dass es 30-mal mehr kostet, Fehler in der Produktion zu entdecken, als solche, die während der Designphase gefunden werden. Das klingt plausibel.

Wenn Entwickler morgens ein Update bereitstellen, werden normalerweise noch vor dem Ende des Arbeitstages erste Anzeichen für Regressionen auftauchen. Die Feedbackschleife ist so kurz, dass unsere End-to-End-Tests uns bei mehreren Gelegenheiten als Erste auf generische UI-Fehler aufmerksam gemacht haben, die nicht auf Bildschirmleser oder Tastaturnavigation beschränkt waren.

Als die Entwickler begannen, schnelleres Feedback aus End-to-End-Tests zu erhalten, stellten wir fest, dass der kognitive Aufwand für die Priorisierung geringer wurde. Die Unklarheiten waren verschwunden. Entwickler dachten: „Ich bin dafür verantwortlich, weil ich es heute Morgen ausgeliefert habe. Gestern hat es funktioniert und heute funktioniert es nicht mehr. Ich muss es jetzt beheben.“ Das Beheben von Barrierefreiheitsfehlern wird wie ein Muskelgedächtnis.

Bei Asana sind Barrierefreiheits-Bugs einfach nur Bugs. Und sie werden behoben.

Eine bessere Möglichkeit, die Barrierefreiheit zu automatisieren

Bevor wir End-to-End-Barrierefreiheitstests eingeführt haben, hat unser Barrierefreiheitsteam bereits erhebliche Fortschritte gemacht. Auf der operativen Seite verfügten Design- und Entwicklungsteams über dokumentierte Überprüfungsprozesse, Regressionsdefinitionen und SLAs. Beim Testen gab es automatisierte Lösungen für schnelle, aber oberflächliche Berichte und manuelle Qualitätssicherung für gründliche, aber zeitaufwändige Audits.

Mit End-to-End haben wir eine technische Lösung, die den bestehenden Aufwand ergänzt und darüber hinausgeht. Regressionen werden früher, detaillierter und mit mehr Nachweisen dokumentiert. Praktisch niemand verschwendet Zeit mit Fehlerberichten, die nicht umsetzbar oder reproduzierbar sind.

Jetzt haben wir einen klaren Überblick darüber, welche Fehler neu und welche alt sind, welche User-Flows sie betreffen und wer für die Behebung verantwortlich ist. Wir können der Zeit voraus sein und uns auf unsere Vision für die Barrierefreiheit von Asana in der Zukunft konzentrieren.

Über die Autoren:  Cameron Cundiff (Technical Lead) und Jiaxin Zheng (Technical Program Manager) sind beide Mitglieder der Development Lifecycle-Gruppe, die sich der Bereitstellung von Tools widmet, mit denen Entwickler Ideen schnell, zuverlässig und ansprechend in die Produktion bringen können.