Landmark roles mit HTML5 und ARIA veröffentlicht in 2012/2014

Verteilung von Rollen als Navigationskonzept

HTML 4.01 bietet Tastaturnutzern generell nur eine Möglichkeit der Navigation innerhalb einer Webseite. Mit der Tabulatortaste können Links und Steuerelemente nacheinander angesprungen werden. Dieser Problematik wurde im Laufe der Jahre durch erweiternde Konzepte entgegnet:

Mit WAI-ARIA werden weitere Maßstäbe gesetzt. Die Anforderungen umfassen zum einen viele neue Attribute, die die Semantik von Webseiten betreffen, aber die Tastaturbedienung innerhalb von Webseiten spielt ebenfalls eine zentrale Rolle. Mit den landmark roles kann eine Webseite in verschiedene Bereiche unterteilt und für Tastaturnutzer ansteuerbar gemacht werden.

Wenn landmark roles eingesetzt werden, dann sollten sie mit Bedacht vergeben werden. Allzu oft wird WAI-ARIA über eine Webseite "gestreut", was im Extremfall dazu führt, dass die Seite weniger barrierefrei wird als zuvor. Folgende 5 Punkte sollten bei der Vergabe von landmark roles beachtet werden:

1. Regionen einer Webseite identifizieren

Zunächst sollte eine Seite zu wahrnehmbaren, logischen Regionen herunter gebrochen werden. In den einzelnen Regionen sollten Inhalte zusammenhängend oder zumindest miteinander verwandt sein. Diese Herangehensweise darf zwar rekursiv erfolgen, d.h. nach einer groben Einteilung der Seiteninhalte kann für einzelne Bereiche eine weitere Unterteilung vorgenommen werden, aber für die Praxis sind Verschachtelungen von Bereichen, die als navigierbare landmarks gekennzeichnet werden, nicht besonders übersichtlich.

Für die Unterteilung der Webseite in Bereiche ist es hilfreich, sich die einzelnen Blöcke der Seite als Abschnitte oder unabhängige Einheiten vorzustellen. Es sollte die Erstellung eines Inhaltsverzeichnisses möglich sein, die die Erschließung der Webseite einwandfrei möglich macht. Am Ende der Prozedur soll der (Screenreader-)Nutzer von Bereich zu Bereich springen und dabei jeden Bereich eindeutig identifizieren können.

2. Jede Region in einem eigenen Element fassen

Nachdem die Regionen festgelegt wurden, müssen sie auch softwaretechnisch eindeutig identifizierbar sein. Im Allgemeinen wird dieser Schritt ohnehin befolgt: Die einzelnen Regionen der Seite benötigen ein eigenes Element wie ein DIV, das anschließend die Inhalte des Bereichs als einer Region zugehörig identifizieren wird.

<div id="meineRegion">
  ... Inhalte einer Region ...
</div>

Die Bereiche können auch mit den HTML5-Elementen für die Unterteilung von Inhalten wie NAV oder zur Gruppierung von Inhalten wie MAIN gekennzeichnet werden. Derzeit sind die meisten neuen HTML5-Elemente, die mit den landmark roles korrelieren, nicht zugänglichkeitsunterstützend und müssen zusätzlich mit landmark roles ergänzt werden.

3. Vergabe von landmark roles

Jetzt, wo alle Inhalte nach Regionen unterteilt sind, muss dem Browser auch mitgeteilt werden, um welche Arten von Regionen es sich handelt. WAI-ARIA sieht hierfür folgende landmark roles vor:

landmark roles
applicationEine Region, die als Webanwendung deklariert wird (im Gegensatz zu einem Webdokument). Beachten Sie dabei Intern: Die Besonderheit der ARIA-Rolle application.
bannerEine Region, die hauptsächlich Website-orientierte Inhalte enthält (im Gegensatz zu seitenspezifischen Inhalten). Die Rolle wird üblicherweise einem HEADER-Element zugewiesen, aber das ist nicht zwingend. HEADER-Elemente haben i.S.v. WAI-ARIA keine Semantik und können mehrfach pro Seite vorkommen; Die landmark role banner hingegen sollte nur einmal pro Seite vergeben werden.
complementaryEin unterstützender Abschnitt des Dokuments, der ergänzend und auf ähnlicher Ebene in der DOM-Hierarchie zu den Hauptinhalten gestaltet wird, aber aussagekräftig bleibt, wenn er vom eigentlichen Inhalt getrennt wird. Browser werden das HTML-Element ASIDE zukünftig mit dieser Rolle ergänzen; derzeit muss das role-Attribut noch verwendet werden: <aside role="complementary">
contentinfoEine große wahrnehmbare Region, die Informationen über das übergeordnete Dokument enthält (z.B. Impressum und Datenschutz). Die Rolle wird üblicherweise einem FOOTER-Element zugewiesen, aber das ist nicht zwingend. FOOTER-Elemente haben i.S.v. WAI-ARIA keine Semantik und können mehrfach pro Seite vorkommen; Die landmark role contentinfo hingegen sollte nur einmal pro Seite vergeben werden.
formEine Region, die eine Sammlung von Einträgen und Objekten enthält, die als Ganzes zu einem Formular kombiniert wird. Wenn ein Formular mit FORM aufbereitet wird, ist ein role-Attribut nicht erforderlich.
mainDer Hauptinhalt eines Dokuments. Browser werden das HTML-Element MAIN zukünftig mit dieser Rolle ergänzen; derzeit muss das role-Attribut noch verwendet werden: <main role="main"> Sowohl das HTML5-Element als auch die entsprechende Rolle dürfen nur einmal pro Seite vorkommen.
navigationEin Satz von Navigationselementen (in der Regel Links), um im Dokument oder zu verwandten Dokumenten zu navigieren. Browser werden das HTML-Element NAV zukünftig mit dieser Rolle ergänzen; derzeit muss das role-Attribut noch verwendet werden: <nav role="navigation">
searchEine landmark-Region, die ein Satz von Einträgen und Objekten enthält, die als Ganzes zu einer Suchfunktion kombiniert wird. Für diese Rolle gibt es keine Entsprechung in HTML.

