Working Draft

Wir spielen mal wieder ARIA-Glücksrad und haben uns dafür mit Paweł Masarczyk (Mastodon), Peter Krautzberger (LinkedIn / Mastodon) und Marco Bretschneider (Mastodon) in bekannter Runde zusammengefunden. Daniela Kubesch musste diesmal krankheitsbedingt leider aussetzen 😥. Wir bedienen erneut unseren Zufallsgenerator, das „Glücksrad“, welches uns verschiedene ARIA-Properties ausspuckt, über die wir aus Sicht von Spezifikation, Implementierung und praktischer Nutzung mit assistiven Technologien sprechen.

Dabei geht es weniger um trockene Attributkunde als um die Frage, was von den ARIA-Versprechen im Alltag tatsächlich bei Screenreadern und Browsern ankommt. Wir streifen typische Einsatzfälle, problematische Altlasten, offene Support-Lücken und die Unterschiede zwischen dem, was in Spezifikationen steht, was Browser daraus machen und was bei Nutzerinnen und Nutzern schließlich wirklich nutzbar ist.

Shownotes

[00:05:05] aria-selected

Zum Einstieg landen wir bei aria-selected und sprechen darüber, wo dieser Zustand überhaupt erlaubt ist, etwa bei Optionen, Tabs, Grid-Zellen oder Tree-Items. Dabei geht es unter anderem um Mehrfachauswahl in komplexeren Widgets, um den Unterschied zwischen Fokus und Auswahl sowie um die Frage, warum ARIA hier neben true und false auch noch den Zustand undefined kennt.

[00:17:22] aria-level

Danach schauen wir uns aria-level an. Das Attribut kennen viele vor allem im Zusammenhang mit selbstgebauten Überschriften, also etwa bei Elementen mit role="heading", aber es spielt auch in Baumstrukturen, Kommentarhierarchien und ähnlichen Konstruktionen eine Rolle. Wir sprechen über Heading-Level jenseits von HTMLs sechs Überschriftsebenen, über Unterschiede zwischen Browsern und Screenreadern und über aktuelle Arbeiten rund um tiefere Überschriftenstrukturen, einschließlich der Diskussion um neue HTML-Mechanismen wie im WHATWG-Issue zu Heading Offsets.

[00:28:14] aria-owns und ariaOwnsElements

Von dort aus geht es zu aria-owns und der zugehörigen DOM-API ariaOwnsElements. Wir erklären, dass damit der Accessibility-Tree umgebaut werden kann, indem Inhalte semantisch an eine andere Stelle gezogen werden als im DOM. Genau das macht das Attribut mächtig, aber auch fehleranfällig. Entsprechend diskutieren wir die Risiken, verweisen auf die bekannte Kritik an aria-owns und kommen auch auf Konfliktauflösung bei widersprüchlicher Semantik zu sprechen, etwa im Zusammenspiel mit role="presentation", role="none" oder aria-hidden. In diesem Zusammenhang erwähnen wir auch den Beitrag von Manuel Matuzović zu präsentationalen SVGs, in dem es um aria-hidden="true" als robustere Lösung geht.

[00:42:39] aria-disabled

Mit aria-disabled wird es scheinbar einfacher, aber auch hier zeigt sich schnell, dass die Praxis komplizierter ist. Wir sprechen darüber, warum viele Teams lieber das native HTML-disabled nutzen, warum aria-disabled allein nur ein Signal für assistive Technologien ist und keinerlei Funktionalität automatisch abschaltet, und wie sich das auf Fokusreihenfolge, Tastaturbedienung und Screenreader-Ansagen auswirkt. Dabei kommt auch zur Sprache, wie sich deaktivierte Elemente im Browse-Modus und im Formularmodus von Screenreadern unterschiedlich verhalten und warum man bei selbstgebauten Widgets zusätzliche Logik mit JavaScript und oft auch CSS ergänzen muss.

[00:57:20] aria-controls und ariaControlsElements

Ein längerer Block dreht sich um aria-controls und die dazugehörige DOM-API ariaControlsElements. Wir diskutieren den ursprünglichen Gedanken dahinter, nämlich Beziehungen zwischen steuernden und gesteuerten Elementen explizit zu machen, etwa in komplexen Formularen, Menüs oder Tabellen-Interfaces. Gleichzeitig wird deutlich, dass die tatsächliche Unterstützung in Screenreadern dünn ist und dass unklar bleibt, wie Nutzerinnen und Nutzer sinnvoll zwischen solchen verknüpften Elementen navigieren sollen. Im Gespräch fallen dazu auch andere ARIA-Mechanismen wie aria-expanded, aria-describedby, aria-description und aria-details.

[01:00:32] Support-Realität von Browsern, Screenreadern und Testprojekten

Ausgehend von aria-controls sprechen wir grundsätzlicher über die Lücke zwischen Spezifikation und tatsächlicher Unterstützung. Dabei kommen Unterstützungsmatrizen und Testprojekte wie a11ysupport.io, AT-Driver, Tetralogicals HTML-Support-Projekt und WebAIM zur Sprache. Außerdem geht es um praktische Tests mit Screenreadern wie JAWS und um den Wert von Open-Source-Projekten wie NVDA, bei denen Verbesserungen durch Beiträge aus der Community direkt möglich sind.

[01:15:20] KI, Agenten und Semantik im Web

Am Rand streifen wir auch die Frage, wie agentische Browser und KI-Systeme künftig auf Semantik zugreifen könnten. Dazu fällt der Blick auf WebMCP und auf die Sorge, dass ARIA von manchen Systemen überinterpretiert werden könnte. Als Aufhänger dazu wird Adrian Rosellis Kritik an OpenAI, ARIA und SEO erwähnt.

[01:22:33] aria-orientation

Zum Schluss erwischen wir noch aria-orientation. Hier geht es um die Ausrichtung von Widgets wie Slidern, Scrollbars oder Tablisten und darum, ob vertikale oder horizontale Bedienmuster gegenüber Nutzerinnen und Nutzern kommuniziert werden sollten. Dabei kommen fehlende oder lückenhafte Unterstützung in Screenreadern, Standardannahmen bei der Tastaturbedienung und native HTML-Parallelen wie orient bei <input type="range"> zur Sprache.

Links

Revisionen 683 und 699

Unsere vorangegangenen ARIA-Glücksrad-Runden.

Invoker Commands API

Die API fällt im Zusammenhang mit der Frage, ob neue HTML-Mechanismen Beziehungen wie bei aria-controls künftig nativer abbilden könnten.

Visually Hidden Content and the Clip Path Hack

Der Artikel ergänzt den allgemeinen Accessibility-Kontext der Folge.

Bad UI

Eine Sammlung absichtlich schlecht gestalteter Formulareingaben, die typische UX- und Accessibility-Probleme greifbar und erlebbar machen.

User Inyerface

Ein interaktives Spiel, das Nutzerinnen und Nutzer durch einen frustrierenden Dark-Pattern-Flow schickt und dabei schlechte UX-Praktiken überspitzt demonstriert.

Anhören

Feedback-Kanäle