Zwei Herangehensweisen an Barrierefreiheit im Internet

Artikel vom 20. Juli 2022. ISSN 1614-3124, #72. Schwerpunkt: Barrierefreiheit (RSS-Feed für alle Themen).

Man kann zwischen mindestens zwei Herangehensweisen an Barrierefreiheit im Internet unterscheiden. Eine besteht darin, zugängliche Websites und Apps zu produzieren, und diese zugänglich zu halten oder zugänglicher zu machen: aktive Barrierefreiheit. Die andere besteht darin, zugänglich machende Software zu erstellen, einschließlich User-Agents, und diese zu warten und zu verbessern: passive Barrierefreiheit. ^*

Der erste Ansatz wird im Wesentlichen durch die Web Content und Authoring Tool Accessibility Guidelines widergespiegelt. Beim zweiten greifen die User Agent Accessibility Guidelines. (Richtlinien zu Barrierefreiheit kommen dabei nicht nur vom W3C.)

Autorzentrierte Barrierefreiheit

Wenn man sich beide Ansätze näher anschaut, mag man denken, dass das Feld der Barrierefreiheit für gewöhnlich die erste Herangehensweise bevorzugt. Wenn dem so ist – die Arbeitshypothese dieses Beitrags –, verpasst dies eine Gelegenheit. Es würde zugleich unnötigen (und vielleicht unfairen) Druck auf Entwickler und Seitenbetreiber ausüben, wenn es um alles geht, was effizienter auf Softwareseite gelöst werden kann.

Fortschritte für Barrierefreiheit sollten leichter über Software zu erzielen sein, weil die Arbeit mit ein paar Dutzend Herstellern – rund um assistive Technologien, Browser und Betriebssysteme – wahrscheinlicher und schneller zum Erfolg führen muss als Hunderttausende Entwickler zu bitten, etwas an fast zwei Milliarden Websites zu machen.

Warum befinden wir uns in dieser Lage? Vielleicht fühlt es sich einfacher an, Entwicklern zu sagen, was sie tun sollen, als dasselbe mit Implementierern zu machen. Dazu sind einige Zugänglichkeitsprobleme ausgesprochen schwierig. (Da Software Zeit braucht, das zu erledigen, was Entwickler und Seitenbetreiber auf ihrer Seite tun können – die, die durch Regeln erreichbar sind –, mag der Softwareansatz auch Widerstand erzeugen. Aus persönlicher Erfahrung ist ein Beispiel hierfür Kritik an der Idee, Sprachdeklarationen und -erfassung keine Entwicklungsanforderung, sondern ein Softwareproblem zu machen.) Neben Kommunikationsvorlieben und internem Widerstand mag es aber auch herausfordernd sein, mit Herstellern zu arbeiten – auf Screenreader-Seite scheint es kein Google zu geben, das wie im Fall des Chrome-Ökosystems das ganze Feld hinter sich vereint und herzieht.

Sicherlich fehlt hier etwas, besonders Standpunkte und Berichte von »Evangelists« im Bereich Barrierefreiheit. Schließlich mag die Arbeit mit Herstellern wesentlich weniger Sichtbarkeit erfahren, und dies das größte Problem darstellen. Man kann jedoch auch kaum einen Reflex leugnen, dass wann immer etwas als Zugänglichkeitsproblem verstanden wird, wir die Verantwortung an Entwickler und Seitenbetreiber übertragen, ohne dabei sonderlich auf die Tragweite des Problems zu achten (ein anderes Thema, das separat betrachtet werden sollte) und – wie bemerkt, die Hypothese dieses Beitrags – ohne ausreichende Prüfung, Anforderung und Lobbyarbeit, dass es durch Software gelöst wird.

… führt nicht zu »automagischem« Zugang

Was wäre, wenn wir nicht aktive Barrierefreiheit bevorzugen, sondern uns auf passive Barrierefreiheit – Barrierefreiheit auf Softwareseite – konzentrieren würden; wenn das nicht funktioniert, weiter auf der Softwareseite Druck zu machen; wenn das nicht funktioniert, weiter auf die Softwareseite zu setzen, aber Entwickler über das absolute Minimum zu informieren, um das Problem zu lindern; und wenn das nicht funktioniert, noch weiter auf der Softwareseite Druck auszuüben, und vorsichtig zu dem hinzuzufügen, was wir von Entwicklern und Seitenbetreibern erwarten?

