Marcus Herrmann

Die frustrierend unübersichtliche Situation der WAI-Authoring Practices

Dass das Netz im Jahre 2022 nicht mehr so aussieht wie zur Zeiten seiner Erfindung, ist offensichtlich. Immerhin ist das Web mehr als 30 Jahre alt, und Stillstand in einer Technologie wäre ein schlechtes Zeichen. Genauso offensichtlich ist der Einfluss, den es inzwischen auf die Gesellschaft, Politik, (Diskussions-)Kultur, kurz: das Leben von uns hat – im Guten und im Schlechten. Website-bauende unter uns wissen, dass sich – drittens – auch die Art und Weise wie wir das Web bespielen verändert hat. Social Media brachte eine Demokratisierung des Beitragens. Ein Mensch, der Inhalte ins Netz stellen wollte, braucht etwa seit 20 Jahren nicht mehr zwingend Ahnung von FTP, HTML-Dateien und Domains. Und durch technische Fortschritte, genannte Mitmachkultur und eine Professionalisierung hat sich auch der architektonische Ansatz zumindest komplexer Seiten geändert: Wir bauen weniger vollständige Dokumente als vielmehr Komponenten, die in ihrer Zusammenstellung erst Dokumente ausmachen. Die Komponentenbauweise hat dabei mehr als einen Vorteil: Man baut eine Informations- oder Interaktionskomponente einmal (eventuell in unterschiedlichen Abformatieungen für verschiedene Kontexte), und kann sie dann beliebig häufig einsetzen. Das macht Website-Produktion wirtschaftlicher; man kann sich auf Funktionen konzentrieren, anstatt das Rad immer und immer wieder neu zu erfinden. Und auch für die Barrierefreiheit hat der komponentenbasierte Ansatz zumindest theoretisch Vorteile: man sorgt einmal dafür, dass etwas für das Maximum an Usern bedienbar ist, hält einmal Standards ein, wendet einmal best practices an und setzt ein zugängliches Modul dann beliebig häufig ein.

Eine offizielle Komponentenbibliothek?

Und es scheint so, als ob auch das für Webstandards federführende W3-Konsortium (W3C) die Zeichen der Zeit erkannt hat. Denn scheinbar bietet es mit dem „WAI-ARIA Authoring Practices Guide“ (APG) eine – scheinbar seltsam benannte – Komponentenbibliothek an. Für die Öffentlichkeit freigegebene, gut getestete und wohl dokumentierte Bibliotheken dieser Art kennt man erfreulicherweise auch von Regierungsorganisationen (zum Beispiel USA, Großbritannien, Frankreich, Schweiz), öffentlich-rechtlichen Institutionen (z. B. der BBC) und sogar von Vertretern der freien Wirtschaft (beispielsweise ING-Bank, Shopify oder airbnb). Es wirkt also, als hätten wir eine „offiziell beglaubigte“, barrierefreie Component Library für komplexe Web-App-Herausforderungen – damit ist alles gut, oder?

Festzuhalten ist – die APG sind eine Sammlung an Widgets und Interaktionsmustern, häufig mit JavaScript, aber immer mit WAI-ARIA gebaut. Und wie man es vom W3C gewöhnt ist, gibt es detaillierte Erklärungen z. B. zum Tastaturverhalten, den vollständigen Code und natürlich läuffähige Demos mit dazu. Die auf W3C veröffentlichten Authoring Practices unterscheiden sich auf den ersten flüchtigen Blick eigentlich nicht von Webstandards (wie beispielsweise CSS, SVG und RDF). Was die Sache allerdings kompliziert und auch ein wenig frustrierend macht: Die Authoring Practices sind keine Web-Standards, die ein für allemal aufzeigen, wie man Web-App-Interaktionen richtig und maximalkompatibel macht. Sie sind noch nichtmal wetterfeste Nutzungsmuster, die als Ergebnis von Usability-Tests geboren sind. Ja, sie funktionieren teilweise auch nicht „mobil“ oder im Touch-Kontext (im Jahre 2022)!

Eine unbequeme Wahrheit

Die „WAI-ARIA Authoring Practices“ sind in Wirklichkeit eine Demonstration der „reinen WAI-ARIA-Lehre“, also ein Beispieldokument einer dogmatisch korrekten Umsetzung der ARIA-Spezifikation. Noch dazu sind sie Testbett für Entwickler*innen von Hilfstechnologien, mit dessen Hilfe sie ihre Software (wie z. B. Screenreader) weiterentwickeln können. Das machen die APG auch an einer Stelle deutlich:

[T]he purpose of this guide is to illustrate appropriate use of ARIA 1.1 as defined in the ARIA specification, the design patterns, reference examples, and sample code intentionally do not describe and implement coding techniques for working around problems caused by gaps in support for ARIA 1.1 in browsers and assistive technologies.

https://www.w3.org/TR/wai-aria-practices-1.1/

Oder auf deutsch (Eigenübersetzung):

Der Zweck dieses Leitfadens ist es, den angemessenen Gebrauch von ARIA 1.1, wie er in der ARIA-Spezifikation definiert ist, zu illustrieren. Die Entwurfsmuster, Referenzbeispiele und der Beispielcode beschreiben und implementieren absichtlich keine Programmiertechniken, um Probleme zu umgehen, die durch Lücken in der Unterstützung von ARIA 1.1 in Browsern und assistiven Technologien verursacht werden.

