Die Navigation über Seitenregionen veröffentlicht in 2012/2016

Seit vielen Jahren haben Webentwickler die strukturelle Navigation mit unterschiedlichen Techniken zu realisieren versucht. Alle Techniken sind letztlich "Krücken" gewesen, denn HTML 4.01 sah für die Navigation per Tastatur lediglich die Tab-Taste vor (wenn von Shortcuts abgesehen wird). Mit HTML5 und ARIA gibt es inzwischen die Möglichkeit, Regionen einer Seite zu bestimmen und zu beschriften. Die Regionen können dann per Tastatur angesteuert werden.

Die "klassische" strukturelle Navigation

Die strukturelle Navigation ist eine erweiterte Navigation für Tastatur- und insbesondere Screenreadernutzer, die über die Verwendung der Tab-Taste hinausgeht. Während mit der Tab-Taste aktive Elemente wie Links und Formularelemente angesprungen werden können, kann mit der strukturellen Navigation über die Strukturmerkmale einer Webseite navigiert werden. So ist es vor allem in Screenreadern möglich, zur nächsten Überschrift oder zum nächsten Absatz mit einem Tastendruck zu springen.

Wer eine Maus nicht nutzen kann steht auf Seiten mit vielen aktiven Elementen vor einem Problem. Wenn beispielsweise ein Formular ausgefüllt werden soll und vor dem Formular etliche Links stehen, dann muss die Tab-Taste nicht selten sehr häufig betätigt werden, um den Fokus in das erste Formularfeld zu setzen. Die Web Content Accessibility Guidelines (WCAG) 2.0 geben deshalb vor, dass Intern: Navigationsbereiche einer Webseite per Tastatur übersprungen werden sollen. Die Richtlinien lassen dabei offen, ob ein solcher Mechanismus über die strukturelle Navigation oder mit Sprunglinks erfolgen soll.

Um Navigations- oder Werkzeugleisten überspringbar zu machen gibt es verschiedene Techniken:

  1. Ist eine Seite gut strukturiert mit Überschriften, Listen oder Absätzen, so können Screenreadernutzer über die Strukturen navigieren. Eine Navigationsleiste, die aus einer HTML-Liste besteht, ist beispielsweise überspringbar — Screenreader bieten Tastenbefehle an, um zum Ende eines Elements zu springen. Alternativ zu den Listen gelingt die strukturelle Navigation auch über Intern: Frames, Grafiken, Formulare und viele andere Elemente. Obwohl es viele navigierbare Strukturmerkmale einer Webseite geben kann, ist es letztlich dem Nutzer überlassen, diese technischen Unterschiede zu begreifen und zu lernen.
  2. Der gezielte Einsatz von (teilweise unsichtbaren) Intern: Überschriften vor einzelnen Inhaltsblöcken stellt eine bessere Technik dar, da zusätzlich zur Struktur mit dem Überschriftentext auch eine Bezeichnung des nachfolgenden Inhalts berücksichtigt werden kann. Screenreader können Überschriften per Tastendruck (meist die Taste H) nacheinander ansteurn. Allerdings wird diese Technik in der Praxis nicht einheitlich umgesetzt. Die einen setzen für die strukturelle Navigation H1, die nächsten H2 und manche H3, H4, H5 oder H6 ein. Außerdem finden sich dabei immer wieder Überschriftenhierarchien und viele andere inkonsistente Umsetzungen dieser Technik.
  3. Schließlich werden Intern: Sprunglinks für die Navigation innerhalb von Webseiten in Betracht gezogen. Schwierig bei diesem Konzept ist, dass die Sprunglinks meist am Anfang einer Webseite stehen und beispielsweise nicht dafür geeignet sind, eine webseite zu "scannen".

Die Technik mit Überschriften war — früher — der bestmögliche Weg, Navigationsbereiche überspringbar zu machen:

<div id="nav">
  <h6>Navigation</h6>
  <!-- ... Die Navigationseinträge ... -->
</div>

Mit Accessible Rich Internet Applications (ARIA) 1.0 wurden neue Rollen eingeführt. Insbesondere bieten die landmark roles nicht nur die Möglichkeit, einzelne Regionen einer Webseite semantisch zu identifizieren, sondern sie dienen insbesondere der strukturellen Navigation.

Hinweis: DieARIA-Spezifikation sieht zwar vor, dass "user agents" eine Navigation über Seitenregionen ermöglichen, aber bislang ist das nur mit Screenreadern oder mit Browser-Plugins möglich.

Inzwischen kann auf Hilfskonstrukte wie das vorstehende Beispiel mit einer zusätzlichen Überschrift verzichtet werden. Die Zuweisung einer Rolle als Seitenregion erlaubt es Screenreadern, die Region semantisch zu identifizieren:

<div id="nav" role="navigation">
  <!-- ... Die Navigationseinträge ... -->
</div>

Damit wird ein Navigationsbereich nicht nur semantisch identifiziert, sondern Hilfsmittel wie Screenreader bieten Intern: Tastenbefehle an, um die Region direkt anzuspringen.

