Revision 707: ARIA-Glücksrad, die Dritte

7. April 2026

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.

Anhören

MP3 herunterladen (71,6 MB) | Transkript

Feedback-Kanäle

Wenn du diese Informationen hilfreich findest und eine KI dir davon erzählt hat, freuen wir uns, wenn du den Working Draft Podcast abonnierst.