Webseiten sind keine Anwendungen  

Wie Sie Screenreadernutzer mit role=“application“ so richtig aus den Tritt bringen

Bewegungsablauf einer stolpernden Figur in 5 Schritten

Mit ARIA können Widgets eine Semantik erhalten, die von Screenreadern verarbeitet werden kann. Beispielsweise gibt es in HTML keine Registernavigationen mit Reitern. Die Semantik einer Registernavigation wird mit role=“tablist“ bestimmt und die Semantik eines Reiters mit role=“tab“. Was ist aber mit role=“application“?

Bei der Erstellung von Gutachten zur Barrierefreiheit von komplexen Anwendungen treffe ich immer wieder auf das gleiche Problem. Die Anwendung ist in sich recht fortgeschritten und einzelne Widgets (wie zum Beispiel sortierbare Tabellen, Akkordeons oder Menüs) werden mehr oder weniger mit ARIA und einem Fokus-Management gut ergänzt – eine Bedienung der Widgets ist oft mit einem Screenreader möglich. Die Navigation innerhalb der Seite von Widget zu Widget oder bei Fließtexten ist gleichzeitig katastrophal.

Die Ursache für diese Problematik ist immer ein role=“application“ auf dem <body>-Element. Um es auf den Punkt zu bringen: Webseiten sind keine Widgets, sondern sie bestehen aus Widgets.

Widgets

Die Rolle „application“ definiert nach der ARIA-Spezifikation ein Widget, das durch die anderen Rollen nicht abgebildet werden kann. Es gibt Rollen für alle möglichen Komponenten einer Webseite, aber bestimmte Komponenten wie ein Editor oder ein Spiel werden nicht von den „widget roles“ abgedeckt. Solche Spezialfälle sind ein Fall für role=“application“.

Ein Widget ist eine Komponente der Benutzungsschnittstelle mit diskreten Zuständen, und mit der ein Nutzer interagieren kann. Widgets gibt es als einfache Komponenten (wie eine Checkbox oder ein Link) bis hin zu komplexen Komponenten, die weitere Komponenten managen (zum Beispiel Baumstrukturen oder Grids).

Eine Webseite mit einem Formular oder mit Prozessen in einer E-Akte sind aber keine Widgets. Ein Formular oder ein Prozess mit Formularen besteht aus einzelnen Widgets. Eine Checkbox ist aktiviert oder nicht aktiviert und ein Menüeintrag mit Unterpunkten ist zugeklappt oder aufgeklappt. Welche derartigen Zustände gibt es für Webseiten als Ganzes? Selbstverständlich sind Webseiten „vollständig geladen oder „nicht vollständig geladen“, aber solche Zustände erfordern keine Nutzeraktion. Bei Widgets kommt es darauf an, dass einzelne Zustände einer Komponente durch Nutzer geändet werden.

Das Problem

Sie könnten jetzt fragen, was denn das Problem eigentlich sei. Die Antwort ist relativ einfach: Mit role=“application“ werden die Navigationsmechanismen eines Screenreaders abgeschaltet. Zusammengefasst bedeutet das:

  1. Sämtliche Navigationsmöglichkeiten eines Screenreaders (zum Beispiel Drücken der Taste „H“, um die nächste Überschrift anzuspringen) funktionieren nicht mehr.
  2. Screenreadernutzer können meist nur per Tab-Taste (und weiteren Browserfunktionen) navigieren. Dabei werden nur fokussierte Texte oder verknüpfte Texte (z.B. das <label> Element für Formularelemente) per Sprachausgabe vorgelesen oder per Braille-Zeile angezeigt.
  3. Wenn für einzelne Widgets ein Fokus-Management autorenseitig implementiert wurde, können Widgets mit einem Screenreader bedient werden.
  4. Andere nicht fokussierbare oder nicht verknüpfte Texte (Fließtexte, Anweisungen und so weiter) werden vom Screenreader nicht gelesen.

Zugegebenermaßen decken die Web Content Accessibility Guidelines (WCAG) 2.1 den Umgang eines Screenreaders mit bestimmten Code nicht ab, und es wird Webseiten mit einem role=“application“ geben, die WCAG-konform sind. Aber das dauerhafte Abschalten der Navigationsmechanismen eines Screenreaders kann trotzdem nicht als „nutzbar“ oder „barrierefrei“ bezeichnet werden. Das ist vergleichbar mit einer Deaktivierung der Mausbedienung.

Vor allem bei solchen Widgets, die eine Nutzereingabe erfordern (zum Beispiel Texteingabe oder Bedienung mit Pfeiltasten), reicht ein Screenreader die Tastendrücke automatisch durch. Voraussetzung ist, dass die Widgets eine korrekte Semantik gemäß ARIA-Spezifikation aufweisen.

ARIA ist Stand der Technik

In diesem Zusammenhang bin ich ganz dankbar für die neue „Barrierefreie-Informationstechnik-Verordnung – BITV 2.0“, die seit Mai 2019 in Deutschland gilt. Sie besagt, dass Webseiten und Intranets

  1. die Erfolgskriterien der WCAG 2.1 auf Stufe AA erfüllen müssen und
  2. nach dem Stand der Technik erstellt werden müssen.

Der Stand der Technik muss nach der BITV 2.0 noch von einem Ausschuss dokumentiert werden, aber der richtige Einsatz von ARIA muss dann zum Stand der Technik gehören.

Schreibe einen Kommentar

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