Sollte man aria-checked statt nativer Checkboxen verwenden?

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.

Links

Revision 651: Accessible Rich Internet Applications (ARIA)

Folge, in der Schepp mit Marco über den grundsätzlichen Sinn, den Einsatz und dia Stolperfallen von ARIA spricht.

a11yphant

a11yphant ist eine von Daniela bereitgestellte, kostenlose, offene Lernplattform für Web-Accessibility. Statt langer Texte übst du die Basics direkt in interaktiven Coding-Challenges und kurzen Quizzes – ohne Account startklar, optional mit Anmeldung zum Fortschrittsspeichern.