Barrierefreies Webdesign ein zugängliches und nutzbares Internet gestalten

Die Navigation über Seitenregionen veröffentlicht in 2012zuletzt bearbeitet in 2017

Viele Jahre lang hatten Webentwickler die strukturelle Navigation mit unterschiedlichen Techniken zu realisieren versucht. Alle Techniken waren 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 insbesondere für Screenreadernutzer (und mit entsprechenden Plug-Ins auch für Tastaturnutzer), 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 bzw. Barrierefreie Informationstechnik-Verordnung – BITV 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 gab 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 stellte 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 Varianten 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". Gleichzeitig ist es die einzige Technik, die nur mit dem Browser (und ohne Screenreader) zugänglich ist.

Die Technik mit Überschriften war – früher – der übliche 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.

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.

Genauso kann aber auch ein NAV-Element eingesetzt werden, das die implizite Rolle "navigation" besitzt. Der folgende Code führt zum gleichen Ergebnis:

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

HTML oder ARIA?

Die Rollen werden inzwischen in ARIA 1.1 definiert. Sieben der acht landmark roles werden außerdem durch HTML-Elemente implizit bestimmt, so dass eine explizite Zuweisung einer Rolle mit dem role-Attribut nicht erforderlich ist. Folgende landmark roles (mit ihren HTML-Entsprechungen) gibt es:

RolleHTML
BannerHEADER-Element
ComplementaryASIDE-Element
contentinfoFOOTER-Element
FormFORM-Element mit Bezeichnung
MainMAIN-Element
NavigationNAV-Element
regionSECTION-Element mit Bezeichnung
Searchkeine HTML-Entsprechung;

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 überflüssig. Der folgende Code bewirkt genau dasselbe:

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

Für die landmark roles, die eine unmittelbare HTML-Entsprechung haben (ASIDE-, FOOTER-, FORM-, HEADER-, MAIN-, NAV- und SECTION-Elemente), ist nach der HTML-Spezifikation keine erneute Bestimmung der Rolle mit ARIA zulässig.

Für Regionen auf einer Webseite, die die Rolle "search" erhalten sollen, muss die Rolle mit dem role-Attribut zugewiesen werden.

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

Besonderheiten

Bei dem Konzept der Rollen (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 "region"

Sowohl bei der Rolle "form" als auch bei der generischen Rolle "region" müssen die Seitenregionen mit aria-label oder aria-labelledby bezeichnet werden, bevor sie als Seitenregion identifizierbar sind:

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

Diese Vorgehensweise kann damit begründet werden, dass nicht jeder Abschnitt und nicht jedes Formular als Region einer Seite ausgezeichnet werden soll oder muss. Ein Kontaktformular könnte der Hauptinhalt (MAIN-Element) der Seite sein – eine zweite Seitenregion ist nicht förderlich für die Barrierefreiheit an der Stelle. Wenn aber das Kontaktformular zwischen anderen Inhalten oder in einem Modalfenster steht, kann die zusätzliche Auszeichnung sinnvoll sein.

Die Rolle "search"

Die Rolle "search" sollte 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:

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

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. Sie dürfen außerdem im Kontext eines MAIN-Elements stehen.

Nach der ARIA-Spezifikation sollen die Rollen "banner" und "contentinfo" nur dann als Region an den Accessibility-Tree übermittelt werden, wenn sie im Kontext des BODY-Elements stehen. Sofern die beiden Elemente im Kontext eines ARTICLE-, ASIDE-, MAIN-, NAV- oder SECTION-Elements stehen, dürfen Browser keine Regionen an den Accessibility-Tree übermitteln.

Beschriftung von Regionen

Regionen sind semantische Auszeichnungen ohne Inhaltsbezug. Wenn ein Screenreader auf eine Region mit der Rolle "navigation" trifft, wird die Region mit "Navigationsregion" o.ä. identifiziert. Ähnlich werden die anderen Regionen identifiziert (auch wenn die Bezeichnungen von Screenreader zu Screenreader variieren).

Seitenregionen sollten eindeutig beschriftet werden, wenn mehr als eine Region des gleichen Typs auf einer Seite vorkommt. Außerdem sollten sie einen inhaltlichen Bezug herstellen (wie eine Überschrift); eine Region sollte beispielsweise nicht mit "Navigation" bezeichnet werden, da sie vom Screenreader dann als "Navigation Navigationsregion" identifiziert wird. Hingegen sind Bezeichnungen wie "Sie sind hier" (für eine Brotkrumennavigation) oder "Untermenü" in Ordnung. Manchmal wird es Fälle geben, wo die gleiche Bezeichnung zweckmäßig ist und zwar dann, wenn die Inhalte der Seitenregionen identisch sind (z.B. bei der Wiederholung einer Blätterfunktion). Letztlich kommt es darauf an, dass wenn die Seitenregionen aufgelistet werden, sie voneinander unterscheidbar sind.