ARIA in HTML  

ARIA-Attribute sind nicht überall erlaubt

Accessible Rich Internet Applications (ARIA) ist eine Spezifikation des W3C. Darin wird die Onthologie der Rollen, Attribute und Eigenschaften von Auszeichnungssprachen im Web spezifiziert. Im Dezember 2021 ist ein weiteres Regelwerk vom W3C veröffentlicht worden, die einige Regeln für den Einsatz von ARIA in HTML festlegt. Das Regelwerk ist insbesondere für Konformitätschecker relevant. Webentwickler sollten den Standard aber auch zur Kenntnis nehmen.

Zum Webstandard

Die Konformitätsbedingungen für den Einsatz von ARIA in HTML werden in dem Dokument „ARIA in HTML“ beschrieben:
http://www.w3.org/TR/html-aria/

Insbesondere geht es in ARIA in HTML darum,

  1. dass ARIA und HTML nicht in Konflikt stehen und
  2. dass ARIA nicht unnötig auf Webseiten eingesetzt wird.

ARIA in HTML ist ein Modul der HTML-Spezifikation. Das Dokument ist an Webentwickler, aber insbesondere auch an Entwickler von Konformitätscheckern gerichtet.

Ein Konformitätschecker überprüft eine Webseite auf die Einhaltung von Regeln, die beispielsweise in HTML spezifiziert werden. Ein Beispiel für ein Konformitätschecker ist der W3C Markup Validation Service. Mit ARIA in HTML gibt es zusätzliche Regeln für die Anbieter von Konformitätscheckern, damit ARIA möglichst korrekt in HTML eingesetzt wird.

Nicht erlaubter Einsatz von ARIA

Konformitätschecker sollen zukünftig vier Arten von inkorrektem ARIA anzeigen.

Unzulässige Zuweisungen von Rollen

Der wesentliche Inhalt des Webstandards ist eine Tabelle mit HTML-Elementen, die Angabe, welche Rolle das HTML-Element ursprünglich besitzt, und eine Auflistung der zulässigen Rollen und Attribute, die das Element erhalten darf. Die Tabelle ist nützlich bei der Entwicklung von Widgets.

Nach ARIA in HTML ist beispielsweise der folgende Code von einem Konformitätschecker als Fehler anzuzeigen:

<button role="heading">Für Screenreader ist das jetzt eine Überschrift</button>

Dieser Code-Schnipsel wird vom W3C Markup Validation Service als Fehler angezeigt.

Bad value heading for attribute role on element button.

Die Veränderung der Semantik ist besonders dann problematisch, wenn es um die Tastaturbedienung geht. Ein Button ist eine Komponente, die Interaktion erlaubt. Eine Überschrift ist hingegen ein strukturierendes Element, die keine Interaktion im Browser erlaubt. Deshalb darf ein Button die Rolle „heading“ nicht bekommen.

Wenn ein Button zusätzlich als Überschrift ausgezeichnet werden soll (z.B. in einem Akkordeon), dann ist ein Konstrukt wie nachfolgend erforderlich:

<h2><button> Für Screenreader ist das eine Schaltfläche in einer Überschrift</button></h2>

Unzulässige Verschachtelung von Rollen

Es gibt insgesamt 69 unzulässige Verschachtelungen für Rollen.
Nach der HTML-Spezifikation ist die unzulässige Verschachtelung von Elementen bereits spezifiziert. Beispielsweise darf in einem Button kein Link stehen. Mit ARIA in HTML wird dieses Konzept auch auf explizit zugewiesene Rollen mit dem role-Attribut erweitert. Wenn innerhalb eines Buttons ein Element die Rolle eines Links erhält:

<button><span role="link">Wie soll das semantisch übersetzt werden?</span></button>

oder wenn ein Button in einem Element mit der Rolle „button“ steht:

<div role="button"><button>Wie soll das semantisch übersetzt werden?</button></div>

sollten Konformitätschecker den Fehler anzeigen. Der W3C Markup Validation Service zeigt solche Fehler an.

The element button must not appear as a descendant of an element with the attribute role=button.

Redundante Rollen

Es gibt zahlreiche unnötige Implementierungen von ARIA. Die Attribute sind oft harmlos. Ein typisches solches Beispiel ist die explizite Zuweisung einer bereits implizit festgelegten Rolle:

