Navigation und Service

Einfach teilhaben (Link zur Startseite)


Interaktive Elemente

Interaktive Elemente

Das Internet hat sich im letzten Jahrzehnt sehr gewandelt. Webinhalte werden von Nutzerinnen und Nutzern nicht nur mehr konsumiert. Auf modernen Webseiten können Nutzerinnen und Nutzer eigene Inhalte erzeugen. Im Allgemeinen wird für diese Art "Mitmach-Web" der Begriff "Web 2.0" verwendet.

Die Möglichkeiten die Technologien wie JavaScript, HTML und CSS bieten werden immer intensiver ausgenutzt. Frameworks wie jQuery oder mootools vereinheitlichen und abstrahieren den JavaScript-Code, lösen Browserabhängigkeiten auf und bieten Lösungen komplexer Probleme durch einfache Funktionsaufrufe. Mittlerweile stellen einige Internet-Seiten bereits komplexe Anwendungen dar. Der Begriff "Rich Internet Applications (RIA)" wurde für solche Web-Anwendungen eingeführt.

Aber auch auf einfachen Seiten geht die Interaktion zwischen Mensch und Webseite dabei meist über das Anklicken von Links und das Ausfüllen einfacher Formulare hinaus. Heute kommt kaum eine moderne Seite ohne solche interaktiven Elemente aus. Dazu zählen unter anderem Akkordeons, Tab-Navigationen, Vorhersagen und Vervollständigungen von Eingabefeldern, Überprüfungen von Eingaben in Echtzeit, Karussells, Slideshows, modale Dialoge usw.

Barrierefreiheit

Alle interaktiven Elemente unterliegen der BITV und müssen den BITV-Anforderungen genügen. Zu beachten sind dabei auch die Bedingungen zur BITV-Anforderung 2.2 — "Den Nutzerinnen und Nutzern ist ausreichend Zeit zu geben, um Inhalte zu lesen und zu verwenden".

Eine besondere Problematik tritt bei interaktiven Elementen durch deren Dynamik auf. Unter Dynamik wird hier der aktive Austausch und die Veränderung von Seitenbereichen und Seiteninhalten durch JavaScript-Funktionen verstanden. Dieser Änderungen geschehen, ohne dass die Webseite neu geladen werden muss.

Ein technisches Problem dabei ist, dass eine Leserin oder ein Leser der Webseite diese Veränderung der Informationen nicht unbedingt bemerkt. Dies betrifft vor allem sehbehinderte Menschen, die eine Bildschirmlupe verwenden, oder blinde Menschen, die einen Screenreader oder eine Braille-Zeile nutzen. Gut sehende Menschen werden das Problem eher nicht haben.

Um ein dynamisches Seitenelement zu erzeugen, existieren prinzipiell drei Vorgehensweisen.

  1. Alle Inhalte sind im HTML-Code vorhanden. Inhalte, die nicht sichtbar sein sollen, werden aus dem sichtbaren Bereich der Webseite geschoben. Die Folge ist, dass alle Inhalte auf der Webseite vorhanden sind und von Screenreadern jederzeit vorgelesen werden können.
  2. Alle Inhalte sind im HTML-Code vorhanden. Inhalte, die nicht sichtbar sein sollen, werden mittels der CSS-Eigenschaft display:none oder mit einem anderen Mittel so aus der Webseite entfernt, dass ein Screenreader den Inhalt nicht erreichen und vorlesen kann.
  3. Nur der sichtbare Inhalt ist im Quellcode vorhanden. Bei Bedarf, zum Beispiel nach einer Nutzerinteraktion, wird ein neuer Inhalt vom Server geladen und dargestellt. Der alte Inhalt wird aus der Webseite gelöscht.

Mit allen drei Vorgehensweisen ist es grundsätzlich möglich, barrierefreie interaktive Elemente zu erzeugen. Die Karteikarten-Navigation ("Tab-Navigation") in Kapitel 2 des BITV-Lotsen nutzt zum Beispiel die erste Vorgehensweise:

