Informationen


Navigationsmechanismen für einen Webauftritt
[Materialsammlung]

Symbolgrafik Labyrinth mit tastbarem Bodenleitsystem für einen Blindenstock

Bedeutung von Navigationsbereichen

Webauftritte bestehen nicht nur aus einer einzelnen Webseite, sondern aus einer Sammlung von Webseiten mit unterschiedlichen Inhalten und teilweise auch Funktionalitäten. Die einzelnen Webseiten müssen ausgehend von der Startseite durch verständliche Navigationsmechanismen erschlossen werden.

Es gibt unterschiedliche Methoden, wie Inhalte innerhalb eines Webauftritts erschlossen werden können. Typischerweise sind es verschachtelte Navigationen, Sitemaps oder visuell wahrnehmbare Metainformationen zu einer Seite (Contentinfo) im footer. Auf größeren Webauftritten wird wohl häufig einfach die Suchfunktion verwendet. Und um sich auf einer Unterseite über die Seitenhierarchie des Webauftritts zu orientieren, können Breadcrumbs sehr hilfreich sein.

Da die unterschiedlichen Navigationsmechanismen ihre jeweiligen Vor- und Nachteile aufweisen und abhängig von persönlichen Präferenzen und der Arbeitsumgebung unterschiedliche Strategien erwartet werden oder hilfreich sein können, ist es fein, wenn unterschiedliche Mechanismen zur Navigation innerhalb des Webauftritts verfügbar sind.

Erfolgskriterium 2.4.5 Mehrere Wege (Level AA)

Labyrinth mit tastbarem Bodenleitsystem für einen Blindenstock

Intuitive Navigationen in Struktur und Wording

Bedeutung intuitiver Navigationen

Dem Festlegen der Navigationsbereiche, Hauptnavigationspunkte und einzelner Navigationselemente muss bei der Konzeption eines Webauftritts von Seiten der Betreiber und der Redaktion höchste Aufmerksamkeit zugewandt werden. Beim Besuch einer Startseite sollte rasch das Angebot intuitiv verständlich sein und klar sein, auf welchen Link zu drücken ist, um die gesuchte Information oder Funktionalität zu erhalten.

Es gibt Webauftritte, auf denen die Navigationshierarchie die interne Organisationsstruktur der Einrichtung widerspiegelt. Jede Abteilung erhält ein eigenes Link in der Hauptnavigation und wenn die Abteilung Unterabteilungen hat, erhalten diese entsprechende Unternavigationspunkte.

Das erleichtert organisatorisch die Pflege der Seitenbereiche innerhalb der Einrichtung. Der Navigationsbaum entspricht einfach dem Organisationsbaum. Die Navigationshierarchie sollte jedoch der Perspektive der Besucher und Besucherinnen entsprechen.

Überlegungen zur Benutzerperspektive

Zum Ergründen der Benutzerperspektive sind eigene Reflexionen, Methoden des Useability Engineering und optimalerweise auch die direkte Einbindung von Zielgruppen in den Gestaltungsprozess hilfreich.

Eigenreflexion (Cognitive Think Through)

Folgende Fragen sollte man sich beim Festlegen der einzelnen Navigationspunkte und deren Formulierung stellen:

  1. Welche Personengruppen dürften sich für meine Angebote interessieren?
  2. Welche Personengruppen möchte ich ansprechen?
  3. Was sucht jemand auf meinen Webauftritt?
  4. Welche Informationen und Funktionalitäten habe ich auf meinem Webauftritt?
  5. Welche meiner Webseiten werden besonders interessant sein?
  6. Wie kann ich aufbauend auf die Analyse der Bedürfnisse meiner Besucher und Besucherinnen meine Navigationshierarchie optimieren?

Methoden des Useability Engineering

