Registernavigation für das Web veröffentlicht in 2015

eine Registernavigation besteht aus einer Registerleiste mit mehreren (horizontal oder vertikal angeordneten) Reitern und einem Anzeigebereich für die Inhalte (Registerseite). Nutzer können die Reiter einzeln aktivieren, wobei der zugehörige Inhalt in der Registerseite eingeblendet wird; die zuvor angezeigte Registerseite wird gleichzeitig ausgeblendet. Die Registerseiten können dabei verschiedenartige Inhalte besitzen.

Registernavigation mit Registrierung, Anmeldung und Passwort vergessen Funktion

Registernavigationen können mit HTML semantisch nicht abgebildet werden, d.h. in der Praxis werden diverse HTML-Konstrukte eingesetzt und die Funktionalität wird mit JavaScript hinzugefügt. Damit sich Registernavigationen wie vergleichbare Komponenten des Betriebssystems verhalten und mit Screenreadern oder mit der Tastatur auf ähnliche Weise bedient werden können, muss das HTML mit Accessible Rich Internet Applications (ARIA) ergänzt werden. Zunächst geht es um die Zuweisung der Semantik mit dem role-Attribut:

role="Tablist" für die Registerleiste
role="Tab" für die einzelnen Reiter
role="Tabpanel" für die Registerseiten

Nur mit diesen Rollen können Browser die Komponenten korrekt identifizieren und über den Accessibility-Tree für Screenreader und andere Hilfsmittel semantisch identifizierbar machen.

Darüber hinaus — da es sich um ein dynamisches Widget handelt — muss ein Fokus-Management für die Tastaturbedienung bereitgestellt werden. Es geht darum, dass ein Event-Handling implementiert wird, welches die Bedienung der Reiter mit Pfeiltasten ermöglicht.

Erforderliche Attribute

Eine Registernavigation benötigt neben den drei Rollen tablist, tab und tabpanel weitere Attribute, um sinnvoll in einem Screenreader bedient werden zu können. Die Rollen selbst ermöglichen es Screenreadern, einerseits die Reiter als Steuerelemente (Formularelemente) zu behandeln und andererseits sowohl Reiter als auch Registerseiten dem Nutzer textlich zu beschreiben. Weitere erforderliche Attribute für Registernavigationen sind:

Tabindex mit den Werten 0 oder -1 ist Grundlage für das Fokus-Management in der Reiterleiste.
aria-selected="true" wird für den aktivierten Reiter benötigt (nicht aktivierte Reiter benötigen hingegen aria-selected="false").
aria-controls ermöglicht den Sprung von einem Reiter direkt zur zugehörigen Registerseite.
aria-hidden="true" kann dafür genutzt werden, die ausgeblendeten Registerseiten aus dem Accessibility-Tree zu entfernen (Alternativen sind das HTML-Attribut hidden und die CSS-Eigenschaft display:none;).

Darüber hinaus benötigen die Registerseiten eine Beschriftung. Weil die Reiter i.d.R. die Beschriftung für die Registerseiten bereits liefern, kann die Beschriftung mit einem aria-labelledby-Attribut mit der zugehörigen Registerseite verknüpft werden.

Der Einsatz des Aria-activedescendant-Attributs ist nach der ARIA-Spezifikation auch für den Fokus-Management innerhalb eines Tablist vorgesehen, aber die Technik ist ausschließlich für Screenreader und nicht allgemein per Tastatur zugänglich.

HTML-Gerüst

Der Weg zu einer barrierefreien Registernavigation ist variabel. Entscheidend für die Zugänglichkeit ist letztlich das JavaScript. Die Rollen und weiteren Attribute müssen dynamisch korrekt aktualisiert werden. Die Anforderungen an das HTML sind hingegen zweitrangig:

Die Frage, ob das Grundgerüst mit HTML sinnvoll sein soll oder ob Tabpanels vollständig mit JavaScript erzeugt werden, ist grundsätzlich ohne Belang, denn eine Registernavigation funktioniert nur mit aktiviertem JavaScript. Dennoch gibt es Situationen, in denen es vorteilhaft ist, ein sinnvolles HTML-Grundgerüst bereit zu stellen.
Ein sinnvolles Grundgerüst im HTML kann verschiedenartig aussehen:
- Die designierten Reiter können als Liste aufbereitet werden, gefolgt von DIV-Elementen mit den Inhalten der Registerseiten.
- Anstatt einer einfachen Liste kann eine Linkliste für die Reiter eingesetzt werden.
- Eine Registernavigation kann aus einer Überschriften-Absatz-Abfolge oder einer Definitionsliste erstellt werden, wobei die Überschriften resp. die Begriffe als Reiter und die Absätze resp. Definitionen zu Registerseiten mit dem role-Attribut umdefiniert werden.
- Auch FIELDSET-Elemente können die Grundlage für Reiter (LEGEND-Element) und Registerseiten liefern, ebenso wie FIGURE-Elemente im Zusammenspiel mit FIGCAPTION-Elementen.