Die Inhalte der einzelnen Karteikarten sind dabei immer im HTML-Code vorhanden. Wird von einem Screenreader die vollständige Webseite vorgelesen, werden auch alle Inhalte der Karteikarten vorgelesen. Die nicht-sichtbaren Karteikarteninhalte sind lediglich aus dem sichtbaren Bereich des Browsers heraus geschoben. Durch das Klicken auf einen der Karteikartenreiter, wird der Karteikarteninhalt optisch ausgetauscht. Für einen Screenreader ist dieser Klick bzw. die Auswahl des Reiters per Tastatur nur ein normaler Link auf den entsprechenden Seitenbereich. Für einen sehenden und einen nicht-sehenden Menschen sind alle Informationen erreichbar und die Webseite verhält sich wie man es erwarten würde. Die Lösung ist barrierefrei.

Die nächste Abbildung zeigt eine Tab-Navigation aus Kapitel 2 aus der Sicht eines Screenreaders:

Sichtweise eines Screenreaders auf die Tab-Navigation in Kapitel 2 des BITV-Lotsen Sichtweise eines Screenreaders auf die Tab-Navigation in Kapitel 2 des BITV-Lotsen

Die Vorgehensweisen 2 und 3 haben den Nachteil, dass eine Screenreader-Nutzerin oder Nutzer die Änderungen auf den Webseiten nicht ohne Weiteres mitbekommt. An dieser Stelle setzt WAI-ARIA an. Die "Web Accessibility Initiative - Accessible Rich Internet Applications" (WAI-ARIA), eine Empfehlung des W3C, ist eine rein semantische Erweiterung für HTML, die das Layout von Webseiten nicht verändert. Über zusätzliche Attribute werden den HTML-Elementen besondere Bedeutungen und Eigenschaften zugewiesen. So kann ein Bereich der Webseite, der dynamisch verändert wird, durch das Attribut aria-live als "Live Region" gekennzeichnet werden. Die Spezifikation zu WAI-ARIA hat zwar im Moment noch den Status einer "Candidate Recommendation", der letzte Schritt vor einer offiziellen Empfehlung, aber WAI-ARIA wird von den meisten modernen Browsern und Screenreadern bereits unterstützt und die WCAG hat bereits mehrere WAI-ARIA-Techniken offiziell veröffentlicht.

Live Regions

Folgende Anleitung soll die Möglichkeiten erläutern die Sie haben, um dynamische Seitenbereiche, die sogenannten Live Regions, durch die Nutzung von WAI-ARIA-Attribute, für Screenreader-Nutzerinnen und -Nutzer zugänglicher zu machen.

Zunächst müssen Sie den Bereich bestimmen, der dynamisch verändert wird. Dieser Bereich sollte aus nur einem übergeordneten HTML-Element bestehen und nicht aus mehreren einzelnen Elementen. Ein div-Element bietet sich in der Regel dafür an. Das ausgewählte Element muss das aria-live-Attribut zugewiesen bekommen.

Der Wert des Attributs ist abhängig von der Priorität, mit der die Änderungen an die Nutzerinnen und Nutzer weitergegeben werden sollen. Dem Attribut aria-live können folgende drei Werte zugewiesen werden:

  • Durch aria-live="off" bestimmen Sie, dass Änderung nicht an die Nutzerinnen und Nutzer weitergegeben werden. Dies wäre zum Beispiel der Fall, wenn Sie für Ihre Webseite eine Uhr implementiert haben, deren Anzeige sich im Sekundentakt ändert.
  • Mit aria-live="polite" bestimmen Sie, dass eine Änderung erst weitergegeben wird, wenn die Nutzerinnen und Nutzer gerade keine andere Aktion durchführen. Wenn Sie zum Beispiel einen Bereich mit sich aktualisierenden Nachrichten auf Ihrer Webseite haben, können Sie so bestimmen, dass neue Nachrichten erst vorgelesen werden, wenn die Nutzerin oder der Nutzer das Lesen der alten Nachrichten beendet hat.
  • Durch aria-live="assertive" werden Änderungen unmittelbar an die Nutzerin oder den Nutzer weitergegeben. Sinnvoll ist die Priorität zum Beispiel für wichtige Warnungen, auf die die Nutzerin oder der Nutzer sofort reagieren muss.

Wenn dem aria-live-Attribut einmal ein Wert zugewiesen wurde, sollte dieser nicht mehr dynamisch verändert werden. Falls Sie den Inhalt in mehreren Schritten aktualisieren und die Änderungen sollen den Nutzerinnen oder den Nutzern erst nach Abschluss aller Änderungen mitgeteilt werden, können Sie für diese Zeit das Attribut aria-busy verwenden. Solange für das Attribut der Wert true gesetzt ist, werden weder bei aria-live="assertive" noch bei aria-live="polite" Änderungen an die Nutzerinnen und Nutzer weitergegeben. Erst, wenn das Attribut aria-busy wieder auf false gesetzt oder komplett gelöscht wird, werden die Änderungen wieder weitergegeben.

