Register-Elemente

Register-Elemente (tabbed interfaces) stapeln Informationen wie ein Stapel Karteikarten. Die Auswahl eines Registers zeigt die zugehörige Karte (das tab panel).

Ein Register-Element in Aktion

Das folgende Video zeigt ein typisches Register-Element in Aktion. Der Screenreader NVDA ist angeschaltet, um die nicht-visuelle Nutzererfahrung zu zeigen.

Video -Beschreibung

Auf einer Seite der Website sas.com zeigt ein Register-Element verschiedene Daten-Visualisierungen.

  • Der Nutzer tabbt zu dem ersten Tab in der Tab-Liste, die "Registerkarte" ausgibt.
  • Dann gibt der Screenreader den Namen des Tabs aus ("Net Operating Income"), gefolgt von der Rolle (tab) und dem Zustand bzw. der Gesamtanzahl von Tabs in der Tab-Liste.
  • Der Nutzer gebraucht nun die rechte Pfeiltaste → , um den nächsten Tab zu fokussieren.
  • Der Nutzer drückt ENTER, um den fokussierten Tab auszuwählen und das dazugehörige Tabpanel anzuzeigen.

Verschiedene Arten von Register-Elementen

Es gibt grundsätzlich zwei verschiedene Arten von Register-Elementen: Solche mit automatischer Aktivierung, und solche mit manueller Aktivierung. Wenn ein Register-Element automatische Aktivierung nutzt, dann führt das Fokussuieren eines Tabs direkt zur Anzeige des fdazugehörigen Panels. Bei der manuellen Aktivierung dagegen muss der Nutzer erst den ausgewählten tab über ENTER) aktivieren, um das dazugehörige Tabpanel aufzurufen.

Es gibt noch eine andere wichtige Unterscheidung. Sie können Register-Elemente gemäß den ARIA-Empfehlungen erstellen, sodass sie sich wie Register-Elemente in Software verhalten. In diesem Fall werden die Registerkarten mit der Pfeiltaste und nicht mit der Tabulatortaste fokussiert. Oder Sie können Registerkarten als eine Liste von Links (oder Schaltflächen) implementieren, die mit der Tabulatortaste fokussiert werden können. Dies ist immer noch das bei weitem häufigere Tastaturverhalten von Register-Elementen im Internet.

Typische Nutzungsprobleme bei Register-Elementen

Registerkarten sind für viele Benutzer schwierig zu handhaben.

Verstehen, dass die Pfeiltasten zum Fokussieren der Registerkarten verwendet werden

Wenn Tastaturbenutzer mit dem Fokus auf ein  Register-Element erreichen, das gemäß den Aria Authoring-Practices 1.1 erstellt wurde, wird bei den Reitern standardmäßig der erste (oder der letzte zuvor ausgewählte) Reiter angezeigt. Die Fokussierung der übrigen Reiter erfolgt dann über die Pfeiltasten ← →. Benutzer können nicht erkennen, dass sie zu den Pfeiltasten wechseln müssen, insbesondere wenn eine Oberfläche nicht wie ein Register-Element aussieht. Webautoren reagieren manchmal auf dieses Usability-Problem, indem sie die einzelnen Registerkarten auch über die Tabulatortaste ⇥ auswählen können.

Dies kann jedoch auch zu Problemen führen, wenn der aktuell angezeigte Inhaltsbereich fokussierbare Elemente enthält, die dann nicht unmittelbar nach dem ausgewählten Reiter fokussiert würden. Der Fokus würde erst die übrigen Reiter durchlaufen, bevor er im Inhaltsbereich landet. Vergleiche Heydon Pickerings Hinweise zum Tastaturverhalten bei Tabbed Interfaces.

Umgang mit dem Screenreader bei der Interaktion mit Register-Elementen

Wie Alastair Campbell hervorgehoben hat, zeigen Usability-Tests, dass viele Nutzer des Screenreader ohne besondere Expertise nicht mit dem Konstrukt von ARIA-Tabs vertraut sind (weil konforme Implementierungen in öffentlichten Webinhalten recht selten sind). Einige Benutzer verwechseln die Tabs bzw. Reiter (die Elemente mit der Rolle tab) mit der Tab-Aktion (mit der Tabulatortaste), was bei konformen Implementierungen nicht zur nächsten Registerkarte führt.

Mögliches Verpassen von Inhalten in verborgenen Registerkarten

