Wie ein Zweierteam ein Barrierefreiheitsprogramm ins Leben rief

Einleitung

In diesem gemeinsam verfassten Blogbeitrag berichten Alexis Lucio und Sim K Sidhu darüber, wie sie bei Splunk ein Programm zur Barrierefreiheit ins Leben gerufen haben. Splunk verwandelt Daten in Handlungen – mit der „Data-To-Everything“-Plattform, die darauf ausgelegt ist, Daten in jedem Umfang zu untersuchen, zu überwachen, zu analysieren und darauf zu reagieren. Angesichts des Leitbilds von Splunk, „Maschinendaten für alle zugänglich, nutzbar und wertvoll zu machen“, könnte man meinen, dass die Umsetzung von Best Practices im Bereich Barrierefreiheit (a11y) einfach ist; doch wie jeder Barrierefreiheitsexperte weiß, ist das nicht immer der Fall.

In diesem Blogbeitrag werden sie ihre Erfahrungen beim Aufbau eines Teams für Barrierefreiheit teilen, insbesondere in folgenden Bereichen:

Was tun, wenn Ihr Team noch nicht das Niveau eines erfahrenen Fachmitarbeiters erreicht hat,
Was ist zu tun, wenn man in einem Unternehmen arbeitet, das eher technikorientiert ist, im Gegensatz zu einem design- oder nutzerorientierten Unternehmen, und
Was ist zu tun, wenn man in einem mittelständischen B2B-Unternehmen tätig ist – im Gegensatz zu einem Direct-to-Consumer-Unternehmen?

Am Anfang: Ein Barrierefreiheitsteam aus einer Person

Sim berichtet über ihre Erfahrungen als erste Fachexpertin für Barrierefreiheit (SME) bei Splunk.

Sim: Als ich bei Splunk anfing, war mir die Produktfamilie noch nicht bekannt und ich hatte das Produkt noch nie verwendet. Ich musste nicht nur den Umgang damit erlernen, sondern auch einen Barrierefreiheitsplan dafür erstellen. Unter Verwendung von Tools, mit denen ich bereits vertraut war, wie JIRA und Confluence, habe ich bestehende Testfälle ausgewertet und anschließend Tests für die gesamte Produktfamilie durchgeführt. Durch diesen Prozess erhielt ich einen umfassenden Bericht zur Barrierefreiheitsanalyse des Produkts.

Nach Durchsicht dieses Berichts wurde mir klar, dass diese Testfälle zwar im Hinblick auf die Funktionsprüfung hervorragend aussahen, es ihnen jedoch an den Grundlagen der Barrierefreiheit fehlte, wie beispielsweise den WCAG-Best-Practices. Ich begann daraufhin damit, die WCAG 2.1-Erfolgskriterien in die Testfälle zu integrieren, um sie für alle zukünftigen Testanforderungen und -zwecke nutzbar zu machen. Über JIRA konnte ich außerdem Statusberichte für alle bestehenden offenen JIRA-Fehler abrufen, was mir dabei half zu analysieren, inwiefern bei den meisten dieser Fehler die Anforderungen an die Barrierefreiheit nicht erfüllt waren. Anschließend habe ich die Schweregrade der bestehenden Fehler gründlich überprüft und die Schweregrade nach Bedarf zugewiesen oder angepasst. Zuletzt habe ich beschlossen, die verfügbaren „Voluntary Product Accessibility Templates“ (VPATs) für unsere Produkte zu überprüfen, um den aktuellen Konformitätsgrad der Produkte besser einschätzen zu können und Änderungen für die Vorlage vorzuschlagen.

Während ich an all diesen Dingen arbeitete, hörte ich, dass das Designteam vorhatte, einen Vollzeit-Barrierefreiheits-Designer einzustellen. Ich kann Ihnen gar nicht sagen, wie begeistert ich über diese Nachricht war – während meiner Zeit im QA-Team hatte ich ja noch keine Gelegenheit gehabt, regelmäßig mit einem Designer zusammenzuarbeiten.

Barrierefreiheit ausweiten: Mitarbeiter schulen und ein Netzwerk aufbauen

Alexis, die zuvor als UX-Designerin bei Splunk tätig war, bietet sich eine neue Chance.

