Navigationsmechanismen für einen Webauftritt
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)
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 Usability 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:
- Welche Personengruppen dürften sich für meine Angebote interessieren?
- Welche Personengruppen möchte ich ansprechen?
- Was sucht jemand auf meinen Webauftritt?
- Welche Informationen und Funktionalitäten habe ich auf meinem Webauftritt?
- Welche meiner Webseiten werden besonders interessant sein?
- Wie kann ich aufbauend auf die Analyse der Bedürfnisse meiner Besucher und Besucherinnen meine Navigationshierarchie optimieren?
Methoden des Usability Engineering
Wenn wir für uns die Fragen der Eigenreflexion beantworten, verwenden wir schon eine Methode des Usability Engineering, das (Cognitive Think Through.
Um die Navigation innerhalb des Webauftritts zu optimieren, empfiehlt es sich, weitere Methoden des Usability Engineering zu verwenden. Insbesondere die Konzepte der Persona und des Card Sorting sind dabei hilfreich.
Semantische Kennzeichnungen von Navigationsbereichen
Kennzeichnung als Navigationsbereich
Bedeutung der Kennzeichnung als Navigationsbereich
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.
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 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
Beschriftung von <nav>-Bereichen
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:
- <nav aria-label="Standort" > … </nav>
- <nav aria-label="Hauptnavigation" > … </nav>
- …
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.
Standortangaben (Breadcrumbs)
Bedeutung von Standortangaben
IT – Menschen sind beim Ausdenken von Fachausdrücken oft märchenhaft kreativ. Hänsel hat auf seinem Weg mit Gretel Brotkrümel am Weg fallen lassen, um wieder zurückzufinden.
Auf Webseiten sind Breadcrumbs Navigationsmechanismen, die im Navigationsbaum des Webauftritts quasi vertikal von der aktuellen Seite zur Startseite zurückführen. Auf diese Weise können übergeordnete Webseiten bequem aufgerufen werden und die hierarchische Anordnung des Webauftritts verdeutlicht werden.
Technische Realisierung von Standortangaben
Standortangaben werden üblicherweise oberhalb des Hauptinhalts und manchmal redundant am Ende des Hauptinhalts eingeblendet. Die hierarchische Anordnung erfolgt in einer horizontalen Anordnung.
Beispiel:
Standort: Startseite > Waren > Obst > Äpfel
Bezeichnung des Bereichs für den Standort
Bei der Benutzung eines Screen Readers ist es wichtig, den Kontext eines Inhalts zu verstehen. Wenn die Standortangaben über keine Überschrift im Kontext verfügen, benötigen sie eine Bezeichnung via aria-label oder aria-labelledby.
Es ist grundsätzlich fein bei der Nutzung eines Screen Readers, wenn Bereiche mit aria-label adäquat beschriftet sind. Der Screen Reader kann auf diese Weise nicht nur den Anfang, sondern auch das Ende des Abschnitts wiedergeben.
CSS Techniken für Standortangaben
Zwischen den hierarchischen Ebenen befindet sich visuell üblicherweise ein Zeichen, das auf eine andere Ebene hinweist, häufig ein "Größer Als" (>), das als spitze Klammer nach rechts erscheint. Ein solches Zeichen kann mittels CSS3 etwa folgendermaßen automatisch hinter jedes Link platziert werden:
#breadcrumbs a::after {content: "> " }
Die CSS3 Anweisungen after und before dürfen natürlich nicht eingesetzt werden, um relevante Texte in den HTML-Code zu schummeln. In diesem Fall geht jedoch kein Inhalt für den Screen Reader verloren, egal ob er diese CSS Anweisungen interpretiert oder nicht. Die Semantik ergibt sich aus der Tatsache, dass es sich um einen Navigationsbereich handelt, gegebenenfalls der Beschriftung, vor allem jedoch aus der Auflistung von Links.
Links zu Standortangaben
WAI-ARIA Authoring Practices 1.1 - Breadcrumb (Arbeitspapier)
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 Usability 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
- Links, die mit
role="menuitem" versehen sind, erscheinen für den Screen Reader nicht mehr als Links, sondern Formularelemente. Das bedeutet:
- Sie erscheinen nicht mehr beim Auflisten der Links mit Funktionalitäten der Screen Reader (etwa JAWSTASTE + F7).
- Dafür wird die Liste der Formularelemente völlig unübersichtlich, wodurch sich eigentliche Formularelemente, die sich eventuell auf einer Seite befinden, nicht mehr effizient finden lassen (JAWSTASTE + F5).
- Einige Screen Reader wechseln beim Einsatz dieser ARIA Rollen in den Formularmodus, was sich auf die Tastaturbedienung auswirkt. Die Pfeiltasten links (←) und rechts (→) dienen etwa nicht mehr zum Bewegen zwischen Zeichen, sondern Navigationselementen.
- Sobald ARIA Menu-Rollen in einer Navigation eingesetzt werden, müssen ziemlich komplexe Interaktionsmechanismen zur Bedienbarkeit gewährleistet werden, um tatsächlich die gewohnte Tastaturbedienung einer Anwendung wiederzugeben. Man macht es also bei der technischen Umsetzung selbst schwerer als nötig.
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
Links zur Problematik von Navigationsmenüs
Befindet sich der Fokus auf einem Hauptnavigationspunkt, sind folgende Punkte zu beachten: (Der Fokus wird z.B. mit Tabulator auf den Navigationsbereich hin verschoben.)
- Das Vorhandensein von Unterpunkten wird mittels
aria-haspopup="true" oder aria-expanded="false" an den Screen Reader vermittelt.
- Für die visuelle Tastaturbedienung ist es fein, wenn beim Fokus auf einem Hauptpunkt die Unterpunkte gleich eingeblendet werden.
- Ob die Unterpunkte noch ausgeblendet oder bereits eingeblendet sind, wird an den Screen Reader mittels
aria-expanded="true" oder "false" bekannt gegeben.
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
Adobe.com arbeitet ohne ARIA Rollen für Menüs in der Hauptnavigation.
Das Beispiel zeigt ein Megamenü mit ARIA Rollen für Menüs.
Die Kriterien für die Tastaturnavigation scheinen erfüllt:
- Mit Cursor Links / Rechts kann zwischen den Hauptnavigationspunkten gewechselt werden.
- Mit der Leertaste oder Pfeil Unten kann das Untermenü geöffnet werden.
- Im Untermenü hingegen kann zwischen den Überschriften für die Navigationsspalten nicht mehr mit Pfeil Links / Rechts gewechselt werden. Dieses Feature wird man aus Gründen der Usability wohl kaum einmal brauchen
- Mit Escape springt der Fokus zurück zum Hauptmenüelement.
Problembereiche des Deque Beispiels für Megamenüs:
- Vor den Hauptnavigationspunkten befinden sich quadratische Symbole, die dazu führen, dass beispielsweise beim JAWS Dialogfeld für Formularelemente (JAWSTASTE + F5) die Elemente nicht mehr mit dem Anfangsbuchstaben angesprungen werden können. Möglicherweise werden diese unnötigerweise mit
- Die einzelnen Menüpunkte erscheinen in JAWS als Formularelemente und nicht als Links. (wegen
role="menuitem")
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.
- Das Menü scheint mit der Tastatur alleine bedienbar und liefert die erforderliche textuelle Information an den Screenreader.
- Das Beispiel ist gut dokumentiert.
Links zum Thema der verschachtelten Navigationen
