Neues in ARIA 1.1 #4 role=“application“ ist jetzt Teil der Dokumentenstruktur (und keine Region)

Das Wort Application gelegt mit Scrabble-Steinen in Spiegelschrift

Die Rolle „application“ wird viel zu oft auf Webseiten eingesetzt. Eigentlich gibt es kaum Fälle, in denen die Rolle berechtigt ist – bestimmte komplexe Anwendungen wie ein Editor oder Widgets, die nicht mit einem der zahlreichen widget roles aus Accessible Rich Internet Applications (ARIA) abgebildet werden können, kommen in Frage. Die Rolle „application“ schränkt in den meisten Fällen die Barrierefreiheit einer Anwendung sehr stark ein.

Mir ist die Begründung nicht bekannt, warum die Rolle „application“ in ARIA 1.1 eine Dokumentenstruktur und keine Seitenregion mehr darstellen soll. Im Prinzip ist es auch egal, denn fast immer gehört die Rolle nicht auf eine Webseite. Das möchte ich zum Anlass nehmen, die Grundproblematik zu erläutern.

Hintergrund

Screenreader verfügen über verschiedene Modi, um in verschiedenen Situationen die beste Zugänglichkeit zu ermöglichen. Obwohl Screenreader meist über mehr als zwei Modi verfügen, ist die folgende Unterscheidung wichtig:

  • Lesemodus: In Lesemodi werden alle Inhalte gelesen. Um im Inhalt zu navigieren wird die Tastatureingabe größtenteils vom Screenreader abgefangen und nicht an den Browser durchgereicht. Bei der Mehrzahl der Tastenschläge handelt es sich um Befehle an den Screenreader, irgendetwas auf der Webseite zu tun (z.B. oft führt das Drücken der Taste „H“ zu einem Sprung zur nächsten Überschrift).
  • Bedienmodus: Bei Formularen und Anwendungen müssen die Tastenbefehle an den Browser durchgereicht werden – sei es bei der Eingabe in einem Formular oder bei der Bedienung von Widgets per Tastatur. Ein Screenreader kann in solchen Situationen keine strukturelle Navigation mehr anbieten. Die Bedienung der Webseite erfolgt „nur“ mit den Tastenbefehlen, die ein Browser bietet.

Die Bestimmung einer Webseite oder eines Teilbereichs der Webseite als „application“ erzwingt den Bedienmodus (und deaktiviert zwangsläufig die strukturelle Navigation des Screenreaders). Folglich können nur noch aktive Elemente wie Links oder Formulare per Tab-Taste erreicht und mit der Eingabetaste bedient werden. Andere Texte können in einem Screenreader generell nicht mehr gelesen werden.

Richtige Rollen und Fokus-Management

Durch den unvorsichtigen Einsatz der Rolle „application“ wird die Barrierefreiheit von Anwendungen stark beeinträchtigt, wenn kein alternatives Bedienkonzept für Tastaturnutzer und insbesondere Screenreader-Nutzer autorenseitig bereitgestellt wird. Für viele „Anwendungen“ gibt es widget roles, aber auch dort kommt die Tastaturbedienung nicht „out of the box“. Vielmehr müssen die benötigten Tastenschläge per JavaScript mit einem Fokus-Management abgefangen werden.

Wenn es für eine bestimmte Anwendung innerhalb einer Webseite keine widget role oder Kombination von widget roles gibt kann role=“application“ eingesetzt werden. Damit muss die Tastaturbedienung sowie die Zugänglichkeit sämtlicher Inhalte autorenseitig gelöst werden:

  1. Generell können Screenreader nur diejenigen Inhalte erreichen, die in der Fokus-Reihenfolge stehen. Texte, die nicht in der Fokus-Reihenfolge stehen, müssen mit aria-labelledby oder aria-describedby mit fokussierbaren Inhalten verknüpft werden.
  2. Texte, die nicht mit einem aktiven Element verknüpft sind, müssen in einem fokussierbaren Element mit der Rolle „document“ oder „article“ stehen.
  3. Ein Fokus-Management muss implementiert werden, das die Navigation des Screenreaders ersetzt.
  4. Wenn eine Anwendung innerhalb einer Webseite vorkommt, so müssen Screenreader diese identifizieren können. Dafür muss der Bereich der Seite mit der Rolle „application“ (mit aria-label oder aria-labelledby) bezeichnet werden.

Lasst es weg

Auf manchen Webseiten wird die Rolle „application“ auf das <body> Element angewandt. Der Fall, dass eine Webseite nicht mit anderen Dokumentenstrukturen und Widgets aufgebaut werden kann, dürfte in der Praxis nicht so oft vorkommen. Die Komponenten einer Anwendung sind i.d.R. normale Steuerelemente, die mit HTML abgebildet werden können, oder sie lassen sich mit widget roles sinnvoll aufbauen. Und auch wenn es Regionen einer Seite gibt, die erst mit der Rolle „application“ semantisch richtig bestimmt werden, so wird das meistens nur ein Teilbereich der Webseite sein.

Daher sollte die Rolle „application“ immer nur als letzte Möglichkeit genutzt werden. Diese Möglichkeit ist sicher auch einer der schwierigsten zu lösende Alternativen, wenn es um die barrierefreie Gestaltung von Webanwendungen geht, denn das Fokus-Management muss nicht nur für die Tastaturbedienung allgemein, sondern in zahlreichen Screenreader-Browser-Kombinationen funktionieren.

Dieser Beitrag ist Teil einer mehrteiligen Serie zu Aria 1.1:

Schreibe einen Kommentar

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