Alexis: Im September 2019 bat mich mein Designleiter in einen Konferenzraum, wo er mir folgende Frage stellte: „Wie würdest du Diversity und Inklusion über Hautfarbe, Geschlecht und sexuelle Orientierung hinaus betrachten?“ Er sagte, er habe meine Arbeit in Mitarbeiter-Ressourcengruppen (ERGs) sowie meine Vorträge zu den Themen Diversity, Gerechtigkeit und Inklusion gesehen und sei aufgrund dessen der Meinung, dass ich perfekt für die Rolle als Accessibility-Designer geeignet sei. Ich antwortete mit „Na klar!“ und begann, mich auf diese Aufgabe vorzubereiten. Im Februar 2020 wurde aus unserem Ein-Personen-Team ein Zweierteam. Für uns als einzelne Mitarbeiter war es entscheidend, unsere Arbeit zu skalieren: Wie konnten wir uns in einem Unternehmen mit 6.000 Mitarbeitern für Barrierefreiheit einsetzen, geschweige denn das Bewusstsein dafür schärfen, dass nun zwei Personen da waren, um bewährte Verfahren und Maßnahmen zur Barrierefreiheit zu unterstützen?

Wir beschlossen, bei der Interessenvertretung einen zweigleisigen Ansatz zu verfolgen: Während wir gemeinsam an der Strategie und am Benchmarking arbeiteten, konzentrierten Sim und ich uns auch auf unsere jeweiligen Einflussbereiche. Auf der Designseite wusste ich, dass es wichtig war, mich als „Fachexpertin für Barrierefreiheit“ weiterzubilden und diese Informationen in einer leicht verständlichen Form an den Rest meiner Organisation weiterzugeben. Ich startete die „A11y Hour“, eine monatliche Veranstaltungsreihe zu allen möglichen Themen rund um Barrierefreiheit. Anfangs wurden die Themen von Sim und mir vorgegeben. Später stellten wir fest, dass das Interesse groß genug war, um auch Wünsche aus dem Publikum aufzunehmen. Im Bereich Qualitätssicherung nutzte Sim die von mir erstellten Schulungsmaterialien, um zu verdeutlichen, wie wichtig SLAs und ein Behebungsprozess für Ingenieure sind. Wir betonten außerdem, dass unsere Kunden – mehr noch als wir selbst – Bedenken hinsichtlich der Barrierefreiheit äußerten, da die meisten B2B-Unternehmen vor dem Kauf die Konformität eines Produkts analysieren müssen.

Vor allem aber hat unser Zweierteam bei Splunk den Grundstein dafür gelegt, dass Barrierefreiheit im Web als gemeinsame Verantwortung von Designern und Entwicklern angesehen wird – ein Aspekt, der bisher vernachlässigt worden war.

Messung und Benchmarking

Sim: Während wir unsere täglichen Aufgaben erledigten, legten wir gleichzeitig den Grundstein für das Programm zur Barrierefreiheit im Web bei Splunk – sowohl für derzeitige als auch für zukünftige Mitarbeiter. Nach ersten Recherchen hatten wir noch viele offene Fragen, wie zum Beispiel:

Wie viele Tickets zum Thema Barrierefreiheit haben wir? Wie war das Verhältnis zwischen der Anzahl der geschlossenen und der neu eröffneten a11y-Tickets?
Welchen portfolioweiten Maßstab könnten wir für a11y festlegen? Splunk verfügt über fast 10 Kernprodukte und hat in den letzten Jahren zahlreiche Unternehmen übernommen, weshalb diese Frage schwer zu beantworten ist.
Wurden vor unserer Zeit bereits Maßnahmen zur Barrierefreiheit durchgeführt? Falls ja, wer war daran beteiligt und wie wurde der Umfang festgelegt? Wir kannten zwar den Hintergrund bei einigen unserer Produkte, aber es gab immer noch zu viele, bei denen wir uns nicht sicher waren.
Welche Kunden, wenn überhaupt, haben wir in der Vergangenheit aufgrund der Nichteinhaltung von Barrierefreiheitsvorschriften verloren?
Wie viel Prozent unserer Zeit sollten wir in einen proaktiven Ansatz im Vergleich zu einem reaktiven Ansatz im Bereich Barrierefreiheit investieren?