Es ist keinesfalls erforderlich, die HTML5-Elemente einzusetzen. Die Rollen können genauso gut DIV-Elementen zugewiesen werden. Die Rolle für den Hauptinhalt kann z.B. wie folgt vergeben werden:

<div id="meineRegion" role="main">
  ... Hauptinhalte der Webseite ...
</div>

4. Falls unbedingt nötig, autorendefinierte Regionen anlegen

Wenn es einzelne Regionen einer Seite gibt, die mit den generischen landmark roles nicht oder nicht gut bezeichnet werden können, so können document structure roles vergeben werden. Es gibt einige spezifische Rollen wie article oder toolbar, und eine generische document structure role region. Generell sind die document structure roles nicht mit der Tastatur ansteuerbar, sondern sie fügen der Webseite zusätzliche Semantik hinzu. Generische Regionen benötigen auch eine Bezeichnung:

<main id="hauptinhalt" role="main">
  ... Hauptinhalt der Webseite ...
  <footer role="region" aria-labelledby="autor">
    <h6 id="autor">Autorenangaben</h6>
    ... Autorenangaben ...
  </footer>
</main>

Die Bezeichnung der Region erfolgt über aria-labelledby und der id der Überschrift. Ohne diese Verknüpfung wird die Region als generische Region identifiziert, vergleichbar mit "Raum" in einem Haus (es könnte Küche, Keller oder Arbeitszimmer sein).

5. Jede Region eindeutig bezeichnen

Jede Region einer Webseite sollte eindeutig identifizierbar sein. Wenn eine bestimmte Rolle nur einmal vergeben wird (was für banner, contentinfo und main auf jeden Fall gelten sollte) so kann auf eine zusätzliche Beschriftung verzichtet werden. Wenn aber beispielsweise mehrere Navigationsbereiche auf einer Webseite vorkommen, dann benötigen sie zusätzliche Bezeichnungen. Die Verwendung von Überschriften ist aus Gründen der Intern: Rückwärtskompatibilität zweckmäßig:

<nav id="meineRegion" role="navigation" aria-labelledby="breadcrumbheading">
  <h2 id="breadcrumbheading">Sie sind hier:</h2>
  ... Navigationseinträge ...
</nav>

Aussagekräftige Überschriften sind dann gewählt, wenn eine Auflistung der Überschriften — etwa in einem Inhaltsverzeichnis — Intern: außerhalb des Kontextes einen guten Überblick über Seitenaufbau und -inhalte geben.

Alternativ zu einer Verknüpfung zu einem Inhalt auf der Seite kann die Beschriftung dem Element mit der Rolle direkt zugewiesen werden:

<aside id="meineRegion" role="complementary" aria-label="Links zum Artikel">
  ... Inhalte der Region ...
</aside>

Eine andere Technik ist die Verwendung des title-Attributs:

<aside id="meineRegion" role="complementary" title="Links zum Artikel">
  ... Inhalte der Region ...
</aside>

Es gibt bei WAI-ARIA den Nachteil, dass die Ergebnisse nicht gut am Bildschirm geprüft werden können. Es gibt Extern, englischsprachig: Werkzeuge, die es erlauben, die vom Browser an die Accessibility API übermittelten Informationen zu überprüfen, aber ob ein Screenreader die Informationen tatsächlich dort abholt, ist nicht garantiert. Eine vernünftige Einschätzung der Qualität kann nur mit Screenreadern auf aktuellen Browsern überprüft werden. Bei der Entwicklung solcher Navigationskonzepte sollte in jedem Fall mit dem kostenfreien Screenreader Extern, englischsprachig: NVDA oder mit der Demo-Version des kommerziellen Screenreaders Extern: JAWS getestet werden; besser noch ist die Einbindung von blinden Nutzern bei der Überprüfung.