Barrierefreiheit mit Web Analytics

Web Analytics sind Dienste, mit denen sehr detaillierte Statistiken über die Nutzung eines Webangebots erhoben werden können. Ursprünglich hatten sie ungefähr den Funktionsumfang von serverseitig generierten Reports, können mittlerweile aber wesentlich mehr. Aber kann man sie auch zur Verbesserung der Barrierefreiheit verwenden?
Analytics kann gezielt dazu genutzt werden, mögliche Barrieren aufzuspüren. Dazu nehmen wir uns gezielt die Bereiche der Website vor, die am meisten Probleme machen können. Das sind vor allem Bereiche mit JavaScript sowie Formulare. Verbesserungsmöglichkeiten sehe ich vor allem dort, wo der Nutzer mit der Site interagiert. Vorneweg der Hinweis: Da es sich bei assistiven technologien um externe Software handelt, ist es nicht möglich, durch Analytics die Nutzung solcher Technologien zu tracken. Auch nicht indirekt. Der Browser bzw. bei Software das Betriebssystem wissen, dass der Nutzer die Accessibility APIs abruft, entsprechende Informationen werden aber nicht an die Website bzw. die App übermittelt. Die Diskussion darüber flammt in der Szene immer wieder auf. Apple hatte wohl für iOS entsprechende Pläne, diese aber aufgrund massiver Kritik verworfen.
Es gibt generell zwei Möglichkeiten, das Tracking zur Verbesserung der Barrierefreiheit zu verwenden. Das allgemeine Tracking einer bereits bestehenden Website sowie das Testen in einem geschlossenen Bereich.

Das allgemeine Tracking

Die großen Dienste erlauben das Beobachten – also Tracken – von Aktionen. Dazu gehört zum Beispiel das Verhalten beim Ausfüllen von Formularen oder der Umgang mit bestimmten Elementen der Webseite wie die Navigation. Das Maus-Tracking gehört mehr oder weniger zum Standard, aus irgendeinem Grund werden Tastatureingaben nicht standardmäßig getrackt.
Mit einer Heatmap kann man erkennen, wo die Menschen hingeklickt haben. Wenn es da nichts zu klicken gab, besteht Optimierungsbedarf.
Damit lässt sich auch beobachten, wie hoch die Dropout-Rate bei Ausklappmenüs ist. Wenn ein signifikanter Anteil der Nutzer daneben klickt gibt es Verbesserungsbedarf.
Ein weiterer fehlerträchtiger Bereich sind Formulare. Das Scheitern an Formularen gehört sicherlich zu den häufigsten Barrierefreiheitsproblemen überhaupt. Mit Analytics lässt sich generell beobachten, wie hoch die Zahl der Fehlversuche beim Ausfüllen von Formularen ist. Die Ursache ist nicht immer eindeutig an den Daten ablesbar, aber bei einer auffälig hohen Fehlerrate sollte ohnehin ein Experte ran, der mögliche Probleme mit einer heuristischen Analyse erkennen kann.
Ein Problem bei der Optimierung der Barrierefreiheit besteht allerdings darin, dass die statistische Signifikanz zu gering ist. Wir wissen natürlich nicht, ob unser Besucher blind, motorisch eingeschränkt ist oder eine andere Behinderung hat. Gehen wir davon aus, dass bis zu fünf Prozent unserer Besucher eine Behinderung haben, schlägt sich diese Zahl wahrscheinlich nicht als messbarer Wert in unseren Daten nieder. Diese fünf Prozent setzen sich aus unterschiedlichen Behinderungen zusammen, es kann sein, dass Blinde problemlos zurecht kommen, während motorisch Behinderte scheitern. Wir erkennen also eher Usability- als Barrierefreiheits-Probleme. Für ein Dropout-Menü halte ich eine Fehlerrate von fünf Prozent schon für alarmierend, zumindest die Navigation einer Website sollte problemlos funktionieren. Auch bei Formularen halte ich einen möglichst geringen Wert für wünschenswert. Die meisten – auch behinderten – Nutzer sind oft nicht so aufmerksam, wenn es um das Ausfüllen geht. Aber offensichtlich sind sie bereit, das Formular auszufüllen und ein mehrfaches Scheitern legt nahe, dass der Webdesigner nicht sauber gearbeitet hat.
Eine Möglichkeit, die ich allerdings verworfen habe ist die Beobachtung der Seiten, bei denen die meisten Nutzer die Website verlassen. Hier fehlt einfach die Aussagekraft, es kann alle möglichen Gründe haben, warum die Besucher die Website an dieser Stelle verlassen. Sie haben vielleicht gefunden, was sie gesucht haben oder erkannt, dass sie das Gesuchte hier nicht finden oder die Unterseite bildet den Schlusspunkt eines logischen Informationsblocks und ist daher ein natürlicher Ausstiegspunkt.
Ein Bereich, der ebenfalls nur indirekte Informationen liefert ist das Tracking der User Agents. Darunter werden Daten zum Betriebssystem, Browser, Browserversion und teils auch eingesetzte Plugins gesammelt. Außerdem werden Werte wie die Bildschirmauflösung oder die Internet-Bandbreite getrackt. Daraus läst sich zumindest ableiten, ob die Benutzer mit veralteter Technik auf der Website unterwegs sind. Plugins für PDF und Flash sind zwar noch weit verbreitet, aber dank NoScript und Flashblock kann heute kaum noch jemand sagen, ob sie tatsächlich noch zum Einsatz kommen.
Veraltete Software sowie langsame Internetverbindungen deuten zumindest auf einen eingeschränkten Zugang zu neuen Techniken hin, was ja auch schon eine Barriere sein kann. Die Lösung lautet so oder so responsives Webdesign und möglichst geringe technische Anforderungen an die Technik der Besucher zu stellen.