Wenn Register-Elemente nicht gemäß der ARIA-Spezifikation umgesetzt sind, können blinde Benutzer möglicherweise nicht erkennen, auf welche Art von Inhalt sie gestoßen sind, und können so den Inhalt in den derzeit ausgeblendeten Registerkarten verpassen. Dasselbe Problem kann auftreten, wenn Benutzer auf älteren Systemen mit älteren Browsern oder älteren unterstützenden Technologien arbeiten, bei denen die ARIA-Rollen möglicherweise nicht verfügbar sind.

Sichtbare Panel-Inhalte umgehen

Ein weiteres Problem besteht darin, dass manche Screenreader-Nutzer den Inhalt des sichtbaren Bereichs verpassen und überspringen, insbesondere wenn keine fokussierbaren Elemente darin sind. Wenn sie die Liste von Reitern (tablist) erreichen, wechselt der Screenreader meist in den Formularmodus. Um den Panel-Inhalt zu lesen, müssen Benutzer wieder in den Lesemodus wechseln. JAWS hat einen Kutrzbefehl, um zum zugehörigen Panel zu springen, nicht aber andere Screenreader wie NVDA und VoiceOver. Wenn Nutzer nach Erreichen des Register-Elements weiter tabben, springen sie zum ersten interaktiven Inhalt nach dem Panel, wenn dieses keine fokussierbaren Inhalte enthält. Deshalb empfehlen manche Autoren, das Panel selbst fokussierbar zu machen. Ein einfacher Weg wäre die Verwendung von tabindex = "0" im Panel. Viele raten jedoch davon ab, nicht interaktive Elemente über den Tabulatortaste fokussierbar zu machen. Eine Alternative ist die Verwendung von tabindex = "- 1" auf der Registerkarte und die programmgesteuerte Versetzung des Fokus. Der Beitrag zu tabbed interfaces von Heydon Pickering empfiehlt die Implementierung der Abwärtspfeiltaste, um den Fokus auf das Bedienfeld zu verschieben.

Lineare Leseprobleme

Benutzer, die Inhalte im Browsermodus eines Screenreaders oder mit ihrem eigenen CSS linear von oben nach unten lesen, sehen in der Regel zuerst die Registerkarten in einem Abschnitt, gefolgt von den Bedienfeldinhalten in einem separaten Abschnitt. Dadurch kann es schwierig werden, Registerkarten und entsprechenden Bedienfeldinhalt zuzuordnen. Ein nicht ARIA-basierte Alternative, um die lineare Anordnung der Inhalte zu verbessern, ist die Umsetzung von Reitern als Sprunglinks zu Überschriften in den zugehörigen Registerkarten.

Einige Tastaturbenutzer (insbesondere blinde Benutzer) stoßen auf Probleme beim Bedienen von Register-Elementen. Wenn sie nach Best-Practice-Empfehlungen erstellt sind, wird beim Hinein-Tabben standardmäßig der erste (oder der zuletzt ausgewählte) Tab fokussiert. Weitere Tabs in der Tab-Liste werden dann über die Pfeiltasten → selektiert. Benutzer erkennen möglicherweise nicht, dass sie zu den Pfeiltasten wechseln müssen, besonders wenn eine Register-Element nicht deutlich wie eines aussieht. Oft reagieren Webautoren auf dieses bekannte Usability-Problem, indem sie die einzelnen Tabs auch über die Tabulatortaste ⇥ fokussierbar machen.

Dies kann jedoch auch zu Problemen führen, wenn der aktuell angezeigte Inhaltsbereich fokussierbare Elemente enthält, die dann nicht unmittelbar nach dem ausgewählten Reiter fokussiert würden. Der Fokus würde erst die übrigen Reiter durchlaufen, bevor er im Inhaltsbereich landet. Vergleiche Heydon Pickerings Hinweise zum Tastaturverhalten bei Tabbed Interfaces.

Wenn die Bestandteile von Register-Elementen nicht gemäß den Best Practices von WAI-ARIA gekennzeichnet sind, erkennen blinde Benutzer möglicherweise nicht, um welche Art von Inhalt es sich handelt, und nehmen Inhalte in den derzeit ausgeblendeten Panels eventuell gar nicht wahr. Dasselbe Problem kann auftreten, wenn Benutzer auf älteren Systemen mit älteren Browsern oder älteren Hilfstechnologien arbeiten, bei denen die ARIA-Rollen und Attribute möglicherweise nicht unterstützt werden.

1 Tastaturnutzer: Das Element kann nicht erreicht werden