Im Rahmen unserer Suche standen wir mit verschiedenen Teams und funktionsübergreifenden Partnern in Kontakt, was uns dabei half, ein Netzwerk innerhalb von Splunk aufzubauen und Verbündete für Barrierefreiheit innerhalb des Unternehmens zu gewinnen.

Aufbau eines internen Netzwerks von Verbündeten für Barrierefreiheit

Alexis: Ein einzigartiger Aspekt unserer Reise waren die Employee Resource Groups (ERGs) von Splunk, die auch als Business Resource Group (BRG) oder Affinitätsgruppe bezeichnet werden. Ich hatte ein Jahr lang die Latinx-Employee-Resource-Group mitgeleitet und kannte die Co-Leiter von „disabled=true“, einer ERG, die sich dafür einsetzt, ein inklusives und barrierefreies Umfeld für aktuelle und zukünftige Splunker zu schaffen, die eine Behinderung haben oder unter chronischen Erkrankungen oder Schmerzen leiden. Im Juni 2020 fanden im Rahmen der ERGs Gesprächsrunden mit der Unternehmensleitung statt. Da wir mit „disabled=true“ zusammengearbeitet hatten, um die Perspektive von Nutzern mit Behinderungen besser zu verstehen, wurden wir zu deren Gesprächsrunde eingeladen. In der Liste der Vorschläge sahen wir unter anderem die Forderung nach mehr Personal für unser a11y-Team. Darüber hinaus gab uns die ERG die Möglichkeit, offen über die Herausforderungen zu sprechen, mit denen wir nicht nur aus personeller und kultureller Perspektive in Bezug auf Barrierefreiheit, sondern auch bei Programmen und Abläufen zu kämpfen hatten.

Einer der Führungskräfte, die an der Telefonkonferenz teilnahmen, war der Senior Vice President of Engineering, und nach der Konferenz bat er uns, an der Sitzung seines Führungsteams teilzunehmen und dort einen Vortrag über die Bedeutung der Barrierefreiheit zu halten. Es dauerte eine Weile, bis wir den anfänglichen Schock überwunden hatten, aber danach war uns klar, dass dies eine perfekte Gelegenheit war, die wir uns nicht entgehen lassen durften.

Argumente für die Umsetzung von Barrierefreiheit gegenüber Führungskräften

Sim: In den folgenden sechs Wochen erstellten wir eine Präsentation und holten Feedback aus unserem Netzwerk interner Barrierefreiheits-Beauftragter ein. Uns war es wichtig, den Business Case für Barrierefreiheit auf unsere Zielgruppe zuzuschneiden. Als Designerin fällt es Alexis ziemlich leicht, andere Designer davon zu überzeugen, dass Barrierefreiheit das Richtige ist; und wir wussten, dass dies nicht die einzige Perspektive sein konnte, mit der wir unsere Führungskräfte ansprechen konnten. Im Rahmen eines Brainstormings mit unseren Befürwortern haben wir unsere Philosophie erweitert: Wir müssen Barrierefreiheit als etwas betrachten, das wir praktizieren, um rechtliche Risiken zu verringern, mehr Aufträge zu gewinnen (insbesondere als B2B-Unternehmen unter Berücksichtigung der Bundesbeschaffungsvorschriften) und – wenn sie über den gesamten Produktentwicklungszyklus hinweg umgesetzt wird – deutlich weniger Kosten verursacht als die Behebung von Fehlern nach der Markteinführung.

Gleichzeitig hat uns unser Netzwerk aus Barrierefreiheits-Befürwortern mit Beispielen für bewährte Praktiken im Bereich Barrierefreiheit dazu angespornt, uns noch mehr anzustrengen. Ja, wir hätten Unternehmen wie Apple, Google, Airbnb und Salesforce hervorheben können; doch einige dieser Unternehmen waren nicht einmal in unserer Branche tätig, geschweige denn Wettbewerber. Dank dieses Feedbacks fanden wir konkrete Beispiele bei Wettbewerbern und zumindest bei Produkten auf demselben Markt.