Noch einfacher formuliert: Man kann die APG als die idealisierte Demonstration der WAI-ARIA-Spezifikation betrachten, losgelöst von faktischer Unterstützung in assistiver Technologie (AT) oder Ausgabegeräten. Und auch für die Unterstützung von Entwickelnden, sollten sie auf Bugs treffen, sind die AGP nicht gedacht. Im Gegensatz zu den oben verlinkten Bibliotheken von BBC, gov.uk und Co. wurden die dort befindlichen Muster weder initial noch mit jeder neuen Hilfstechnologie-Generation regelmäßig getestet. Mehr noch: Eine reine Übernahme des dort angebotenen Codes kann unter Umständen problematisch sein und der Barrierefreiheit der einsetzenden Seite sogar schaden! Was für ein Plot-Twist also. Heißt das nun, dass man die dortigen Muster überhaupt nicht nutzen sollte, und viele Websites und -apps deswegen unbrauchbar sind, weil sie die Patterns aus dieser Quelle verwenden?

Eine mögliche Strategie

Die Antwort ist ein klares „Jein“. Wie schon im Titel suggeriert: Die Lage um die Authoring Practices muss man differenziert betrachten, denn sie ist nicht besonders übersichtlich oder zugägnlich. Erst einmal das Wichtigste: Mit der Verwendung von Mustern aus den APG holt man sich nicht zwangsläufig alle oben genannten Probleme ins Haus. Einige der Interaktionsmuster sind robust, solide, gut von Hilfsmitteln unterstützt und vielfach getestet. Zum Beispiel:

Wenn ein Designmuster aus dem APG besonders gut zu den eigenen Web-App-Bedürfnissen passt, aber in der obigen Liste nicht auftaucht, gibt es noch einen weiteren Weg: Man schaut in die Github Issues und durchsucht sie nach Nennungen dieses jeweiligen Musters. Grob über den Daumen gepeilt kann man nun erahnen, ob ein Muster nach Ansicht von internationalen Expert*innen eher umstritten ist oder eher nicht, welche Unzulänglichkeiten ggf. noch codeseitig da sind, was die Ergebnisse von User Tests sind oder welche Bugs noch von Seiten der Hilfsmittelhersteller auszumerzen sind.

Und zu guter Letzt bleibt noch eine dritte Lösungsstrategie, die sich nicht nur auf Authoring Practices beschränkt, sondern für Zugänglichkeit in der Web-Entwicklung allgemein gültig und empfehlenswert ist: Nämlich das konkrete Testen von Webprojekten mit Userinnen und Usern. Denn Barrierefreiheit im Web ist – trotz einer Vielzahl an guter, verantwortungsvoll geschriebener und praxisnaher Standards – keine reine akademische Sportart oder Fingerübung. Sondern sie dient letztendlich den Menschen, der Teilhabe und einem Teilarm von Inklusion im immer wichtiger werdenden digitalen Bereich.

Update vom 20.05.2022:

Am Tag der Veröffentlichung dieses Artikel, 19.05.2022, gab es eine Aktualisierung der Authoring Practices. Die neuen APG sind ab jetzt unter folgender Adresse zu finden: https://www.w3.org/WAI/ARIA/apg/.

Dieses Update hat einige Sachverhalte verbessert, die ich im oben stehenden Artikel kritisiert habe:

  • So wirken die AGP zum Beispiel nicht mehr wie „Standards“, sind stattdessen deutlich lesbar, „freundlicher“ und moderner formatiert. Der neue Look ist nicht identisch mit den W3C-WAI-Tutorials, aber ähnlich und aber deutlich einfacher zu navigieren. Kurz: Die neuen APG verströmen nicht mehr die Aura einer technischen Spezifikation, inklusiver latent juristischer Anmutung.
  • Oberhalb der Auflistung aller Patterns findet sich ein Absatz der Warnung, der sich grafisch von dem Rest der Seite abhebt. Er verlinkt auf ein ausführliches Dokument, beinhaltet eine klare Anweisung („Read this first“) und betont die Notwendigkeit, ARIA zuerst einmal verstehen zu müssen, bevor man es anwendet.

Leider musste ich auch Verschlimmbesserungen feststellen:

  • Stand jetzt ist keine Weiterleitung eingerichtet, was insbesondere bei Links auf konkrete Nutzungsmuster ärgerlich ist. Diese werfen nun den Fehler 404 – Seite nicht gefunden Jeder, der eine interne Wissensdatenbank aufgebaut hat oder als externer Beraterin fungiert, darf jetzt manuell Verlinkungen in seinen Schulungsmaterialien anpassen. Es gibt auch ein entsprechendes Issue auf GitHub, ich hoffe sehr, dass z. B. 301-Weiterleitungen noch nachgereicht werden und deren Fehlen dem GAAD-Termindruck zuzuschreiben sind.
  • Mehr noch als vor der Aktualisierung suggerieren die „neuen“ Authoring Practices, dass alle Patterns unproblematisch, barrierefrei und kopierenswert sind, siehe oben. Dabei haben sich die Muster selbst nicht verändert – nur die Verpackung, wenn man so will.

Ich würde mich also sehr freuen, diesen Artikel ein weiteres mal zu aktualisieren, sobald die APG weitere Korrekturen erfahren. Der gestrige Relaunch zeigt, dass dem WAI-Team zumindest einige Probleme bekannt sind, und die Bereitschaft da ist, diese auch abzustellen. Der überraschende Relaunch war für das Timing dieses Artikels hier vielleicht ein wenig unglücklich, aber zumindest in Teilen für die Web-App-Barrierefreiheit ein Schritt nach vorne.