Revision 699: ARIA-Glücksrad Nachklapp, neue APIs und reale Unterstützung

In dieser Folge setzen wir dort an, wo wir mit der vorherigen ARIA-Glücksrad-Folge aufgehört haben. Denn wir haben nach der Veröffentlichung tolles Feedback bekommen und holen uns deren Absender als Verstärkung rein: Mit Accessibility Engineer Daniela Kubesch (LinkedIn / Bluesky / Mastodon), Frontend/Design-Systems Engineer Marco Bretschneider, Web-Technologie-Consultant und W3C Invited Expert Peter Krautzberger (LinkedIn) und Accessibility Experience Experten Paweł Masarczyk sprechen wir darüber, was von ARIA-Attributen in der Praxis wirklich ankommt – bei Browsern, im Accessibility Tree und letztlich bei Screenreadern.

Wir gehen systematisch die Attribute aus der letzten Glücksrad-Runde durch, ordnen sie technisch ein und ergänzen sie um Perspektiven aus Spezifikation, Implementierung und tatsächlicher Nutzung. Dabei wird klar: Zwischen Spec-Idee, API-Mapping und realer Unterstützung liegen oft Welten.

Shownotes [00:05:08] aria-placeholder Wir klären, dass aria-placeholder tatsächlich das ARIA-Pendant zum HTML-placeholder ist – gedacht für selbstgebaute Input-ähnliche Controls. Alle sind sich einig: In freier Wildbahn sieht man es kaum, was vermutlich auch ein gutes Zeichen ist. Spannend ist vor allem, wie Placeholder von Screenreadern angesagt werden und wie sie sich von aria-describedby unterscheiden lassen. [00:11:25] aria-details & ariaDetailsElements (DOM) Peter nutzt die Gelegenheit für einen Deep Dive: aria-details ist kein „längeres Describe-By“, sondern ein eigenes Pattern, entstanden aus echten Use-Cases (z. B. Google Docs mit Kommentaren). Wir sprechen über die neuen Element-APIs, die ohne ID-Listen auskommen, über Popover-Verknüpfungen und darüber, wie vage Specs bewusst Spielraum für Assistive Technologien lassen. [00:21:13] (Core) Accessibility API Mappings (AAM) Ein Abstecher unter die Haube: AAM-Spezifikationen beschreiben, wie DOM und ARIA auf die Accessibility-APIs der Betriebssysteme gemappt werden. Eigentlich für Browser-Hersteller gedacht – aber extrem hilfreich, um zu verstehen, wo Informationen verloren gehen oder ergänzt werden. [00:33:35] aria-posinset & aria-setsize Die Klassiker für große, virtuelle Datenmengen. Wir diskutieren, warum diese Attribute auf Einzelelementen sitzen müssen, wie gut sie tatsächlich unterstützt sind und ob User Agents nicht mehr selbst berechnen sollten. Fazit: theoretisch sinnvoll, praktisch noch eine Baustelle. [00:47:17] aria-errormessage Ein gutes Beispiel für das Dilemma „gute Idee, holprige Unterstützung“. Während NVDA und TalkBack Fortschritte machen, bleibt die Abdeckung lückenhaft. Trotzdem sehen wir den Mehrwert gegenüber reinem aria-describedby – gerade, wenn Fehlermeldungen klar als solche kommuniziert werden sollen. [00:50:31] CSS Speech & Audio-Design Wir diskutieren die Idee, Audio-Ausgabe per CSS zu beeinflussen: von Tonhöhe über Geschwindigkeit bis hin zu Sound-Design. Zwischen Branding-Potenzial und Kontrollverlust für Nutzer:innen entsteht eine Grundsatzfrage, die stark an Debatten rund um Alternativtexte erinnert. [01:05:11] Braille-Properties Sehr spezielle Werkzeuge für sehr spezielle Fälle. Peter erklärt, warum Braille-Attribute existieren, wofür sie gedacht sind (z. B. Bildung, Musik- oder Chemienotation) – und warum man sie in 99,9 % der Fälle besser nicht anfasst. [01:15:15] aria-colcount, aria-colindex & Tabellen Wir landen wieder bei großen Tabellen, Grids und Tree-Grids: Wann machen zusätzliche ARIA-Infos Sinn, wann sind sie redundant? Besonders spannend sind menschenlesbare Index-Texte (z. B. Schachfelder wie „A4“) jenseits reiner Zahlen. [01:23:01] aria-multiselectable Ein eher leises Signal mit großer Wirkung: Es teilt Assistive Technologien mit, dass eine interaktive Liste Mehrfachauswahl erlaubt. Wir ordnen es ein zwischen nativen Desktop-Patterns, Web-Mail-UIs und den WAI-ARIA Authoring Practices. Links A-Tag Wien 2026 Accessibility-Konferenz in Wien, Anmeldung ab 1. Februar. ARIA Actions Vorschlag für ein neues Pattern, um sekundäre Aktionen besser zugänglich zu machen. Core Accessibility API Mapping Spezifikation zum Mapping von ARIA auf Betriebssystem-APIs. ARIA-Issues zu Placeholder, Details & Co. Diskussionen rund um mehrere der besprochenen Attribute. HTML-Support in Screenreadern Überblick zu tatsächlicher Unterstützung von HTML-Features. Deprecation-Diskussion zu aria-errormessage Einblick in die Debatte innerhalb der ARIA Working Group. Léonie Watson: CSS Speech Vortrag zur Motivation und Einordnung von CSS Speech. JAWS Sound Schemes Beispiel für nutzerseitig konfigurierbares Audio-Feedback. Pronunciation Task Force „Gegenseite“ im Diskurs um Aussprache und Audio-Kontrolle. Leonie Watson: Addressing concerns about CSS Speech Einordnung der Kritikpunkte und Gegenargumente. Vasilis van Gemert: Exclusive Design Talk mit spannenden Audio- und Nicht-visuellen Design-Experimenten. WAI-ARIA Authoring Practices: Listbox Referenzmuster für interaktive (auch multiselect-fähige) Listen.