Spacy – mit Radical Simplification zu einer barrierefreien Anwendung für Online-Events

This case study is also available in English

TL;DR

Die Challenge

Spacy, eine Plattform für Online-Events, sollte ein barrierefreies Nutzungserlebnis bieten, um allen Teilnehmenden gleichermaßen Zugang zu ermöglichen.

Unser Lösungsansatz

INNOQ entwickelte Spacy mit einer klaren Struktur und Unterstützung für Screenreader, um Barrierefreiheit zu gewährleisten. Das Design umfasste einfache Navigationsmöglichkeiten und Interaktionen, die für alle Nutzertypen zugänglich sind.

Das Ergebnis

Eine benutzerfreundliche Anwendung, die vollständige Barrierefreiheit bietet und bei internen Open Space-Events erfolgreich eingesetzt wurde, um die Teilhabe aller zu ermöglichen.

Bei INNOQ liegen uns regelmäßige Firmenevents mit Workshops und Fachvorträgen besonders am Herzen. Alle zwei Monate treffen wir uns mit allen – mittlerweile mehr als 150 – Kolleginnen und Kollegen unserer neun Standorte in Deutschland und der Schweiz, um uns auszutauschen und fortzubilden. Besonders bewährt hat sich dabei die Open Space-Methode, d.h. die Teilnehmenden bestimmen selbst und vor Ort die Themen und die Tagesordnung.

Da diese Events seit 2020 nur noch online stattfinden konnten, begann die Suche nach einem geeigneten Planungstool – und war mit dem Online Whiteboard Miro auch schnell gefunden. Die Problematik dabei stellte sich erst in der Praxis heraus. Die bekannten Online Whiteboard Tools bieten ein tolles, interaktives Erlebnis – aber nur für Menschen ohne Sehbeeinträchtigung. Damit wurde ein blinder Kollege, der auf einen Screenreader angewiesen ist, komplett von der Anwendung ausgeschlossen. Ein Nachteil, den wir weder mit unserem Anspruch an Barrierefreiheit noch mit unserem digitalen Know How vereinbaren konnten.

Was es nicht gibt, können wir entwickeln

So entschied sich Joy Heron, Senior Consultant und Accessibility-Expertin bei INNOQ, in Eigeninitiative ein geeignetes Tool für Online Open Space-Veranstaltungen zu entwickeln. Die Idee zu Spacy war geboren. Um die Grundbedingung „Barrierefreiheit“ zu erfüllen, musste die Anwendung einige Voraussetzungen erfüllen: sie sollte sowohl Screenreader-, als auch mobil- und Keyboard-tauglich sein – und selbstverständlich für alle ein ansprechendes und praktikables Nutzungserlebnis bieten. Doch die wichtigste Frage zu Anfang war: Was ist wichtig und relevant, sprich: Was muss alles vom Screenreader vorgelesen werden? Dazu zählen nicht nur schriftliche, sondern auch visuelle Informationen. Denn grundsätzlich sollte Spacy so gestaltet sein, wie es vielen schon von anderen Tools bekannt war: Es werden Zettel gesammelt und auf ein Board gepackt. Dabei geht es vor allem um Informationen wie „Welche Session findet wann in welchem Raum statt?“ oder auch um das Anlegen oder Umziehen von eigenen Sessions.

Ein schöner Nebeneffekt, der im Übrigen für das ganze Thema Accessibility gilt: Die Anwendung wurde durch die zusätzlichen Informationen auch für Menschen ohne Beeinträchtigungen – in diesem Fall also sehende Menschen – besser nutzbar und übersichtlicher. Denn alle Informationen, die vom Screenreader vorgelesen werden, sind auch visuell eingebaut.

Klare Struktur im Fokus

Ein wichtiger Bestandteil von Spacy ist die Warteschlange, die auf der linken Seite des Screens dargestellt wird. Hier können die Nutzer:innen ihre Sessions mit Titel und Kurzbeschreibung vorschlagen und in einer Liste einordnen. Anschließend kann von hier aus jeder der Reihe nach seine Session im Zeitplan platzieren.

Der Zeitplan auf der rechten Seite des Screens erscheint in Form einer Tabelle und beinhaltet die Informationen Ort, Tag und Zeit. Hier werden die Sessions mit den unterschiedlichen Themen anhand verschiedenfarbiger Zettel platziert. Besonders hilfreich für Nutzerinnen und Nutzer, die auf einen Screenreader angewiesen sind: Beim Durchlaufen der Tabelle wird in jeder Zeile zunächst der entsprechende Raum und dann die entsprechende Zeit genannt, ohne jedes Mal wieder in den Kopfbereich der Tabelle wechseln zu müssen. Bewegen sich die Nutzenden hingegen innerhalb ein und derselben Spalte bzw. eines Raums, erhalten sie die Information zum Raum erst nach dem jeweiligen Zeitslot. So können sie selbst entscheiden, ob sie diese Information hören oder überspringen möchten.