Das folgende Register-Element ist für Tastaturnutzer nicht bedienbar. Es gibt keine sichtbare Fokus-Hervorhebung, Die Tabs in der Tab-Liste können mit der Tastatur nicht erreicht werden, um einen anderen als den sichtbaren Tab auszuwählen.

Video -Beschreibung

Auf einer Seite der Website bahn.de zeigt ein Register-Element verschiedene Buchungsmöglichkeiten.

  • Der Nutzer tabbt durch die Seite und bemerkt, dass es keinerlei sichtbare Fokus-Hervorhebung gibt.
  • Er aktiviert eine Fokushervorhebung über das "Force Focus" Bookmarklet.
  • Der Nutzer tabbt durch die Hauptnavigation bis hin zum Login-Schalter und dann darüber hinaus.
  • Der Fokus springt vom Login-Schalter ditrekt in die Inhalte des ausgewählten Registerkarte. Eine Auswahl anderer Tabs aus der Tab-Liste mittels Tastatur ist nicht möglich.

2 Tastatur- und Screenreader-Nutzer: Unerwartetes Verhalten

Wenn ein Navigationsmenü als Register-Element implementiert wurde, aber wie ein normales Navigationsmenü aussieht, werden Tastaturbenutzer erwarten, dass sie die Tabulatortaste zum Durchlaufen der Menüelemente verwenden können. Dies funktioniert jedoch nicht, wenn das Register-Element das vorgesehene Tastaturverhalten für diese Komponente unterstützt. Benutzer müssen stattdessen die Pfeiltasten → ← verwenden.

Wenn zusätzlich die Auszeichnung des Elements mit ARIA-Rollen und Attributen unvollständig oder fehlerhaft ist, ist für Screenreader-Nutzer das Verhalten nur schwer nachvollziehbar.

Video-Beschreibung

Der Test zeigt das Verhalten beim Aufruf des Hauptnavigationsmenüs familyreunion-syria.diplo.de im Firefox Browser über die Tastatur, bei eingeschaltetem Screenreader NVDA.

  • Beim Erreichen in das Hauptnavigationsmenü wird der erste Menüpunkt "Startseite" fokussiert.
  • Das Weiter-Tabben zur Fokussierung des nächsten Menüeintrags schlägt fehl. Stattdessen bewegt sich der Fokus auf den darunter liegenden Inhalt der Registerkarte.
  • Der Benutzer bewegt durch Zurück-Tabben den Fokus zurück zum Hauptmenüpunkt und versucht stattdessen die rechte Pfeiltaste →. Aber jetzt liest der Screenreader die einzelnen Buchstaben des Linktextes.

3 Screenreader-Nutzung, kognitive Aspekte: Die Struktur der Register-Elemente verstehen

Für Screenreader-Benutzer von mobilen Betriebssystemen können sogar korrekt ausgezeichnete Registerkarten-Elemente schwierig zu verstehen sein. Ohne Tastatur gibt es keine eindeutige Fokusbedienung und keinen Unterschied zwischen Tabulatortaste ⇥ und Pfeiltasten (← →) - alle Elemente werden gleichermaßen durchlaufen. Rollen werden möglicherweise nicht bemerkt oder missverstanden.

Video-Beschreibung

Der Test zeigt einen blinden Nutzer mit kleinem Sehrest, der das Tabs pattern des GOV.UK Design System auf seinem eigenen iPhone ausprobiert. Der Nutzer ist mit seinem iPhone gut vertraut, nutzt aber nicht alle Möglichkeiten der Navigation, die der iOS Screenreader VoiceOver bietet.

  • Der Benutzer streicht durch die Registerkarten
  • Er erreicht den Inhalt, bemerkt aber nicht den Wechsel zwischen Reitern und Registerkarte
  • Er ordnet die 3 Spalten der Tabellen auf den Registerkarten irgendwie den 4 Reitern zu
  • Auf die Frage, ob er weiß, wo er ist, ist er sich nicht sicher; er meint dann, er sei auf der Registerkarte "abgeschlossene Fälle" (closed cases) — es gibt jedoch keine solche Registerkarte
  • Beim Vor- und Zurückblättern bemerkt der Benutzer nicht den Wechsel zwischen den Reitern und den h2-Überschriften der Registerkarte
  • Der Benutzer merkt nicht, dass er zum Anzeigen einer Registerkarte den entsprechenden Reiter aktivieren muss
  • Er entwickelt sein eigenes System der Interpretation der Inhaltsstruktur durch Abzählen, ein System, das nicht die tatsächliche Struktur widerspiegelt.

Zugänglichkeits-Tipps für Register-Elemente