Es stehen einige Beispiele zur Verfügung (siehe oben in der Navigation oder unten in der Übersicht der Beispiele). Sie unterscheiden sich im Wesentlichen durch das HTML-Grundgerüst. Dabei gibt es selbstverständlich kleinere Unterschiede im JavaScript und im CSS.

Letztlich ist es nicht entscheidend, wie das HTML-Grundgerüst aussieht, solange es eine sinnvolle Struktur darstellt. Wichtig ist hingegen, wie das Ergebnis nach der Verarbeitung mit JavaScript ist. Die Registernavigation muss nach der Verarbeitung mit JavaScript dem folgenden Muster folgen:

<div class="register"> <element role="tablist"> <element role="tab" aria-selected="true" aria-controls="id1" tabindex="0" id="beschriftung-id1">Beschriftung 1</element> <element role="tab" aria-controls="id2" tabindex="-1" id="beschriftung-id2">Beschriftung 2</element> <element role="tab" aria-controls="id3" tabindex="-1" id="beschriftung-id3">Beschriftung 3</element> ... </element> <element role="tabpanel" aria-labelledby="beschriftung-id1" id="id1"> <p>Inhalt für Registerseite 1.</p> </element> <element role="tabpanel" aria-hidden="true" aria-labelledby="beschriftung-id2" id="id2"> <p>Inhalt für Registerseite 2.</p> </element> <element role="tabpanel" aria-hidden="true" aria-labelledby="beschriftung-id3" id="id3"> <p>Inhalt für Registerseite 3.</p> </element> ... </div>

Die Zuweisung von Rollen definiert die Semantik eines Elements neu, unabhängig davon, ob es ein Linktext oder eine Bildunterschrift ist: Wenn ein Element die Rolle tab erhält und dieser Reiter in einem weiteren Element mit der Rolle tablist enthalten ist, dann ist das Element im Accessibility-Tree und somit auch in Hilfsmitteln wie Screenreader ein Reiter. Im DOM hingegen bleibt die ursprüngliche Semantik des Elements erhalten.

Hinweis: Der Einsatz von ARIA beeinflusst die visuelle Darstellung und das JavaScript in keiner Weise. Die ARIA-Attribute stellen lediglich Anweisungen an den Browser dar, wie sie Datenstrukturen in den Accessibility-Tree ablegen sollen.

Fokus-Management

Die Bedienung eines Widgets per Tastatur erfolgt mit JavaScript. Genauer gesagt, muss ein Fokus-Management implementiert werden. In einem ergänzenden Dokument zur ARIA-Spezifikation werden Extern, englischsprachig: Empfehlungen für das Fokus-Management gegeben; dort wird beschrieben, welche Tastenbefehle für ein bestimmtes Widget berücksichtigt werden sollten.

Bei Registernavigationen (Tabpanels) geht es im Wesentlichen um folgende zwei Aspekte:

In der Reiterleiste darf nur der aktivierte Reiter in der Fokus-Reihenfolge stehen.
Die Aktivierung eines Reiters (und Einblendung der zugehörigen Registerseite) per Tastatur erfolgt, indem zuerst der bislang aktivierte Reiter fokussiert und anschließend ein anderer Reiter mit den Pfeiltasten fokussiert und mit der Leertaste aktiviert wird.

Darüber hinaus ist es für die Tastaturbedienung vorteilhaft, wenn die Registerseite bzw. ihre Inhalte fokussiert werden können.

Reiter

In einer Registernavigation darf nur ein Reiter in der Fokus-Reihenfolge stehen. Um das zu erreichen, gibt es verschiedene Vorgehensweisen:

Die Reiter können ursprünglich Links sein, d.h. sie stehen zunächst alle in der Fokus-Reihenfolge. Dann muss gewährleistet werden, dass die nicht aktivierten Reiter ein tabindex="-1" besitzen. Wenn ein Reiter aktiviert wird, müssen die tabindex-Attribute der Links aktualisiert werden.
Die Reiter sind ursprünglich keine aktiven Elemente. Die Vorgehensweise ist wie in der ersten Situation, nur muss zusätzlich der aktive Reiter ein tabindex-Attribut mit dem Wert 0 erhalten, damit es in der Fokus-Reihenfolge steht.
Eine weitere Möglichkeit besteht darin, nur die Registerleiste in die Fokus-Reihenfolge aufzunehmen und mit dem aria-activedescendant-Attribut auf den aktiven Reiter zu zeigen. In diesem Fall erhält das Element mit der Rolle tablist einen tabindex="0" und alle Reiter ein tabindex="-1". Aktualisiert wird der Wert von aria-activedescendant mit der ID des aktivierten Reiters.

Wie oben bereits erwähnt, führt die Technik mit aria-activedescendant nicht zu einer allgemeinen Tastaturbedienbarkeit. Deshalb sollte eine der ersten beiden Techniken für das Fokus-Management eingesetzt werden.

Im Übrigen gibt es keine Argumente, die die eine oder die andere der ersten beiden Techniken favorisieren, sondern es hängt lediglich vom HTML-Grundgerüst ab. In beiden Fällen müssen bei Aktivierung eines Reiters sowohl das tabindex- als auch das aria-selected-Attribut für alle Reiter aktualisiert werden.