Die Zettel werden – zugunsten der Barrierefreiheit – in der jetzigen Version von Spacy nicht per Drag-and-Drop platziert. Stattdessen gibt es Schaltflächen direkt in der Tabelle, die per Klick bzw. mit der Tastatur bedient werden. Mit dieser Funktion können Screenreader und andere assistierende Technologien besser umgehen. Jedoch ist eine zusätzliche Drag-and-Drop Funktion für die Weiterentwicklung nicht ausgeschlossen und im Zuge der Progressive Enhancement-Philosophie sogar wünschenswert. Schließlich soll Spacy allen Nutzerinnen und Nutzern ein bestmögliches Erlebnis bieten.

Lesen und gelesen werden

Das User Interface (UI) folgt den typischen Anforderungen eines digitalen Open Space-Events – und selbstverständlich der Accessibility. Deshalb fiel die technologische Entscheidung auf verschiedene HTML-Attribute. So wurde zum Beispiel für die Warteschlange eine HTML-Liste verwendet. Screenreader können hier leicht Kontextinformationen herauslesen, z.B. wie viele Sessions aktuell in der Warteschlange sind. Mithilfe von ARIA (Accessible Rich Internet Applications), das bei den meisten Browsern und Screenreadern implementiert ist, und im Speziellen mit der Funktion „Live-Regionen“ konnten auch Live-Content-Aktualisierungen vorgelesen werden, beispielsweise Änderungen im Zeitplan.

Eng verbunden mit der UI ist die Datenbank dahinter. Jan Stępień, Senior Consultant bei INNOQ, übernahm diesen Part und entschied sich für Crux, ein interessantes bitemporales Datenbankmodell. Im Wesentlichen werden dort alle Transaktionen gespeichert, die innerhalb der Anwendungshistorie stattfinden. So wird beispielsweise die Fehleranalyse vereinfacht. Außerdem werden die Sessions als strukturierte Dokumente in der Datenbank abgespeichert. Damit spiegelt sie 1:1 alles, was in der UI zu sehen ist.

Ebenfalls elementar für die Barrierefreiheit: die Navigation. Dafür wurde ein <nav> HTML-Element verwendet, mit dem man zu den unterschiedlichen Bereichen auf der Seite springen kann. Aber nicht nur technologisch, sondern auch hinsichtlich der einfachen Bedienbarkeit und der guten Orientierung sollte Spacy die Anforderungen von Screenreader-, Keyboard- und Mobilgeräte-Nutzenden gleichermaßen erfüllen. Ein Beispiel ist die Platzierung von Sessions. Um stets zu wissen, wohin man innerhalb der Website als nächstes navigieren muss, gibt es an mehreren Stellen einen Link zu der Tabelle. Mit dem Screenreader kann man dann beispielsweise innerhalb dieser Tabelle mit den Pfeiltasten navigieren und gelangt zu den Schaltflächen mit verfügbaren Timeslots. Die Links verbessern jedoch die UX für alle Nutzenden, weil man z.B. den Link auf einem Mobilgerät auch einblendet, wenn man nur einen Teil des Screens sehen kann.

Viele Details, die die Accessibility verbessern, werden erst beim Testen entdeckt. Eine Möglichkeit ist es, die Anwendung während der Entwicklung selbst mit einem Screenreader zu testen. Doch besonders sinnvoll ist es, wenn ein Programm oder eine Website von den betroffenen Menschen getestet wird. Deshalb wurde Joy Heron bei der finalen Abnahme von unserem blinden Kollegen Andreas Maier unterstützt. Er erkennt leichter Schwächen in der Struktur, wie Redundanzen oder fehlende Informationen.

‍Sein Feedback führte zu weiteren entscheidenden Verbesserungen. So mussten Nutzer:innen in einer ersten Version von Spacy, um ein Thema vorschlagen und platzieren zu können, zunächst einen Display-Namen wählen. Hierfür folgten sie einem Link, setzten den Namen und kehrten von dort zurück zur Anwendung. Für Screenreader-Nutzer:innen war diese Art der Navigation verwirrend. Deshalb entschied sich Joy Heron, den INNOQ SSO zu integrieren. Damit waren alle Nutzerinnen und Nutzer nach erfolgtem Login automatisch mit ihrem Display-Namen angemeldet und konnten unmittelbar mit der Eingabe ihrer Session beginnen. Auch die Verwendung von ARIA Live-Regionen erfolgte nach dem Feedback von Andreas Maier, dass ihm Veränderungen in der Warteschlange, z.B. dass seine eigene Session erfolgreich platziert wurde, nicht vom Screenreader vorgelesen werden.