Barrierefreiheitsereignisse

„Gibt es keine Möglichkeit zu wissen, wann – …?“

Hier gibt es immer eine Pause. Der Kunde weiß, was er fragt, und ich weiß, was er fragt, aber es in Worte zu fassen – es laut auszusprechen – gestaltet sich unerwartet schwierig.

In den Momenten vor der Frage war es eine rein technische Frage – nicht anders als „können wir dies tun, wenn ein Benutzer auf seinem Handy ist.“ Aber es gibt immer eine Pause, denn diese Frage fällt nicht leicht; nicht wie all die anderen Fragen zu Browsern und Verbindungsgeschwindigkeiten. Ein Satz wie „in einem unterstützenden Browserkontext“ fällt einem nicht so leicht ein wie „auf einem Handy“, „in Internet Explorer“ oder „bei einer langsamen Verbindung“. Ersteres, nun ja, das wäre etwas, das ich sagen würde – ein Satz, der eindeutig in den Bereich der Barrierefreiheitsberater fällt. Letzteres kann der Kunde nachvollziehen. Er hat ein Handy, er hat andere Browser benutzt, er war mit langsamen Internetverbindungen konfrontiert.

„Gibt es keine Möglichkeit zu wissen, wann – … ein Benutzer … so etwas wie einen Bildschirmleser benutzt …?“

Eine einfache Frage, die eine komplizierte Antwort hervorruft, ist bei fast jedem Austausch mit einem Webentwickler Standard. Diese Antwort ist seit langem eine erfrischende Abweichung von dieser Norm: „Nein, das können wir nicht.“

Die Sache ist, wie ich sagen werde, technisch unmöglich; Computer können, sehen Sie, nicht auf diese Weise miteinander kommunizieren. Oft gibt es hier eine spürbare Erleichterung: „Nein“ zum technischen Teil; „Nein“ zum Teil der Computer. Das ist natürlich alles, was sie fragen wollten. Das glaube ich wirklich.

Selbst wenn wir könnten, so werde ich erklären, würden wir es nicht wirklich wollen. Ein solches Aufspalten unserer Codebasis würde uns Wartenden mehr Belastung aufbürden, nicht weniger. Hier gibt es eine einfache Parallele zur Unterhaltung „wenn sie auf einem Handy sind“; eine, die wir sicherlich schon geführt haben. Wir können den Browsing-Kontext eines Benutzers nie sicher wissen, und Annahmen werden uns und unsere Benutzer nur in Schwierigkeiten bringen. Wann immer eine Funktion, eine Komponente oder eine neue Designbehandlung hinzugefügt oder geändert wurde, müssten wir die gleichen Gespräche darüber führen, wie wir sie in die „barrierefreie“ Erfahrung übersetzen. Wenn diese Funktionen gar nicht erst wesentlich sind, sind sie dann überhaupt die Mühe wert? Wenn diese Funktionen wesentlich sind – nun, dann müssen wir immer noch einen Weg finden, sie in beiden Kontexten zum Laufen zu bringen.

Auf den ersten Blick mag dies für unsere Benutzer eine verlockende Option erscheinen: eine verbesserte, voll ausgestattete Website auf der einen Seite, eine voll barrierefreie alternative Erfahrung auf der anderen. Das löst sich jedoch bei der geringsten Untersuchung auf: Wenn die voll ausgestattete Website nicht barrierefrei ist, wird die barrierefreie Website nicht voll funktionsfähig sein. Indem wir die „barrierefreie Erfahrung“ von der „echten Website“ abweichen lassen, ziehen wir letztendlich eine schärfere Trennlinie zwischen diesen beiden Definitionen und rücken die „barrierefreie Erfahrung“ näher an einen nachträglichen Gedanken heran – begrenzt und frustrierend außer Takt mit der „echten“ Website, wie es so viele dedizierte mobile Seiten schnell geworden sind.

Hier gibt es nie Meinungsverschiedenheiten. Wiederum: Das ist alles nachvollziehbar. Wir alle sind schon einmal unentrinnbar in die Nutzung der „mobilen“ Version einer Website gezwungen worden. Wir haben diese Fehler als Benutzer schon gemacht; wir haben diese Fehler als Entwickler schon gemacht. Wir wissen es jetzt besser.

Aber das ist keine rein technische Frage. Das ist nicht so einfach wie Browserfunktionen und Bildschirmgrößen – eine Frage eines privilegierten Browsing-Kontexts oder eines anderen. Technische Fragen fallen leicht. Auf halbem Weg durch die Frage – im Zögern, in der Pause, in dem gestolperten Wort – wurde aus einer alltäglichen Entwicklungsfrage etwas viel Belastenderes. Denn es gab ein Wort, das passte.

„Gibt es eine Möglichkeit, dass wir wissen können, wann ein Benutzer eine Behinderung hat?“

