Revision 683: ARIA-Glücksrad

Oct 7, 2025

Marco Bretschneider ist Frontend-/Design-Systems-Engineer und Daniela Kubesch ist Accessibility Engineer. Sie diskutieren spannende ARIA-Attribute wie aria-placeholder und deren Herausforderungen in Formularen. Warum native Checkboxen vorzuziehen sind, wird erklärt und die Bedeutung von aria-labelledby sowie aria-describedby beleuchtet. Zudem geht es um den Einsatz von aria-posinset und aria-setsize bei großen Listen sowie um die effiziente Gestaltung von modalen Dialogen. Ein Highlight ist die Vorstellung des neuen aria-brailleroledescription aus WAI-ARIA 1.3.

Ask episode

AI Snips

Chapters

Transcript

Episode notes

ADVICE

Native Controls Vorziehen

Verwende native Elemente statt ARIA-Äquivalenten, wenn möglich (z.B. Checkbox statt aria-checked).
Implementiere Toggles als Button, wenn die Aktion sofort wirksam wird.

ADVICE

Zustände Mit aria-pressed Kennzeichnen

Nutze aria-pressed für zustandsbezogene Buttons statt selbstdefinierter Klassen.
Verwende das Attribut auch als Hook fürs Styling und für den Accessibility-Tree.

INSIGHT

Fehlendes Accessibility‑Only Pendant

aria-hidden entfernt Elemente vom Accessibility-Tree, ein Gegenstück für nur Accessibility-Anzeige fehlt.
Entwickler benutzen oft SR-Only-CSS-Hacks, weil es kein 'Accessibility-only' Attribut gibt.

Get the Snipd Podcast app to discover more snips from this episode

Get the app

Wir drehen wieder am „Glücksrad“ – diesmal allerdings ausschließlich mit ARIA-Attributen! Schepp hat sich als Mitspielende Accessibility Engineer Daniela Kubesch (LinkedIn / Bluesky / Mastodon) und Frontend/Design-Systems Engineer Marco Bretschneider eingeladen. Der Zufall spuckt ARIA-Attribute aus und wir sezieren sodann deren Einsatzfälle, Stolpersteine und ggf. sinnvolle Alternativen: von aria-placeholder über erklärende Verknüpfungen mit aria-details (plus ariaDetailsElements) bis hin zu großen, virtuellen Listen mit aria-posinset/aria-setsize. Außerdem sprechen wir über gute modale Dialoge (aria-modal & <dialog>) und wagen einen Blick nach vorn mit dem brandneuen aria-brailleroledescription aus WAI-ARIA 1.3.

Schaunotizen

[00:19:52] aria-placeholder: Entspricht inhaltlich dem HTML-placeholder – verschwindet also, sobald Nutzer:innen tippen. In der Praxis deshalb eher nicht verwenden: wichtige Hinweise gehören dauerhaft sichtbar neben/unter das Feld. Als Notnagel kann der Placeholder in der Accessible-Name-Ermittlung herangezogen werden, falls kein Label vorhanden ist (trotzdem immer ein richtiges <label> setzen). Möglicher Spezialfall: contenteditable. Weiterführend: HTML placeholder, Accessible Name Computation.
[00:27:58] aria-details & ariaDetailsElements (DOM): Verknüpft ein Widget mit einer längeren, „reichen“ Zusatzbeschreibung (z. B. FAQ-Inhalt, Größentabelle, Bildbeschreibung). Anders als aria-describedby beeinflusst aria-details nicht den Accessible Name; Screenreader können die Details kontextuell anbieten. Über die DOM-Property element.ariaDetailsElements lässt sich die referenzierte(n) Beschreibung(en) als Elemente abrufen (nützlich für Tests/Tooling). Wichtig: Informationen auch visuell zugänglich machen! Weiterführend: aria-describedby, aria-labelledby, aria-description.
[00:41:36] aria-posinset & aria-setsize: Für „Teilmengen“ großer Sets (virtuelle Listen/Tabellen, Pagination): aria-setsize gibt die Gesamtzahl der Elemente an (falls unbekannt: -1), aria-posinset markiert die Position des jeweils sichtbaren Items. Typische Anwendung bei endlosem Scrollen oder chunkweisem Nachladen („250 von 3000 geladen“). Setzt man auf den einzelnen Listeneinträgen/Zeilen; die Information landet zuverlässig im Accessibility Tree. Weiterführend: listitem role, row role.
[00:52:48] aria-modal: Kennzeichnet einen modalen Dialog (meist mit role="dialog" oder nativem <dialog>): Inhalte außerhalb sind für Assistive Technologien „inert“ also deaktiviert, der Fokus bleibt im Dialog. Gute Praxis: Dialog immer beschriften (aria-labelledby), eine kurze Erklärung mit aria-describedby verknüpfen, Fokus beim Öffnen auf ein sinnvolles Start-Ziel setzen (nicht zwingend das erste Input). Bei modalen Dialogen beginnt die Überschriftenhierarchie sinnvoll erneut (z. B. H1 im Dialog). Für die visuelle/Pointer-Sperre der Seite am besten das native <dialog> mit .showModal() verwenden (der Browser inertet den Rest). Weiterführend: <dialog>, inert, WAI-ARIA APG: Dialog (Modal) Pattern.
[01:06:44] aria-brailleroledescription (neu in WAI-ARIA 1.3): Liefert eine speziell für Refreshable Braille Displays geeignete, kurze Rollenbeschreibung (z. B. Abkürzungen wie „BTN“ statt „Button“). Wird von AT/Plattform-APIs ausgewertet; im Markup sparsam und nur mit etablierten, verständlichen Kürzeln einsetzen. Ergänzt die bestehende Rollenkommunikation (ähnlich zu aria-roledescription, aber gezielt für Braille-Ausgaben). Weiterführend: WAI-ARIA 1.3: aria-brailleroledescription, aria-roledescription.

Revision 683: ARIA-Glücksrad

Native Controls Vorziehen

Zustände Mit aria-pressed Kennzeichnen

Fehlendes Accessibility‑Only Pendant

Schaunotizen

Links