Das letzte Feedback unserer Teamkollegen lautete: „Zeigen, nicht erzählen“ – das heißt, die Demonstration einer Benutzererfahrung mit assistiver Technologie sei weitaus effektiver, als nur darüber zu sprechen. In diesem Fall erinnerten wir uns an einen Vertriebsingenieur, mit dem wir kürzlich im Zusammenhang mit einem öffentlich zugänglichen COVID-19-Dashboard zusammengearbeitet hatten und der uns auch einen Geldwert für das Geschäft genannt hatte, der bei unserem Publikum Anklang finden würde. Ich schlug vor, den Bildschirm abzudunkeln und JAWS auf dem Dashboard zu verwenden. Indem wir die Benutzeroberfläche ausblendeten, war unser Publikum gezwungen, genau dieselbe Erfahrung zu hören, die Screenreader-Nutzer machen würden, anstatt sich auf ihr Sehvermögen zu verlassen. Wir erstellten noch einige weitere Beispiele nach diesem Prinzip und konzentrierten uns dabei auf besonders auffällige und häufig genutzte Seiten.

Schließlich war es dann im August soweit – und wir erhielten großartiges Feedback! Die Führungskräfte luden uns ein, zwei Wochen später mit unserer Lückenanalyse und einem Vorschlag zur Gestaltung eines Programms wiederzukommen. Danach mussten wir uns ernsthaft Gedanken darüber machen, wie wir Barrierefreiheit nicht nur zu einer Checkliste oder einem Projekt, sondern zu einem Programm machen wollten.

Aufbau eines Barrierefreiheitsprogramms mit einem Zweierteam

Alexis: Vor unserer Präsentation haben wir an Fahrt gewonnen, indem wir Teams angesprochen und um eine Zusammenarbeit gebeten haben; plötzlich hatte sich die Situation umgekehrt: Die Teams nahmen Kontakt zu uns auf und wollten so schnell wie möglich mit uns zusammenarbeiten. Uns wurde schnell klar, dass wir einen Prozess zur Erfassung dieser Anfragen entwickeln mussten, und so erstellten wir ein A11y-Team-Anfrageformular, in dem die Teams beschreiben konnten, in welcher Form sie uns benötigten, welche Fristen anstanden und ob es sich um ein Kundenproblem handelte oder nicht. Dieses Formular sammelte auch quantitative Daten, sodass wir im Laufe der Zeit Trends erkennen und den Bedarf innerhalb unserer eigenen Organisation ermitteln konnten.

Auch der Austausch von Wissen zum Thema Barrierefreiheit gewann enorm an Bedeutung, da zwei Personen bei über 6.000 Mitarbeitern nicht skalierbar sind. Als Reaktion darauf haben wir auf dem Slack-Kanal unseres Unternehmens den Hashtag #a11y-questions eingerichtet. Anstatt immer wieder dieselben Fragen zu beantworten, die uns direkt per Nachricht zugeschickt wurden, konnten wir nun im Rahmen unserer FAQ eine gut sichtbare Antwort für alle Beteiligten anheften.

Während wir unseren plötzlichen Erfolg bewältigten, stellten wir fest, dass die von uns aufgebauten grundlegenden Ressourcen es uns ermöglichten, das Bewusstsein für Barrierefreiheit weiter zu verbreiten. So wurde beispielsweise die Präsentation, die wir für Führungskräfte erstellt hatten, auch in den Einführungs-Bootcamps für neue Mitarbeiter im technischen Bereich eingesetzt. Diese Einführungsmaßnahme stellt sicher, dass jeder Mitarbeiter von Anfang an zumindest ein grundlegendes Verständnis davon hat, was Barrierefreiheit ist und warum sie für Splunk wichtig ist. Der größte Erfolg war jedoch, dass wir Teilzeit-Ressourcen von anderen Splunk-Mitarbeitern gewinnen konnten, um ein wöchentliches Treffen des Kernteams für Barrierefreiheit durchzuführen. Gemeinsam erstellten wir die seit Langem benötigte Dokumentation, darunter eine Confluence-Seite zum Thema Barrierefreiheit. Diese Seite enthält laufende und intern veröffentlichte Ausschreibungen (RFPs), VPATs, Benchmarks für verschiedene Produktsuiten sowie vierteljährliche Ziele und Schlüsselergebnisse (OKRs) unseres Teams, die mit den OKRs des gesamten Unternehmens verknüpft sind. Schließlich werden auf dieser Seite auch Statistiken zu JIRA-Tickets gesammelt, sodass wir den Fortschritt bei der Behebung von Mängeln im Zeitverlauf verfolgen, erkennen können, welche Komponenten zuerst angegangen werden müssen, und weitere Anforderungen ermitteln können.