<button role="button">Der Button bleibt ein Button</button>

Dieser Schnipsel wird ebenfalls vom W3C Markup Validation Service angezeigt, aber nicht als Fehler, sondern als Warnung. Bei redundanten Rollen handelt es sich in ARIA in HTML um eine nicht normative Anforderung.

The button role is unnecessary for element button.

Bei Warnungen muss der Autor entscheiden, ob der Code korrigiert werden soll, hier: ob das role-Attribut entfernt werden soll. HTML spezifiziert die Rolle bereits für viele HTML-Elemente, und Browser gehorchen in den allermeisten Fällen. Browser weisen ein button-Element die Rolle „button“ zu und leiten diese Information an den Accessibility-Tree des Betriebssystems weiter. Eine explizite Zuweisung der Rolle ist in diesem Beispiel überflüssig.

Redundante ARIA-Attribute

Während bei der Zuweisung einer Rolle mit dem role-Attribut der Wert des role-Attributs Vorrang vor der impliziten Rolle hat, ist das bei sonstigen ARIA-Attributen umgekehrt. Wenn ein HTML- und ein ARIA-Attribut die gleiche Semantik haben, dann hat das HTML-Attribut Vorrang vor dem ARIA-Attribut. Es gibt ein Dutzend Attribute, die in HTML und ARIA vorkommen und für Screenreader die gleiche Bedeutung haben.

Das folgende Beispiel ist nicht eindeutig:

<button disabled aria-disabled="false">Ist das im Screenreader deaktiviert oder nicht?</button>

Das disabled-Attribut ist entscheidend. Der Button wird eingegraut und ist weder per Maus noch per Tastatur aktivierbar. Für Screenreader ist das Element deaktiviert. Das ARIA-Attribut sagt aber das Gegenteil, nämlich dass das Element nicht deaktiviert ist. In solchen Fällen ist auf das ARIA-Attribut zu verzichten.

Dieser Fehler wird aktuell nicht vom W3C Markup Validation Service angezeigt. Das Kriterium ist allerdings an Browser und nicht an Autoren gerichtet. Browser müssen nach ARIA in HTML ein redundantes ARIA-Attribut ignorieren.

Testseite

Die obengenannten Code-Beispiele sind auf folgende Testseite zu finden.

Bookmarklet als Unterstützung

Bei Verwendung des W3C Markup Validation Services müssen die Konformitätsverletzungen, die durch den falschen Einsatz von ARIA entstehen, gesucht werden. Um solche Probleme im Code aufzudecken gibt es ein nützliches Werkzeug. Es handelt sich um ein Bookmarklet namens WAI-ARIA Usage.

Das Bookmarklet zeigt unter anderem auf, wo Rollen und andere ARIA-Attribute auf einer Webseite fehlerhaft eingesetzt werden. Weitere Features zu diesem Helferlein sind im Beitrag Bookmarklet WAI-ARIA Usage von Sylvia Egger beschrieben.

Trotz des Bookmarklets müssen die Anforderungen aus ARIA in HTML grundsätzlich im Browser oder einer anderen App angesehen werden. Dazu müssen Autoren im DOM oder im Accessibility-Tree hineinschauen.

Browser-gestützte Entwicklertools

Alle modernen Browser bieten Entwicklertools an, um Rollen, Namen und Werte von Elementen anzuzeigen:

Desktop-Apps

Die folgenden Apps zeigen den Accessibility-Tree eines Betriebssystems:

Fortschreibung des Webstandards

ARIA in HTML bezieht sich auf ARIA 1.1 (und Digital Publishing WAI-ARIA Module 1.0). Die Spezifikation für ARIA 1.2 steht in den Startlöchern und die ersten Entwürfe für ARIA 1.3 können auch eingesehen werden.

Der Webstandard ARIA in HTML wird weiterentwickelt. Der aktuelle Stand umfasst Weiterentwicklungen aus ARIA 1.2. Beispielsweise dürfen zukünftig bestimmte HTML-Elemente keinen Namen erhalten. Diese Weiterentwicklungen sind notwendig, denn bei der Barrierefreiheit von Widgets gibt es noch eine Menge zu verbessern.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.