A-B- und multivariate Tests

A-B-Tests im Live-Betrieb können verwendet werden, um die User Experience einer Website bezüglich der Barrierefreiheit zu testen. Nehmen wir an, wir haben zwei Varianten einer Navigation, die eine barrierefreier als die andee. Oder zwei Grafiken mit unterschiedlichem Kontrast. Hier kann ausprobiert werden, welche Variante besser funktioniert bzw. angegenommen wird.
Wichtig ist dabei, dass die Nutzerzahlen signifikant hoch und die Unterschiede zwischen den Varianten ausreichend groß sind. Ansonsten besitzen solche Zahlen keine Aussagekraft. Natürlich sind es auch hier eher allgemeine Faktoren und weniger die Barrierefreiheit, es sei denn, man hat definitiv eine signifikante Zahl von behinderten Nutzern.
So etwas kann nützlich sein, um für Barrierefreiheit gegenüber dem Kunden zu argumentieren. Wenn die Grafik mit weniger Kontrast nicht angeklickt wird oder ein Formular signifikante Dropouts hat, sind das harte Zahlen, die sich nicht wegdiskutieren lassen.

Testen im Beta-Bereich

Eine alternative Möglichkeit ist, die Webseite oder den Prototypen in einem geschlossenen Beta-Bereich zu testen. Ähnlich wie beim Usability-Test erhalten die Testpersonen die Möglichkeit, eine Webseite mit ihren Hilfsmitteln zu testen. Nur müssen sie dazu nicht in ein Testlabor fahren, sondern können das bequem von zuhause aus mit ihren eigenen Hilfsmitteln machen. Die Kommunikation mit dem Testleiter kann über Skype oder per Telefon erfolgen. In diesem Fall werden gezielt Menschen mit Behinderung dazu eingeladen, die Website zu evaluieren, wobei verschiedene Indikatoren wie Ausfüllzeiten, Fehlversuche und so weiter gemessen werden können.
Bei Screenreader-Nutzern würde es sich außerdem anbieten, ein Browser-Plugin zu entwickeln, dass die Interaktion zwischen Nutzer und Browser aufzeichnet. Ich vermute zum Beispiel, dass die meisten Blinden nur einen Bruchteil der Screenreader-Funktionen tatsächlich nutzen. Entweder kennen sie die Fuktionen nicht oder sie brauchen sie nicht. Leider haben wir keine brauchbaren Daten dazu.

Messbare Erfolge

Wenn Formulare und andere Interaktionsbereiche verbessert wurden, indem zum Beispiel das CAPTCHA entfernt wurde, kann über Analytics beobachtet werden, wie sich die Zahl der erfolgreichen Interaktionen entwickelt. Wenn grobe Fehler ausgebübgelt wurden, kann sich die Erfolgsrate sehr gut entwickeln. Aber wie schon oben beschrieben, das Problem der statistischen Aussagekraft bleibt bestehen. Daher sollten die Zeiträume für die Beobachtung so lang sein, dass sich aussagekräftige Besucherzahlen ergeben. Bei Websites mit vielen tausend Besuchern sind auch Verbesserungen im einstelligen Prozentbereich als Erfolg zu werten.

Fazit

Web Analytics kann nur eingeschränkt dazu verwendet werden, um die Barrierefreiheit einer Website zu verbessern. Sie kann aber als Teil einer größeren Strategie der Qualitätssicherung verwendet werden. Das bietet sich für Bereiche mit starker Interaktion an. Die anderen Bereiche der Website, die nur konsumiert werden müssen sollten entsprechend schon barrierefrei sein, ansonsten wäre es auch witzlos, ausgerechnet die komplexeren Bereiche zu verbessern. Insgesamt kann das Testen von Live-Versionen von Websites auch für die barrierefreiheit sehr sinnvoll sein.

Zum Weiterlesen