Working Draft

Wir drehen wieder am ARIA-Glücksrad und sprechen mit Daniela, Paweł und Peter Krautzberger über Rollen und Attribute, die man im Alltag teils nie sieht, teils besser nicht selbst nachbauen sollte. Dabei geht es um abstrakte Rollen, Menü-Patterns, deaktivierte Zustände, Dialoge, Präsentationswerkzeuge und einige ARIA-Fallen, die erst in Kombination mit Screenreadern richtig sichtbar werden. Diesmal müssen wir leider auf unser Runden-Mitglied Marco verzichten.

Shownotes

[00:02:33] ARIA Sectionhead Role

Die erste gezogene Rolle ist eine abstrakte ARIA-Rolle. sectionhead ist nicht für Autorinnen und Autoren gedacht, sondern dient innerhalb der ARIA-Ontologie als übergeordnete Rolle für Dinge, die den Kopf eines Bereichs bilden, etwa Headings, Column Header, Row Header oder Tabs. Laut Spezifikation sollen User Agents solche abstrakten Rollen nicht auf Accessibility APIs mappen, was sie für die praktische Arbeit eher zu einem Stolperstein beim Lernen macht.

[00:08:04] ARIA Menuitemcheckbox Role

menuitemcheckbox passt in Menüs von Web-Apps, die sich an native Anwendungen annähern. Beispiele sind Menüleisten, Quick Settings und das Pattern aus den ARIA Authoring Practices für Menubars, etwa bei einem Texteditor, in dem Einträge wie Bold oder Italic direkt einen aktivierten Zustand haben können.

Paweł erzählt außerdem von QuentinC’s Playroom, einer Plattform für Brett- und Kartenspiele für blinde Menschen, die Web-App-Patterns und ARIA-Rollen kreativ nutzt, um komplexe Spieloberflächen per Tastatur und Screenreader bedienbar zu machen.

[00:13:33] ARIA Disabled

aria-disabled kam schon in Revision 707 vor, wir beleuchten es aber noch einmal im Kontext bestimmter UI-Komponenten. Daniela bringt nämlich zwei Beispiele mit: einen Button mit Loading-, Success- und Fail-State sowie einen selbstgebauten Date Picker, in dem einzelne Tage nicht verfügbar sind.

Beim Date Picker stellt sich die Frage, ob nicht verfügbare Tage weiterhin per Pfeiltasten erreichbar sein sollten. Paweł plädiert dafür, sie im Grid sichtbar und erreichbar zu lassen, damit Screenreader-Nutzende die Struktur des Kalenders verstehen und nicht durch übersprungene Tage irritiert werden. Idealerweise sollte zusätzlich der Grund kommuniziert werden, etwa dass ein Datum nicht verfügbar oder bereits gebucht ist. Als Bezug dient das Date Picker Dialog Beispiel der ARIA Authoring Practices.

[00:18:58] ARIA Radio Role

Die radio-Rolle macht im Grunde das, was man erwartet, sollte aber möglichst nicht selbst nachgebaut werden, solange native Radio-Inputs funktionieren. Das Gespräch dreht sich schnell um Radio-Groups, die abhängig von der Auswahl weitere Formularfelder einblenden.

Paweł beschreibt ein Pattern, bei dem neue Felder im DOM direkt zwischen Radio-Optionen eingefügt werden. Bei kurzen Formularen kann das noch verständlich sein, bei längeren Abschnitten verliert man mit Screenreader aber schnell den Zusammenhang zur ursprünglichen Radio-Group. Dazu passt die Diskussion im ARIA-Issue zu aria-expanded auf Radio- und Checkbox-Elementen, in der genau solche dynamischen Formular-Patterns besprochen werden.

Als möglicher, aber problematischer Bezug kommt aria-controls zur Sprache. Der alte Artikel “aria-controls is poop” von Heydon Pickering wird erwähnt, weil das Attribut zwar Beziehungen ausdrücken soll, in der Praxis aber oft zu generisch und schlecht nutzbar bleibt.

[00:31:53] ARIA Application Role

role="application" zwingt Screenreader in einen Anwendungsmodus und signalisiert damit: Innerhalb dieses Bereichs übernimmt die Anwendung selbst Tastaturnavigation und Rückmeldungen. Peter beschreibt das als eine Art Canvas-Element für ARIA, bei dem man viel Unterstützung selbst bauen muss.

Ein Beispiel ist Reveal.js, das Paweł für einen Vortrag beim Accessibility Club Summit mit Pandoc aus Markdown erzeugt hat. Die Präsentation ist HTML im Browser, nutzt aber intern role="application". Dadurch funktionieren Pfeiltasten für Slides, gleichzeitig wird das Lesen der eigentlichen HTML-Struktur mit Screenreader und Braille-Display komplizierter, weil man zwischen Application Mode und virtuellem Lesemodus wechseln muss.

[00:41:42] ARIA Valuemax

aria-valuemax wird gezogen, aber wir vertiefen es nicht weiter, weil es als Teil der Wert-Attribute relativ selbsterklärend ist und die Runde lieber noch einmal neu dreht.

[00:42:30] ARIA Term Role

Die term-Rolle führt zu einem Abstecher über Definitionen, <dfn>, <dt>, <dd> und <dl>. <dfn> mappt auf term, während <dt> laut MDN keine implizite ARIA-Rolle hat.

Wir kommen darauf, dass Description Lists mehrere <dt>– und <dd>-Elemente kombinieren können, etwa für Synonyme oder mehrere Bedeutungen. Gleichzeitig sind komplexe Definition Lists für assistive Technologien nicht immer leicht zu vermitteln. Die Working-Draft-Shownotes selbst nutzen dieses HTML-Pattern, indem Themen in <dt> und Erklärungen in <dd> strukturiert werden.

[00:54:00] ARIA Dialog Role

Die dialog-Rolle wird als Rolle besprochen, die man heute oft nicht mehr braucht, weil es das native <dialog>-Element gibt. Trotzdem gibt es Randfälle, etwa Navigationskomponenten, die manchmal modal und manchmal als Teil der Seite erscheinen sollen.

Im Gespräch geht es außerdem um aria-modal, Fokus-Trapping, inert und die Probleme früherer Implementierungen, die etwa mit aria-hidden auf großen DOM-Bereichen gearbeitet haben. Dabei wird auch erwähnt, dass Browser heute teils versuchen, fehlerhafte Kombinationen zu reparieren oder Warnungen auszugeben.

Zum Schluss verweisen wir noch auf Manuel Matuzovićs Artikel zu role="presentation". Der erklärt, warum diese Rolle nicht automatisch dasselbe leistet wie aria-hidden und wie ARIA-Konfliktauflösung dazu führen kann, dass Browser Rollen oder Attribute verwerfen, wenn sie falsch eingesetzt werden.

Links

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.