HTML oder ARIA?

Folgende landmark roles (mit ihren HTML-Entsprechungen) gibt es:

RolleHTML
Applicationkeine HTML-Entsprechung (siehe Intern: Die Besonderheit der ARIA-Rolle application)
BannerHEADER-Element (siehe unten)
ComplementaryASIDE-Element
contentinfoFOOTER-Element (siehe unten)
Formkeine HTML-Entsprechung (siehe unten)
MainMAIN-Element
NavigationNAV-Element
Searchkeine HTML-Entsprechung; (siehe unten)

Wenn ein HTML-Element eine Rolle bereits besitzt, dann ist es nicht sinnvoll, die Rolle zusätzlich mit dem role-Attribut zuzuweisen. Ein MAIN-Element als

<main id="content" role="main">
  <!-- ... Hauptinhalte der Webseite ... -->
</main>

ist eigentlich überflüssig. Der folgende Code sollte genau dasselbe bewirken:

<main id="content">
  <!-- ... Hauptinhalte der Webseite ... -->
</main>

Für die fünf landmark roles, die eine HTML-Entsprechung haben (ASIDE-, FOOTER-, HEADER-, MAIN- und NAV-Elemente), ist nach der HTML-Spezifikation keine erneute Bestimmung der Rolle mit ARIA notwendig. Allerdings gibt es in der Praxis einige Extern: Kompatibilitätsprobleme mit einzelnen Browsern und Screenreadern, so dass die explizite Zuweisung der Rolle nach wie vor empfohlen wird.

Für Regionen auf einer Webseite, die die Rollen "application", "form" oder "search" entsprechen, muss hingegen die Rolle mit dem role-Attribut zugewiesen werden.

<div id="search" role="search">
  <form>
    <!-- ... Suchformular ... -->
  </form>
</div>

Besonderheiten

Bei dem Konzept der Rollen (HTML und ARIA) ist es wichtig zu wissen, dass sie keinerlei Einfluss auf die Darstellung oder das Verhalten einer Webseite im Browser haben. Vielmehr handelt es sich bei der Semantik um eine Information für den Browser, wie der Intern: Accessibility-Tree des Betriebssystems zu befüllen ist. Hilfsmittel wie Screenreader holen die Informationen dort ab und verarbeiten sie weiter.

Die Rollen "form" und "search"

Die Rolle form fällt ein klein wenig aus dem Rahmen. Während die Rolle "form" eine navigierbare Region einer Seite kennzeichnet, sieht die HTML-Spezifikation diese Rolle nicht für das FORM-Element vor. Dennoch führt

<form id="contact" role="form">
  <!-- ... Kontaktformular ... -->
</form>

zu einer Warnung bei derExtern, englischsprachig: HTML-Validierung. Dabei handelt es sich um zwei unterschiedliche Konzepte, denn die Rolle dient der Navigation in Hilfsmitteln und das HTML-Element dient der Verarbeitung von Nutzereingaben. Um Warnungen bei der Validierung zu umgehen, muss das role-Attribut einem anderen Element zugewiesen werden:

<div id="contact" role="form">
  <form>
    <!-- ... Kontaktformular ... -->
  </form>
</div>

Ähnlich sollte die Rolle "search" nicht mit dem Eingabefeld des Types "search" (<input type="search">) verwechselt werden. Während ein Eingabefeld des Typs "search" durch den Browser als Suchfeld identifiziert werden kann (und eine API des Browsers anspricht), kennzeichnet die Rolle "search" eine per Tastatur ansteuerbare Region der Seite, die Suchfeld, eventuelle Optionen und Erläuterungen sowie die Senden-Schaltfläche umfassen sollte und außerdem semantisch als Suchregion der Webseite identifiziert wird:

<div id="search" role="search">
  <form>
    <input type="search" name="sucheingabe" />
    ...
  </form>
</div>

HEADER und FOOTER

Die HEADER- und FOOTER-Elemente dienen dazu, einen einführenden oder abschließenden Inhalt eines Seitenabschnitts auszuzeichnen. D.h., diese beiden Elemente können für das BODY-Element, aber auch für andere Abschnittselemente (ARTICLE-, ASIDE-, NAV- und SECTION-Elemente eingesetzt werden.

Nach der ARIA-Spezifikation sollen die Rollen "banner" und "contentinfo" nur einmal in einem Dokument vorkommen, typischerweise für eine Kopfzeile der Seite mit Logo und ähnlichem Inhalt sowie für abschließende Informationen zum Inhalt (z.B. Links zu verwandten Beiträgen).

Derzeit werden Banner und Inhaltsangaben innerhalb von Abschnittselementen von Screenreadern unterschiedlich behandelt. Meist werden sie aber als Banner und Inhaltsangabe angesprungen. Wenn also mehrere HEADER- oder FOOTER-Elemente auf einer Webseite eingesetzt werden, werden sie von Screenreadern wie JAWS oder Window Eyes dementsprechend oft als Banner oder Inhaltsverzeichnisse identifiziert.