Der zweite Teil des Fokus-Managements ist die Implementierung von Tastenbefehlen, um den Fokus innerhalb der Registernavigation zu verändern. Die wichtigsten Tastenbefehle sind:

Pfeil nach rechts: Der Fokus wird auf den nächsten Reiter der Registerleiste gesetzt.
Pfeil nach links: Der Fokus wird auf den vorherigen Reiter der Registerleiste gesetzt.
Leertaste: Der fokussierte Reiter wird aktiviert und die zugehörige Registerseite wird eingeblendet.

Darüber hinaus können weitere Tastenbefehle berücksichtigt werden, etwa Pos1, um zum ersten Reiter zu gelangen, oder Ende, um den Fokus auf den letzten Reiter zu setzen. Die Tastenbefehle dürfen im Übrigen nur dann eine Aktion auslösen, wenn der Fokus auf einem Reiter steht.

Schließlich kann das aria-controls-Attribut für die einzelnen Reiter vergeben werden. Dieses Attribut verweist auf die zugehörige Registerseite und erlaubt es, in einem Schritt einen Reiter zu aktivieren und den Fokus auf die zugehörige Registerseite zu setzen. Leider wird dieses Attribut nur vereinzelt unterstützt.

Registerseiten

Ein Fokus-Management innerhalb einer Registerseite ist nicht immer zweckmäßig. In manchen Situationen kann es sinnvoll sein, etwa wenn häufiges Wechseln der Ansichten erwartet werden kann. Die ARIA-Empfehlungen für die Implementierung sehen dabei folgende Tastenkombinationen vor:

Strg+Pfeil nach oben: setzt den Fokus aus der Registerseite zum zugehörigen Reiter.
Strg+SeiteAuf: setzt den Fokus auf den vorherigen Reiter.
Strg+SeiteAb: setzt den Fokus auf den nächsten Reiter.

Diese Tastenkombinationen können selbstverständlich nur dann ausgeführt werden, wenn sich der Fokus auf der Registerseite oder ihrer Inhalte befindet. Sofern keine Links oder andere Formularelemente in der Registerseite enthalten sind, erübrigt sich die Implementierung der Tastenkombinationen. Alternativ kann die Registerseite selbst mit dem tabindex-Attribut fokussierbar gemacht werden, was den zusätzlichen Nutzen bringt, dass bei Drücken der Tab-Taste die Registerseite nicht übersprungen wird.

Beim Einsatz eines Screenreaders funktionieren die Tastenkombinationen für Registerseiten im Übrigen nicht, weil sie sowohl im Lesemodus als auch im Fokus- bzw. Formularmodus vom Screenreader belegt sind. Diese Einschränkung gilt nicht für die Tastenbefehle für die Registerleiste.

Hinweise zu Screenreadern

Beim Fokus-Management müssen zwei Situationen unterschieden werden, wenn es um die Nutzbarkeit in Screenreadern geht:

Screenreader verfügen über einen Lesemodus, um Inhalte zu lesen. In diesem Modus stellt der Screenreader ein erweitertes Bedienkonzept zur Verfügung, das selbstverständlich per Tastatur gesteuert wird. Das Drücken der Taste "H" bedeutet beispielsweise "Springe zur nächsten Überschrift" und die Tastenkombination Strg+PfeilOben bedeutet "Springe zum vorherigen Blockelement".
Screenreader verfügen darüber hinaus über ein Anwendungsmodus (auch Fokus- bzw. Formularmodus genannt), damit Nutzer Eingaben vornehmen können. In diesem Modus wird das erweiterte Bedienkonzept abgeschaltet.

Der entscheidende Unterschied dieser beiden Modi ist, dass im Lesemodus jegliche Tastenbefehle vom Screenreader abgefangen werden. Nur einige wenige Tastenbefehle werden überhaupt an den Browser durchgereicht (wie z.B. Eingabe-, Leer- oder Tab-taste). Erst im Anwendungsmodus werden die meisten Tastenbefehle an den Browser durchgelassen.

Das Fokus-Management für die Registerleiste funktioniert nur deswegen, weil die Reiter in dem Accessibility-Tree als Steuerelemente abgelegt werden. Screenreader behandeln Elemente mit role="tab" wie Formularelemente, d.h. sie wechseln automatisch in den Anwendungsmodus, wenn ein Reiter fokussiert wird.

Während die Tastenkombinationen für die Registerseite grundsätzlich bei Formularelementen funktionieren, gibt es keine Technik, die sie mit vertretbarem Aufwand für Screenreadernutzer auch bei Links und anderen fokussierbaren Inhalten verfügbar machen könnte. Sicher, Screenreadernutzer können den Anwendungsmodus manuell einschalten oder das Durchreichen einer Tastenkombination erzwingen, aber damit sind andere Nachteile verbunden. Aus diesem Grund besitzen die oben in der Navigation und unten in der Übersicht aufgeführten Beispiele zusätzlich noch einen Shortcut mit dem accesskey-Attribut, der es unabhängig vom Anwendungsmodus erlaubt, zum aktivierten Reiter zurückzuspringen.