Die nächste Entscheidung, die getroffen werden muss, ist folgende: Soll bei einer Änderung in der "Live Region" der gesamte Bereich erneut vorgelesen werden oder reicht es, wenn nur die Veränderung vorgelesen wird?

  • Mit aria-atomic="false" sorgen Sie dafür, dass nur der veränderte Bereich der Nutzerin oder dem Nutzer vorgelesen wird. Wenn Sie zum Beispiel einen Live-Ticker entwickelt haben, wäre dies die richtige Einstellung, um zu verhindern, dass bei einer neuen Nachricht auch die bereits vorgelesenen alten Nachrichten erneut vorgelesen werden.
  • aria-atomic="true" sorgt hingegen dafür, dass immer der gesamte Bereich der "Live Region" vorgelesen wird. Dies kann zum Beispiel dann wichtig sein, wenn die Information der Veränderung alleinstehend ohne den gesamten Kontext des Bereichs nicht verständlich wäre.

Als Letztes müssen Sie noch bestimmen, welche Art von Änderungen überhaupt relevant sind, damit sie der Nutzerin oder dem Nutzer mitgeteilt werden. Durch Änderungen können zum Beispiel Elemente hinzugefügt oder gelöscht werden und es können ebenso Inhalte von Elementen verändert werden. Natürlich können auch mehrere Arten von Änderungen gleichzeitig relevant sein. Welche Arten von Änderungen relevant sind, können Sie mit dem aria-relevant-Attribut bestimmen.

  • aria-relevant="additions": Das Hinzufügen neuer Elemente ist relevant und sollte der Nutzerin oder dem Nutzer mitgeteilt werden. Beispiel: Eine Webseite beinhaltet einen Newsticker. Nur das Einfügen neuer Nachrichten ist relevant.
  • aria-relevant="removals": Das Löschen alter Elemente ist relevant und sollte der Nutzerin oder dem Nutzer mitgeteilt werden. Beispiel: Auf einer Webseite werden alle Teilnehmerinnen und Teilnehmer eines Chats angezeigt. Verlässt eine Nutzerin oder Nutzer einen Chat, ist das eventuell eine wichtige Information und diese sollte weitergeleitet werden.
  • aria-relevant="text": Nur die Änderung von Text in einem Bereich ist relevant. Ein Beispiel wären Statusmeldungen auf Webseiten. Listet eine Webseite zum Beispiel die Anwesenheit von Mitarbeitern auf und es ändert sich der Inhalt einer Statusmeldung, ist diese Änderung relevant. Hinweis: Auch der Alternativtext einer Grafik im alt-Attribut des img-Elements gehört zu den hier angesprochenen Texten.

Sind mehrere Arten von Änderungen relevant, können die Werte auch zusammen durch ein Leerzeichen getrennt als Attributwert angegeben werden (zum Beispiel: aria-relevant="additions removals"). Durch den Wert aria-relevant="all" gelten alle drei Änderungsarten als relevant.

Folgendes Beispiel zeigt die Vergabe der "Live Region"-Eigenschaften für einen typischen Chat-Bereich auf einer Webseite:

<div id="chat" aria-live="polite" 
     aria-atomic="false" aria-relevant="additions">
   <ul>
      <li>
         <span class="member">Person A</span>
         <span class="text">Hallo</span>
      </li>
      ...
   </ul>
</div>

Ein Screenreader, der die Webseite mit dem Chat vorliest, soll sich demnach wie folgt verhalten:

  • Änderungen sollen der Nutzerin oder dem Nutzer erst mitgeteilt werden, wenn diese gerade nichts Anderes machen und sich auch nichts Anderes vorlesen lassen (aria-live="polite").
  • Es sollen Ihr oder Ihm nur die sich veränderten Elemente vorgelesen werden (aria-atomic="false").
  • Nur hinzugefügte Elemente sind relevant und sollen das Vorlesen auslösen (aria-relevant="additions").

Weiterführende Informationen

Untersuchungen zu einigen interaktiven Elementen finden Sie hier:

© Bundesministerium für Arbeit und Soziales