Das leichte „Nein“ fühlte sich ermächtigend an; ein Ausweichen. „Es spielt keine Rolle; es kann nicht getan werden“ als Antwort auf eine zutiefst belastende Frage war ein unerwarteter Balsam für Gefragten und Befragten gleichermaßen. Da war wieder diese spürbare Erleichterung – „Nein“ zum technischen Teil; „Nein“ zum Teil der Computer. Das war natürlich alles, was sie fragen wollten.

Dieses leichte „Nein“ gibt es nicht mehr. In iOS 12.2 und MacOS 10.14.4 ist in den VoiceOver-Einstellungen von Apple ein Schalter erschienen, harmlos mit „Barrierefreiheitsereignisse“ beschriftet. Er wurde ohne viel Aufhebens eingeführt – abgesehen von einer kurzen Erwähnung im iPhone-Benutzerhandbuch von Apple – und wir sind uns immer noch nicht sicher, wie er verwendet werden soll. Die großzügigste Auslegung der Absicht hinter dieser Funktion ist, dass sie mit der gleichen Absicht entwickelt wurde wie ein Bezeichner im Stil von „UA-String“ für Benutzer, die VoiceOver verwenden.

Wir wissen eines sicher: Wenn diese Einstellung aktiviert ist – und das ist sie standardmäßig –, identifiziert Ihr Browser Sie als VoiceOver-Benutzer, um Ihnen beim Surfen im Web zu helfen. Wenn Sie Apples VoiceOver verwenden, senden sowohl Ihr Telefon als auch Ihr Computer Ihre angenommene Behinderung an das gesamte Internet, es sei denn, Sie weisen sie ausdrücklich an, dies zu unterlassen.

Update Mai 2019: Sie haben es entfernt.

Wenn Sie über diese Änderung nicht wütend sind, sollten Sie es sein – nicht nur wegen dessen, was sie für die Benutzer bedeutet, sondern auch wegen dessen, was sie Ihnen aufbürdet. Apple hat Sie mit dem Wissen belastet, dass Sie jetzt ja wissen können, ob ein Benutzer eine Behinderung hat. Wir können diese Informationen nutzen, um eine eingeschränkte alternative Version einer Website anzubieten, in die wir Menschen einer geschützten Klasse sehr leicht einbeziehen können. Und sobald wir anfangen, auf „Barrierefreiheitsereignisse“ zu achten, können wir diese Informationen erfassen, wie alles andere, was ins Web gesendet wird. Eine Behinderung eines Benutzers kann und wird auf einen einzigen Datenpunkt reduziert – eine kalte, unpersönliche true, die unaufhaltsam an seinen Namen gebunden ist, in einer Datenbank gespeichert, vielleicht bestimmt, verkauft, geleakt, an Versicherer weitergegeben, auf eine gezielte Marketingmöglichkeit reduziert wird. Alles unter dem Deckmantel der Inklusivität.

Ich bin mir sicher, dass die Entwickler, die für die Funktion „Barrierefreiheitsereignisse“ verantwortlich waren, irgendwann gefragt wurden, ob eine solche Funktion möglich sei. Ihre Antwort war „Ja“. Ich zweifle nicht daran, dass sie es gut meinten. Ich bin mir genauso sicher, dass es sich in diesem Moment wie die richtige Antwort anfühlte; eine technische Lösung für ein technisches Problem und eine einfache Frage des Browsing-Kontexts.

Eines Tages – nicht in ferner Zukunft, hoffe ich – werde ich eine ähnliche Frage gestellt bekommen. Sie wird zögerlich, stammelnd gestellt werden. Die Pausen werden nur allzu vertraut sein. Ich werde nicht mehr den einfachen, vertrauten Trost der technischen Unmöglichkeit haben – kein einfaches „Nein“, um mich vor den unbequemen Gesprächen zu schützen, die ich schon längst mit meinen Kunden hätte führen sollen. Jetzt gibt es keinen technischen Grund mehr, warum ich nicht wissen kann, ob ein Benutzer „so etwas wie einen Bildschirmleser“ verwendet. Ich – meine Kunden, ihre Datenbanken, ihre Organisationen, ihre Muttergesellschaften, ihre Partner, ihre Risikokapitalgeber, ihre Werbetreibenden und so weiter bis ins Unendliche – können absolut wissen, wann ein Benutzer eine Behinderung hat.

Aber ich werde mich nicht daran beteiligen, den Fehler zu verbreiten, den Apples Entwickler gemacht haben. Ich werde meine Antwort schwer und unbequem in der Luft hängen lassen: Nein. Nicht, weil wir es nicht können – das können wir. Nicht, weil wir es nicht sollten, obwohl, nein, das sollten wir immer noch nicht. Nein – jetzt werde ich das Wort so grob werden lassen, wie ich es mir immer gewünscht habe, weil ich nicht mehr den kalten Trost des „nun, technisch gesehen“ habe, hinter dem ich mich verstecken kann.

Nein.