Working Draft

In dieser Ausgabe unserer ARIA-Runde sind Paweł Masarczyk (Mastodon), Peter Krautzberger (LinkedIn / Mastodon) und Marco Bretschneider (Mastodon) am Start. Weil unser Glücksrad inzwischen schon einen beträchtlichen Teil der ARIA-Spezifikation abgegrast hat, verzichten wir diesmal auf den Zufall und widmen uns stattdessen einigen Themen, die uns zuletzt über den Weg gelaufen sind.

Wir sprechen über sekundäre Aktionen mit ARIA Actions, Tastaturkürzel und ihre zahlreichen Konfliktmöglichkeiten, die überraschend schwierige Accessibility-Situation des HTML-Meter-Elements und Pawełs experimentellen Ansatz, die vorhandene Semantik von Webseiten für Screenreader-Nutzer:innen völlig anders aufzubereiten.

Shownotes

[00:02:43] ARIA Actions

Mit ARIA Actions entsteht ein Mechanismus, über den sich primäre und sekundäre Aktionen eines Elements für assistive Technologien beschreiben lassen. Paweł erklärt das anhand von E-Mail-Clients, Messengern und anderen Oberflächen mit wiederkehrenden Elementen: Statt bei jeder Nachricht erneut Buttons für Löschen, Archivieren oder Antworten durchlaufen zu müssen, könnten diese Aktionen direkt am jeweiligen Element verfügbar gemacht werden. Das Prinzip kennen VoiceOver-Nutzer:innen bereits von iOS, wo zu einem Element zusätzliche Aktionen über den Rotor beziehungsweise entsprechende Wischgesten aufgerufen werden können.

Technisch werden die zugehörigen Aktionen über ID-Referenzen mit dem Element verknüpft. Wir diskutieren, wie dabei nicht verfügbare oder deaktivierte Aktionen behandelt werden könnten, was bei destruktiven Aktionen mit dem Fokus passiert und wie sich vermeiden lässt, dass die referenzierten Buttons anschließend zusätzlich in der normalen Navigation auftauchen. Vieles davon ist noch nicht abschließend geklärt, denn ARIA Actions befindet sich weiterhin in Entwicklung. Peter ordnet den Ansatz in eine Entwicklung ein, die wir bereits bei ARIA Details und ARIA Controls gesehen haben: ARIA beschreibt nicht mehr nur Beziehungen zwischen Elementen, sondern versucht zunehmend, komplexe Interaktionen zwischen räumlich oder strukturell getrennten Teilen einer Oberfläche zugänglich zu machen.

Interessant finden wir das Prinzip auch über Screenreader hinaus. Statt für jede Webanwendung eigene Tastaturkürzel zu erfinden, könnten Browser und andere User Agents solche abstrakt beschriebenen Aktionen möglicherweise selbst für Tastaturnutzer:innen zugänglich machen. Wir erinnern uns dabei auch an frühere Browserfunktionen wie die Navigation über rel="next" und rel="prev" in Opera Presto und wünschen uns generell etwas mehr Innovation bei nativer Browser-Navigation.

[00:26:28] aria-keyshortcuts und accesskey

Von sekundären Aktionen kommen wir direkt zu Tastaturkürzeln. Marco berichtet von Erfahrungen mit dem HTML-Attribut accesskey, dessen praktische Verwendung dadurch erschwert wird, dass die tatsächlich notwendige Tastenkombination von Betriebssystem und Browser abhängt. aria-keyshortcuts löst dieses Problem nicht, denn das Attribut implementiert selbst keinen Shortcut. Es stellt assistiven Technologien lediglich die Information bereit, dass eine Anwendung eine bestimmte Tastenkombination anbietet, beispielsweise wenn diese mit JavaScript implementiert wurde.

Dabei stoßen wir schnell auf das grundsätzliche Problem von Keyboard-Shortcuts im Web: Betriebssystem, Browser, Screenreader und Webanwendung beanspruchen jeweils Tastenkombinationen für sich. Paweł erzählt von einem Podcast-Player, bei dem Escape zum Stoppen der Wiedergabe verwendet wurde. VoiceOver unter iOS bildet seine Zurück-Geste in Safari jedoch ebenfalls auf Escape ab, wodurch die eigentlich bequeme Screenreader-Navigation unerwartet nicht mehr funktionierte. Ähnliche Konflikte gibt es mit F6 sowie mit sprachspezifischen Tastaturlayouts. Auf polnischen Tastaturen werden beispielsweise Sonderzeichen über AltGr-Kombinationen eingegeben, die wiederum von Anwendungen oder Screenreadern als Shortcuts beansprucht werden können.

Wir diskutieren deshalb, ob abstrakte Aktionen langfristig der bessere Ansatz sein könnten. Statt konkrete Tastenkombinationen festzulegen, würde eine Webanwendung nur beschreiben, welche Aktionen verfügbar sind. Browser, Betriebssystem und assistive Technologie könnten daraus jeweils eine zum Nutzungskontext passende Bedienung ableiten. Peter erwähnt außerdem eine von JAWS unterstützte Lösung über data-at-shortcutkeys, mit der sich Shortcuts samt Beschreibung hinterlegen lassen und deren Standardisierung bereits diskutiert wurde.

