Barrierefreies Webdesign ein zugängliches und nutzbares Internet gestalten

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

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 insbesondere für Screenreadernutzer (aber 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.

HTML oder ARIA?

Die Regionen werden inzwischen in ARIA 1.1 definiert (und weichen an einigen Stellen von den Definitionen in ARIA 1.0 ab). 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
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 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 berücksichtigt werden kann.

Für Regionen auf einer Webseite, die die Rolle "search" erhalten sollen, muss 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 Rolle "form"

Bei der Rolle "form" gab es eine Änderung zwischen ARIA 1.0 und ARIA 1.1. Obwohl die Rolle in beiden Spezifikationen als landmark role definiert ist, enthielt das FORM-Element diese Rolle nach ARIA 1.0 nicht. Nach ARIA 1.1 soll das FORM-Element erst dann als Region identifiziert werden, wenn das Formular mit einem aria-labelledby-, aria-label- oder title-Attribut bezeichnet wird:

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

Diese Vorgehensweise für das FORM-Element kann damit begründet werden, dass nicht jedes Formular als Region einer Seite ausgezeichnet werden soll oder muss. Ein Kontaktformular könnte der Hauptinhalt der Seite sein – eine zusätzliche Auszeichnung als Region ist dann zu vermeiden. 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:

<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 dann als Region an den Accessibility-Tree übermittelt werden, wenn sie sich auf das BODY-Element beziehen. Sofern die beiden Elemente innerhalb 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).

Die generische Bezeichnung ist grundsätzlich ausreichend für die Konformität zu den WCAG 2.0, aber in der Praxis sollten Regionen 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 werden wird. Hingegen sind Bezeichnungen wie "Sie sind hier" (für eine Brotkrumennavigation) oder "Untermenü" in Ordnung.