Wenn wir für uns die Fragen der Eigenreflexion beantworten, verwenden wir schon eine Methode des Useability Engineering, das (Cognitive Think Through.

Um die Navigation innerhalb des Webauftritts zu optimieren, empfiehlt es sich, weitere Methoden des Useability Engineering zu verwenden. Insbesondere die Konzepte der Persona und des Card Sorting sind dabei hilfreich.

Labyrinth mit tastbarem Bodenleitsystem für einen Blindenstock

Semantische Kennzeichnungen von Navigationsbereichen

Zunächst sollte grafisch intuitiv klar sein, dass es sich um einen Navigationsbereich handelt. Dies erfolgt erfahrungsgemäß meist sauber durch die Platzierung des Navigationsbereichs auf der Webseite und die visuelle Gestaltung der Schaltflächen.

Damit das, was visuell intuitiv gestaltet wurde, aber auch für einen Screen Reader als Navigationsbereich erkannt werden kann, sind semantisch Vorkehrungen zu treffen.

ARIA Landmark role="navigation"

Die Web Accessibility Initiative (WAI) des W3C hat für Navigationsbereiche eine eigene Landmark Role vorgesehen. Auf diese Weise kann etwa der entsprechende <div>-Bereich für einen Screen Reader semantisch gekennzeichnet werden:

<div role="navigation"> ... </div>

Der Screen Reader informiert dadurch über Anfang und Ende der Navigation Region.

Explizite Suchbereiche müssen hingegen mit Landmark role="search" gekennzeichnet werden.

Das Attribut role="navigation" sollte nicht im <ul>-Tag für Linklisten eingesetzt werden, weil dadurch die Semantik als Liste überschrieben werden kann. Statt dessen sollte das Attribut in einem übergeordneten <div>-Bereich oder in HTML5 gleich in einem <nav>-Element eingebettet werden.

HTML5 Element <nav>

In HTML5 gibt es für Navigationsbereiche das Markup Element NAV. Dieses wird von modernen Screen Readern auch schon sauber interpretiert. Es scheint daher nicht mehr erforderlich, das HTML5 Element mit ARIA role="navigation" zu ergänzen.

<nav role="navigation"> ... </nav>

Kennzeichnung von Listen

Ein Navigationsbereich besteht überwiegend aus einer Liste von Links. Gelegentlich enthalten einzelne Navigationsknoten wiederum eine Liste von Links.

Damit ein Screen Reader die einzelnen Listenelemente als solche erkennt, muss die Liste technisch als solche gekennzeichnet sein. Auf diese Weise kann vom Screen Reader etwa die Anzahl der Listenelemente ermitteln werden, was für die Bedienung sehr hilfreich ist.

In HTML wird dazu einfach das <ul>-Element mit dem <li>-Element für die einzelnen Listenelemente verwendet. Damit vom Browser vor den einzelnen Links kein Indikator für Listenelemente angezeigt wird, kann die entsprechende CSS-Anweisung verwendet werden. Der Code kann also etwa folgendermaßen aussehen:

<ul style="list-style-type:none;">
  <li>
    <a href="/angebot">Angebot</a>
  </li>
  ...
</ul>

Wenn das HTML-Markup für Listen adäquat eingesetzt wird, werden die ARIA Rollen list und listitem nicht benötigt.

Beides sind Schaltflächen und beide werden grafisch in Navigationsbereichen und Anwendungen ähnlich realisiert. Dabei verfügen beide Elemente über unterschiedliche Funktionalitäten, wenn sich diese gelegentlich auch nicht klar trennen lassen.

Links sind Schaltflächen, die eine neue Seite öffnen oder den Fokus zu einem versetzten Seitenbereich verschieben. Typischerweise enthalten sie daher ein href-Attribut ohne weitere Funktionalitäten.

Buttons

Buttons führen im Gegensatz zu Links nicht zu einem anderen Standort, sondern lösen innerhalb eines Seitenbereichs einen Mechanismus aus. Dies wird typischerweise in Formularen benötigt, etwa zum Anzeigen eines Ergebnisses. Buttons sind oft aber auch das angemessene semantische Markup zum Öffnen eines Unterbereichs, etwa in einem Akkordeon oder gerade auch einer Region mit Unterpunkten zu einem Hauptnavigationspunkt.

Überschriften und Beschriftungen für Navigationsbereiche

Wer mit einem Screen Reader eine Webseite erkundet, hat Funktionalitäten zur Navigation zwischen Seitenbereichen zur Verfügung. Diese listen etwa vorhandene HTML5 oder ARIA Landmark Roles für Navigationsbereiche auf.

Damit ein Screen Reader aber nicht nur die Rolle als Navigationsbereich, sondern auch einen passenden Namen für den Bereich vermitteln kann, muss der Bereich mit einem technisch zugänglichen Namen versehen werden. Dafür steht das aria-label Attribut zur Verfügung.

Typischerweise wird dieses Attribut etwa für Breadcrumbs oder die Hauptnavigation in folgender Weise eingesetzt:

Die individuelle Beschriftung von <nav>-Bereichen entspricht dem Erfolgskriterium 2.4.6 Überschriften und Beschriftungen (AA). Der Aufwand zur technischen Umsetzung ist jedoch denkbar gering: Normal müssen nur geringfügige Ergänzungen im Template des CMS vorgenommen werden.

Sichtbare Überschriften für Navigationsbereiche

Bei den Breadcrumbs ist es ja vielfach üblich, für den Navigationsbereich eine Überschrift zu vergeben. Als Text wird meist Standort: oder für einfachere Sprache Sie befinden sich hier: verwendet.

Es ist darüber hinaus zu überlegen, ob nicht auch andere Navigationsbereiche mit sichtbaren Überschriften versehen werden sollten. Insbesondere wenn sich auf einer Seite mehrere Navigationslisten befinden, kann dies dem Verständnis dienen. Befinden sich etwa auf einem Webauftritt unterschiedliche Produktpaletten für unterschiedliche Zielgruppen, und diese Zielgruppen werden in einer eigenen Navigation angesprochen, so kann eine Überschrift dies verdeutlichen:

Der Code dafür könnte etwa folgendermaßen aussehen:

<h6>Kundengruppe</h6>
  <a href="privat.html">Privat</a> /
  <a href="business.html">Geschäftlich</a> /
  <a href="kommunal.html">Kommunal</a>

Tabindex für nicht-fokussierbare Elemente

Wenn ein Menüelement kein Formularelement oder Link ist, muss ein tabindex-Attribut gesetzt werden, damit das Element einen Fokus erhalten kann. Gewöhnliche Formularelemente oder Links hingegen benötigen in der Regel keinen Tabindex.

Labyrinth mit tastbarem Bodenleitsystem für einen Blindenstock

Verschachtelte Navigationsmechanismen, Megamenüs und Fly Out

Bedeutung von komplexen Navigationsmechanismen

Größere Webauftritte verfügen gelegentlich über Navigationsbereiche mit Hauptnavigationspunkten und unsichtbaren Unternavigationspunkten. Die Unterpunkte werden erst durch Mausaktion (HOVER-Effekt), Tastaturaktion (Fokuseffekte) oder Berühren am Touch Screen eingeblendet.

Dies technisch und für die Useability sauber zu gestalten ist eine große Herausforderung. In welcher Form dies gewährleistet wird, ist umstritten und bedarf im Einzelfall einer Diskussion.

Navigationen mit ARIA Rollen für Menüs

Um komplexen Navigationsbereiche für Screen Reader das Feeling der Bedienung des Menüs einer Anwendung zu verleihen, können sie mit einschlägigen ARIA Menü-Rollen versehen werden (menu, menubar, menuitem, …). Allerdings bringen diese semantischen Kennzeichnungen einige Probleme im Bezug auf die gewohnten semantischen Erfahrungen und die Tastaturbedienung im Browser mit einem Screen Reader (UX):

Problematik von Navigationen mit ARIA Rollen für Menüs

Ich rate dringend davon ab, ARIA Rollen für Menüs in Navigationsbereichen zu verwenden. Diese sind primär für Webanwendungen (Applications) vorzubehalten. Wie komplexe Navigationsbereiche ohne ARIA Rollen recht barrierefrei und elegant realisiert werden können, lässt sich an folgendem Beispiel recht gut erlernen:

Don’t Use ARIA Menu Roles for Site Nav

Verhalten bei der Bedienung mittels Tastatur

Befindet sich der Fokus auf einem Hauptnavigationspunkt, sind folgende Punkte zu beachten: (Der Fokus wird z.B. mit Tabulator auf den Navigationsbereich hin verschoben.)

Wenn sich die Bewegung innerhalb der Navigation an die Mechanismen von Bedienungsmenüs in Applikationen anlehnt, kommt bei der Bedienung mit der Tastatur den Pfeiltasten eine zentrale Aufgabe zu. Ein Tastaturzugang zu den Hauptnavigationspunkten („Menubar“) wird daher typischerweise folgendermaßen aussehen:

Wenn sich der Fokus schon auf einem Element innerhalb eines Navigationspunktes befindet, erscheint die Tastaturnavigation typischerweise auf folgende Weise:

Best Practise Beispiele für komplexe Navigationen

extern Accessible Mega Menu (Zum Design auf adobe.com) (Stand Februar 2017)

Adobe.com arbeitet ohne ARIA Rollen für Menüs in der Hauptnavigation.

externDeque University Codebeispiel für ein Megamenü (Stand Juni 2016)

Das Beispiel zeigt ein Megamenü mit ARIA Rollen für Menüs.

Die Kriterien für die Tastaturnavigation scheinen erfüllt:

Problembereiche des Deque Beispiels für Megamenüs:

externOpen Ajax Accessibility Example für ein Anwendungsmenü (Stand Juni 2016)

Dieses Beispiel beschäftigt sich zwar wiederun nicht mit einer Navigation, sondern mit einem Menü für eine Webanwendung. Das Beispiel dürfte aber trotzdem interessant sein für die barrierefreie Gestaltung von komplexen Navigationsbereichen, die mit ARIA Menürollen arbeiten.