Aber man mag anderer Ansicht sein.

Vielleicht gibt es Möglichkeiten, zu zeigen, wie Barrierefreiheit nur über Regeln für Entwickler und Seitenbetreiber angegangen werden kann.

Niemand aber scheint zeigen zu können, dass wir bereits guten Gebrauch vom Softwareansatz machen: zu zeigen, wie User-Agents so gut geworden sind, dass sie sogar eine schlechte Website zugänglich machen – wie sie automatisch und korrekt alternative Inhalte zuordnen oder generieren; wie sie Farben und Kontrast auto-korrigieren; wie sie automatisch Formularelemente zuordnen und beschreiben; wie sie automatisch Sprache ermitteln und übersetzen; wie sie automatisch und wenn benötigt Text vereinfachen und umformulieren; wie sie eine Menge mehr machen, automatisch, dass wir lange Zeit immer auf Entwickler und Seitenbetreiber geschoben haben, als ob Tooling, Automatisierung und Maschinenlernen dem Feld der Barrierefreiheit und denen, die darauf angewiesen sind, nichts zu bieten hätten.

Es scheint sogar schwer, zu zeigen, dass es aktuell überhaupt eine Vision für Barrierefreiheit gibt, in der etwas automatisiert und automatisch passiert – automagisch –, und wie so eine Vision nicht vielleicht mit der Betonung nur einer Herangehensweise verwelkte, nämlich der, die ziemlich vielen Entwicklern sagt, hinter ziemlich vielen Websites hinterher zu laufen. (Widerstand gegen die obenstehenden automatisierten Funktionen mag ein Indiz dafür sein, wie sehr uns ein Nordstern für das Feld fehlt.)

Es scheint ebenso schwer, zu belegen, dass kontinuierlich mit Herstellern gearbeitet wird, und immer zuerst mit Herstellern; dass Mitigierungen nicht mit »Entwickler, tut dies« beginnen, sondern mit »Hersteller, tut das«; dass die Arbeit an Barrierefreiheitsproblemen von beiden Seiten erfolgt, über beide Ansätze, wenn eine Softwarelösung schwer zu erzielen ist; und dass wir als Gemeinschaft unsere Tage nicht bitter auf Twitter beenden, mit Schuldzuweisungen, wie x Zugänglichkeit bei a verbockte, sondern zufrieden damit, wie das Web zugänglicher wurde, weil jeder hart dafür kämpft, Tooling besser zu machen – manchmal so, dass kein Webentwickler oder Seitenbetreiber überhaupt einen Finger krümmen musste.

Nicht eine, sondern zwei Herangehensweisen an Barrierefreiheit im Internet.

Dank und Achtung an jeden, der daran arbeitet, Informationen mehr Menschen zugänglich zu machen.

Abbildung: Barrierefreiheit ist wichtig, aber das Feld zögert und bürdet Entwicklern mehr auf als Herstellern. Zwanzig Jahre vergehen? (Copyright King Features Syndicate, Inc., vertrieben durch Bulls.)

Mit Dank an Thomas Steiner für Feedback zu diesem Beitrag.

^* Diese Unterscheidung ist selten, aber nicht neu: Sébastien Aupetit und Vincent Rouillé behandeln sie in ihrem Kapitel Annotation Tool for the Smart Web Accessibility Platform der 2014er Ausgabe von Computers Helping People with Special Needs. Frei übersetzt, »aktive Barrierefreiheit fußt weitgehend auf Normen und Empfehlungen; passive Barrierefreiheit wird durch a posteriori durchgeführte inhaltliche Transformationen erreicht.«

Über mich

Ich bin Jens, und ich bin ein Engineering Lead und Autor. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin W3C und WHATWG verbunden und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Mit meinem aktuellen Umzug nach Spanien bin ich offen für eine neue Führungsposition im Frontend-Bereich. Beachte und empfehle gerne meinen Lebenslauf oder mein LinkedIn-Profil.

Ich experimentiere gerne, nicht nur in der Webentwicklung, sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen.