Navigationsmechanismen für einen Webauftritt
[Materialsammlung]
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.
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:
- 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 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.
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.
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.
Link oder Button?
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
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
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:
Kundengruppe: Privat / Geschäftlich / Kommunal
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.
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
- 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
- [Inclusive Components Design] Menus & Menu Buttons
- [GitHub Diskussion ] Clarify Purpose of Menu Navigation · Issue #353
- Accessible Mega Menu (Zum Design auf adobe.com)
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.)
- Das Vorhandensein von Unterpunkten wird mittels
aria-haspopup="true"
oderaria-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.
Bedienung mittels Tastatur in Megamenüs mit ARIA Rollen
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:
Aktion | Tastaturbefehl |
---|---|
Vorheriges Element: | Pfeil links |
Nächstes Element: | Pfeil rechts |
Elemente des Hauptnavigationspunktes öffnen und Fokus auf ersten Eintrag setzen: | ENTER oder LEERTASTE oder Pfeil unten oder Pfeil oben |
Untermenü schließen wenn sich der Fokus am Hauptnavigationspunkt befindet. | ENTER oder LEERTASTE |
Offenes Untermenü schließen | Escape |
Wenn sich der Fokus schon auf einem Element innerhalb eines Navigationspunktes befindet, erscheint die Tastaturnavigation typischerweise auf folgende Weise:
Aktion | Tastaturbefehl |
---|---|
Fokus auf nächstes Element innerhalb des Untermenüs setzen: | Pfeil unten |
Fokus auf vorheriges Element innerhalb des Untermenüs setzen: | Pfeil oben |
Elemente des vorherigen Hauptnavigationspunktes öffnen und Fokus auf ersten Eintrag setzen: | Pfeil links |
Elemente des nächsten Hauptnavigationspunktes öffnen und Fokus auf ersten Eintrag setzen: | Pfeil rechts |
ElementElement wählen (Fokus verlässt das Menü): | Enter oder LEERTASTE |
Untermenü schließen und Fokus auf Hauptnavigationspunkt | Escape |
Best Practise Beispiele für komplexe Navigationen
Accessible Mega Menu (Zum Design auf adobe.com) (Stand Februar 2017)
Adobe.com arbeitet ohne ARIA Rollen für Menüs in der Hauptnavigation.
Deque 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:
- 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 Useability 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
eingeblendet.
- Die einzelnen Menüpunkte erscheinen in JAWS als Formularelemente und nicht als Links. (wegen
role="menuitem"
)
Open 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.
- Das Menü scheint mit der Tastatur alleine bedienbar und liefert die erforderliche textuelle Information an den Screen Reader.
- Das Beispiel ist gut dokumentiert.