Working Draft

Wir spielen wieder ARIA-Glücksrad und sprechen mit Paweł Masarczyk (Mastodon), Peter Krautzberger (LinkedIn / Mastodon) und Marco Bretschneider (Mastodon) über ARIA-Rollen und -Attribute, die uns unser Glücksrad ausspuckt. Daniela Kubesch (LinkedIn / Bluesky / Mastodon) musste leider erneut aussetzen, und Paweł wurde später von seiner Internetverbindung aus der Runde gewürfelt.

Wir arbeiten uns durch abstrakte Landmark-Rollen, praktische Landmark-Navigation, die Rolle option, aria-required, ariaNotify() und schließlich role="form". Dabei geht es wie immer darum, was die Spezifikation meint, was Browser und assistive Technologien daraus machen und wo native HTML-Elemente fast immer die bessere Wahl sind.

Shownotes

[00:02:28] role=“landmark“

Zum Auftakt würfeln wir die abstrakte Landmark-Rolle. Wir sprechen darüber, warum es in ARIA überhaupt abstrakte Rollen gibt, obwohl sie nicht direkt verwendet werden dürfen, und stellen fest, dass sie vermutlich eher Browsern und Accessibility-APIs als Autorinnen und Autoren dienen. Anschließend biegen wir zu den konkreten Landmark-Rollen wie banner, navigation, main, contentinfo und complementary ab, die heute fast alle native HTML-Entsprechungen besitzen.Wir diskutieren außerdem, warum Elemente wie section oder Formulare nur dann als Landmark sinnvoll sind, wenn sie einen zugänglichen Namen besitzen, und weshalb zu viele oder falsch verschachtelte Landmarks eher schaden als helfen. Schließlich fragen wir uns, ob Landmark-Navigation nicht auch für reine Tastaturnutzende interessant wäre, und verweisen auf Browser-Erweiterungen wie Landmark Navigation via Keyboard or Pop-up. Außerdem überlegen wir, ob sich mit dem WebAIM Million Report oder HTTP Archive herausfinden lässt, wie häufig abstrakte Rollen fälschlich eingesetzt werden.

[00:24:40] role=“option“

Die Rolle option wirkt zunächst wenig spannend, weil sie im Wesentlichen dem nativen option-Element entspricht. Interessant wird sie erst dann, wenn man sich eine eigene Listbox oder Combobox bauen muss, beispielsweise für durchsuchbare Select-Komponenten.Wir sprechen darüber, wie aufwendig solche Eigenbauten sind, weil neben der Semantik auch die gesamte Tastaturbedienung nachimplementiert werden muss. Deshalb hoffen wir auf die weitere Verbreitung von Customizable Selects und Customizable Multi-Selects. Dabei streifen wir auch den aktuellen Stand von Interop 2026 sowie einen kürzlich wieder aufgetauchten Datalist-Bug unter iOS.

[00:33:22] aria-required

Bei aria-required fragen wir uns zunächst, wann man das Attribut überhaupt braucht, wenn es doch bereits das native required-Attribut gibt. Schnell landen wir bei selbstgebauten Eingabekomponenten, bei denen die Semantik zwar kommuniziert werden soll, man aber keine native Formularvalidierung bekommt.Daraus entwickelt sich eine größere Diskussion über Formularvalidierung im Allgemeinen. Wir sprechen über Browser-Bubbles, unterschiedliche Browser- und Dokumentensprachen, das Unterdrücken nativer Fehlermeldungen mittels novalidate und preventDefault(), eigene Fehlermeldungen, Fokusmanagement und ARIA Live Regions.

In diesem Zusammenhang bringt Peter ariaNotify() ins Spiel. Die neue API soll Benachrichtigungen an assistive Technologien deutlich einfacher machen als klassische Live Regions. Dazu verlinken wir erste Erfahrungen und Browser-Tests von Oida Is Des: First Look und Browser Support. Zum Schluss schweifen wir noch zu Declarative Partial Updates ab und überlegen, ob sich damit sogar Live-Regionen ohne eigenes JavaScript befüllen ließen.

[00:53:19] role=“form“

Zum Abschluss würfeln wir eine weitere eher unspektakuläre Rolle. Wir sind uns schnell einig, dass man in den allermeisten Fällen einfach ein echtes form-Element verwenden sollte, weil man sonst zahlreiche praktische Browser-Funktionen wie FormData, form.elements oder das native Submit-Verhalten verliert.Spannend wird es erst, als Marco von historisch gewachsenen Formularstrukturen berichtet, in denen Formulare in Formularen auftauchen. Als mögliche Alternative sprechen wir über das form-Attribut, mit dem Eingabefelder einem Formular per ID zugeordnet werden können, obwohl sie sich an ganz anderer Stelle im DOM befinden.

Außerdem lernen wir, dass ein Formular ohne zugänglichen Namen zwar weiterhin als Formular erkannt wird, aber nicht mehr als Landmark erscheint. Das ist sinnvoll, um unnötige Landmark-Einträge zu vermeiden, insbesondere bei versteckten oder rein technischen Formularen.

Links

TyfloPodcast

Ein polnischsprachiger Podcast rund um Blindheit, Sehbehinderung, Barrierefreiheit und assistive Technologien, an dem Paweł schon seit Jahren mitwirkt, über den wir in unserer Vorbesprechung sprachen.

Anhören

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.