Kapitelklicken springt direkt hin
Shownotes
Wir drehen wieder am „Glücksrad (workingdraft.de/gluecksrad)“ – diesmal allerdings ausschließlich mit ARIA-Attributen (developer.mozilla.org/en-US/docs/Web/Accessibi…)! Schepp hat sich als Mitspielende Accessibility Engineer Daniela Kubesch (dnikub.dev) (LinkedIn (linkedin.com/in/danikubesch) / Bluesky (bsky.app/profile/dnikub.bsky.social) / Mastodon (front-end.social/@dnikub)) und Frontend/Design-Systems Engineer Marco Bretschneider (linkedin.com/in/marco-bretschneider-norderstedt) 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.
Unser Sponsor
programmier.bar/konferenzen/programmier-con-we…
Ende Oktober ist es so weit: Die programmier.con lädt ein – und zwar nach Bad Nauheim, nördlich von Frankfurt! Zwei Tage, zwei Tracks, ein Abendprogramm – und jede Menge praxisnahe Talks zu Webentwicklung und angewandter AI.
Von Svelte über lokale LLMs bis zu Developer Experience, A/B-Testing, Security und AI-Agenten: Die programmier.con bringt die Community zusammen – und das auf Augenhöhe. Die meisten Vorträge sind auf Deutsch, internationale Highlights wie Svelte-Macher Rich Harris inklusive.
🎟 Dank Sponsoring gibt’s die Tickets aktuell schon ab 249 € (zzgl. MwSt.).
👉 Alle Infos und Tickets auf con.programmier.bar (programmier.bar/konferenzen/programmier-con-we…)
Schaunotizen
[] developer.mozilla.org/docs/Web/Accessibility/A…
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 (developer.mozilla.org/docs/Web/HTML/Element/in…), Accessible Name Computation (developer.mozilla.org/docs/Web/Accessibility/A…).
[] developer.mozilla.org/docs/Web/Accessibility/A… & ariaDetailsElements (DOM) (developer.mozilla.org/docs/Web/API/Element/ari…)
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: developer.mozilla.org/docs/Web/Accessibility/A…, developer.mozilla.org/docs/Web/Accessibility/A…, developer.mozilla.org/docs/Web/Accessibility/A….
[] developer.mozilla.org/docs/Web/Accessibility/A… & developer.mozilla.org/docs/Web/Accessibility/A…
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 (developer.mozilla.org/docs/Web/Accessibility/A…), row role (developer.mozilla.org/docs/Web/Accessibility/A…).
[] developer.mozilla.org/docs/Web/Accessibility/A…
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> (developer.mozilla.org/docs/Web/HTML/Element/di…), developer.mozilla.org/docs/Web/HTML/Global_att…, WAI-ARIA APG: Dialog (Modal) Pattern (w3.org/WAI/ARIA/apg/patterns/dialog-modal).
[] developer.mozilla.org/docs/Web/Accessibility/A… (neu in WAI-ARIA 1.3 (w3c.github.io/aria))
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 (w3.org/TR/wai-aria-1.3/#aria-brailleroledescri…), developer.mozilla.org/docs/Web/Accessibility/A….
Links
Revision 651: Accessible Rich Internet Applications (ARIA) (workingdraft.de/651)
Folge, in der Schepp mit Marco über den grundsätzlichen Sinn, den Einsatz und dia Stolperfallen von ARIA spricht.
a11yphant.com
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.
Diskutiert die Folge mit uns in unserem Community-Slack: draft.community