Nach WAI-ARIA Empfehlungen gestaltete Register-Elemente

  • Entscheiden Sie sich für die automatische oder manuelle Aktivierung der Register. Für umfangreichere Inhalte und solche, die interaktive Elemente wie Links enthalten, empfiehlt sich eher die manuelle Aktivierung.
  • Verwenden Sie passende Rollen (tablist, tab, tabpanel) und Attribute, insbesondere aria-selected, um den Status des aktuellen Registers widerzuspiegeln. Es schadet auch nicht, mit aria-controls auf die id des entsprechenden Registerkarten zu verweisen, obwohl aria-controls derzeit schlecht unterstützt wird.
  • Verwenden Sie role="presentation" für Listenelemente (li), denen Sie eine neue Rolle zugewiesen haben (etwa role="tab"). Dadurch wird die Listen-Semantik entfernt, die bei Verwendung der ARIA-Rollen für Register-Elemente störend ist.
  • Implementieren Sie das Tastaturverhalten Pfeiltasten links / rechts zum Durchlaufen der Register. Der Fokus sollte in den Registern zirkulieren. Wenn es sich bei Ihren Registern um Links handelt, sollten Sie einen JavaScript event key handler für die Leertaste erwägen. Wenn Sie dann die Leertaste drücken, wird das aktuell fokussierte Register aktiviert.
  • Verwenden Sie auf der Registerkarte das Attribut aria-labelledby, um auf das zugehörige Register zu verweisen. Wenn Screenreader-Benutzer das Registerl aufrufen, wird der Name des Registerls als Label der Registerkarte ausgegeben, so dass klar ist, dass der Registerkarten-Inhalt zu diesem Register gehört.
  • Machen Sie den Inhalt der Registerkarte fokussierbar. Wenn sich in der Registerkarte keine fokussierbaren Elemente befinden oder wenn wichtiger Inhalt vor dem ersten fokussierbaren Element vorhanden ist, sollten Sie erwägen, tabindex="0" auf der Registerkarte zu verwenden. Ein anderer Ansatz besteht darin, die Pfeiltaste nach unten zu verwenden, um den Fokus auf die Registerkarte zu verschieben.
  • Geben Sie hilfreiche Hinweise. Einige Autoren empfehlen, einen sichtbaren Hinweis oberhalb der Register zu verwenden, wenn diese den Fokus erhalten, wie z. B. "Verwenden Sie die Pfeiltasten, um Register auszuwählen". Dieser Text kann über aria-describedby mit der tablist verknüpft werden.

Register-Elemente, bei denen die Register mit Tabben erreichbar sind

Im Gegensatz zu dem ARIA-Ansatz basieren Register-Elemente, bei denen die Register mit Tabben erreichbar sind, auf einer (normalerweise horizontal angeordneten) Liste von Links oder Schaltflächen (button-Elemente).

  • Verwenden Sie entsprechende ARIA-Rollen (tablist, tab, tabpanel) und Attribute, insbesondere aria-selected, auch wenn die Tastaturbedienung von der ARIA-Spezifikation abweicht.
  • Wenn die Registerkarten interaktiven Inhalt haben, wählen Sie die manuelle Aktivierung anstelle der automatischen Aktivierung. Wenn Sie Panels im Fokus anzeigen (automatische Aktivierung), können Sie den interaktiven Inhalt im Panel nicht direkt eingeben, es sei denn, Sie platzieren jedes Panel direkt nach seinem Tab (in der Reihenfolge des Quellcodes). In diesem Fall müssen Sie alle interaktiven Inhalte durchblättern, bevor Sie den nächsten Tab erreichen.
  • Wenn Sie einen Register-Link bzw. -Schaltfläche aktivieren, setzen Sie den Fokus über einenen seiteninternen Link oder ein Skript auf das erste Element der Registerkarte. Wenn dies nicht-interaktiver Inhalt wie etwa eine Überschrift ist, wird die Unterstützung von Browsern und assistiven Technologien verbessert, wenn Sie tabindex="- 1" für dieses Element festlegen.
  • Legen Sie auf der Registerkarte ein Attribut fest, um den aktuellen Status widerzuspiegeln (also zu kommunizieren, ob das entsprechende Feld momentan sichtbar oder ausgeblendet ist). Bei Links können Sie nicht aria-selected verwenden, aber Sie können es für Schaltflächen oder Links verwenden, denen Sie eine role="tab" gegeben haben.

Quellen für Register-Elemente (tabbed interfaces)

Gute Beispiele

Artikel über das Für und Wider von Register-Elementen