[00:45:01] Das Meter-Element und assistive Technologien

Peter ist über eine Diskussion im KoliBri-Projekt auf ein Problem mit dem HTML-Element meter gestoßen. Die semantischen Informationen des Elements werden zwar grundsätzlich über die Accessibility APIs weitergereicht, Screenreader geben wichtige Werte wie Minimum und Maximum aber nicht unbedingt aus. Das führt zu der paradoxen Situation, dass Entwickler:innen erwägen, das native HTML-Element durch eine eigene ARIA-basierte Lösung zu ersetzen, obwohl die erste ARIA-Regel eigentlich genau davon abrät, wenn bereits passendes HTML existiert.

Ganz trivial ist das Problem allerdings nicht. Würden Screenreader bei jedem Meter sämtliche Informationen wie aktuellen Wert, Minimum, Maximum, Low, High und Optimum vorlesen, könnte das schnell unnötig ausführlich werden. Ohne den Kontext können Nutzer:innen einen einzelnen Wert wiederum unter Umständen gar nicht sinnvoll einordnen. Wir diskutieren deshalb, ob solche Angaben eher als abrufbare Sekundärinformationen behandelt werden müssten.

Hinzu kommt die Frage, warum Elemente wie meter und progress vergleichsweise selten eingesetzt werden. Marco erinnert an eingeschränkte Styling-Möglichkeiten, wegen derer Teams solche Komponenten häufig selbst nachbauen. Peter hält dagegen, dass meter durchaus Informationen ausdrücken kann, die über einen einfachen Prozentbalken hinausgehen, etwa Grenzwerte für ein bestandenes Prüfungsergebnis oder einen Ladezustand, ab dem ein Fahrzeug sein Ziel erreichen kann. Genau solche semantischen Informationen wären für assistive Technologien eigentlich wertvoll, wenn sie zuverlässig zugänglich gemacht würden.

[00:59:21] Eine andere Navigation durch das Web

Paweł stellt einen experimentellen Prototyp vor, mit dem er untersucht, wie Webseiten für Screenreader-Nutzer:innen anders strukturiert werden könnten. Die Anwendung basiert auf Python und wxPython und verwendet im Hintergrund einen Headless-Chromium samt Playwright. Statt eine Webseite wie ein klassischer Screenreader weitgehend linear zu präsentieren, soll die vorhandene Semantik in eine hierarchische Oberfläche aus nativen Windows-Controls übersetzt werden.

Landmarks wie Banner, Navigation, Main oder Footer bilden dabei größere Container, Überschriften strukturieren die darin enthaltenen Inhalte weiter. Paweł behandelt Überschriften konzeptionell wie Kapitel eines Buchs und damit ebenfalls als Container für die jeweils folgenden Inhalte. Formulare werden auf native Eingabefelder, Checkboxen und Radiobuttons abgebildet, Listen sollen zu Listenfeldern und Tabellen zu navigierbaren Grids werden. Navigationsbereiche sollen wiederum über eine klassische Menüstruktur erreichbar sein. Ziel ist ausdrücklich nicht, einen neuen Browser zu bauen oder fehlende Semantik einer Webseite zu reparieren. Der Prototyp soll vorhandenes semantisches HTML und ARIA lediglich anders darstellen.

Hintergrund ist Pawełs Erfahrung, dass insbesondere weniger erfahrene Screenreader-Nutzer:innen Schwierigkeiten haben können, die flache Darstellung einer komplexen Webseite gedanklich in ihre eigentliche Struktur zu übersetzen. Landmarks, in der deutschen NVDA-Übersetzung als „Sprungmarken“ bezeichnet, und Überschriften liefern bereits viel Struktur, werden aber nicht von allen Nutzer:innen gleichermaßen eingesetzt. Paweł möchte untersuchen, ob eine explizit hierarchische Darstellung den Einstieg erleichtern kann.

Wir vergleichen den Ansatz mit der gruppierten Navigation von VoiceOver und der Objektnavigation von NVDA und streifen frühere Ideen zur Spatial Navigation. Sollte der Prototyp weit genug kommen, möchte Paweł ihn als Open Source veröffentlichen, sodass einzelne Ideen daraus beispielsweise in Screenreader-Add-ons übernommen werden könnten. Zum Schluss landen wir wieder bei einem Thema, das sich durch die gesamte Folge zieht: Von besseren, semantisch beschriebenen Navigationswegen könnten nicht nur Screenreader-Nutzer:innen, sondern ebenso Menschen profitieren, die Webseiten hauptsächlich mit der Tastatur bedienen.

Links

Peter Krautzberger zur Lesbarkeit der ARIA-Spezifikation

Ein Beitrag von Peter zur Frage, wie zugänglich und verständlich die ARIA-Spezifikation selbst eigentlich geschrieben ist.

What Can’t I Press?

Das Werkzeug von Eric Bailey zum Untersuchen und Dokumentieren von Tastaturkürzeln.

Anhören

Feedback-Kanäle