„Shift-Left“-Ansatz für Barrierefreiheit

Sim: Nachdem wir nun seit über einem Jahr als Team zusammengearbeitet hatten, konnten wir endlich die Früchte eines „Shift-Left“-Ansatzes bei der Barrierefreiheit ernten. Zuvor habe ich Produkte vor der Veröffentlichung getestet und Fehler protokolliert, wodurch den Entwicklern kaum oder gar keine Zeit blieb, die gemeldeten Probleme zu beheben. Da wir nun Alexis als Expertin für barrierefreies Design (a11y) im Team haben, werden viele a11y-Fehler bereits in der Designphase erkannt, was meine Arbeit im weiteren Verlauf erleichtert. Darüber hinaus bot uns die Einbindung von a11y-Ressourcen bereits in einer früheren Phase des Produktentwicklungszyklus die Möglichkeit, mit Kunden, Vertriebsingenieuren und unserem Außendienstteam zusammenzuarbeiten, um die dringendsten Probleme zu ermitteln.

Durch die Verlagerung nach links konnten wir vor allem gemeinsam mit den Produktteams einen proaktiveren Ansatz in Sachen Barrierefreiheit verfolgen, anstatt uns rein auf die Behebung von Mängeln zu beschränken. Und so unterstützen wir unsere Produktteams mit einem proaktiveren Ansatz:

Veröffentlichen Sie eine Dokumentation zum Designsystem, die Best Practices zur Barrierefreiheit sowie eine komponentenbasierte Dokumentation enthält, falls ein Entwickler die Komponente anpassen muss.
Ein „Designer-A11y-Toolkit“ erstellen, das Checklisten für gängige Arbeitsabläufe sowie nicht-technische Ressourcen für Designer enthält (Ein großes Dankeschön an unsere Design-Praktikantin Angela, die gemeinsam mit Alexis daran gearbeitet hat, dies zu verwirklichen!)
Integrieren Sie bewährte Verfahren zur Barrierefreiheit in die Abnahmekriterien für Produktanforderungen, damit es nicht Aufgabe des Produktmanagers ist, sich alle Richtlinien zu merken.
Arbeiten Sie mit den Produktteams zusammen, um eine Mischung aus Präsenz- und Online-Workshops (mit Untertiteln) zu organisieren, in denen Sie mehr über Barrierefreiheit (a11y) erfahren und warum dies für Splunk wichtig ist.

Zusammenfassung

Barrierefreiheit dient unseren Nutzern, und es ist von Vorteil, die wirtschaftlichen Argumente für Barrierefreiheit auf Ihre Zielgruppe zuzuschneiden.
Die Unterteilung der Herausforderungen in die Bereiche „Mitarbeiter und Kultur“ einerseits und „Programme und Abläufe“ andererseits kann dabei helfen, Schwachstellen schneller zu identifizieren, zu entscheiden, welche Probleme proaktiv und welche reaktiv angegangen werden sollten, und eine Strategie voranzutreiben – selbst wenn Ihnen die Ressourcen fehlen.
Teamarbeit ist für die umfangreichen Anstrengungen, die die Barrierefreiheit erfordert, von entscheidender Bedeutung. Erkennen Sie, wann Sie an Ihre Grenzen stoßen, und holen Sie sich Hilfe von außerhalb Ihres Teams.

Wir möchten uns auch bei all unseren Mentoren, ehemaligen Kollegen und Führungskräften bedanken, die zum Erfolg von Splunk im Bereich Barrierefreiheit beigetragen haben. Ohne euch wären wir nicht dort, wo wir heute sind.

Seid ihr ein Team oder arbeitet ihr zu zweit an Barrierefreiheit? Meldet euch bei Sim auf LinkedIn oder bei Alexis auf Twitter; die Gespräche, die wir seit unserem Vortrag auf der axe-con geführt haben, waren fantastisch, und auch wenn wir wissen, dass es in einem kleinen Team einschüchternd sein kann, solltet ihr wissen, dass ihr nicht allein seid und die Barrierefreiheits-Community euch gerne hilft.