Navigierbar – "Der Nutzerin oder dem Nutzer sind Orientierungs- und Navigationshilfen sowie Hilfen zum Auffinden von Inhalten zur Verfügung zu stellen."

Die Navigation innerhalb von Webseiten und Websites muss für alle Nutzer gewährleistet werden. Die Navigation innerhalb einer Webseite muss beispielsweise für Tastaturnutzer und insbesondere Screenreadernutzer effizient gestaltet werden. Darüber hinaus müssen Navigationsleisten zum einen die Orientierung innerhalb des Webauftritts fördern und zum anderen die Auffindbarkeit anderer Inhalte auf der Website erleichtern.

Accessibility-Checkliste: Navigierbar

Diese Accessibility Checkliste hilft bei der Überprüfung einer Webseite auf Konformität zu den Erfolgskriterien der Richtlinie 2.4 (Konformitätsstufe AA) der Web Content Accessibility Guidelines (WCAG) 2.0 bzw. den Bedingungen der Anforderung 2.4 (Priorität I) der Barrierefreien Informationstechnik-Verordnung – BITV 2.0.

Tastaturbedienung:

Sich auf mehreren Seiten wiederholende Bereiche (z.B. Navigationsleisten) müssen mit der Tastatur übersprungen werden können:
- Wenn Nutzer über ein Mechanismus verfügen (z.B. die strukturelle Navigation in Screenreadern), so können die Blöcke anhand von Code-Merkmalen (z.B. landmark roles oder Überschriften) übersprungen werden.
- Für die Nutzung der Tab-Taste sollten Sprunglinks berücksichtigt werden.
Bei fokussierbaren Inhalten muss die Fokus-Reihenfolge auf der Webseite konsistent mit der Bedeutung der Inhalte sein. Die Fokus-Reihenfolge wird bei Links und Formularelementen durch die Tab-Taste erreicht, aber in Widgets kann die Fokus-Reihenfolge durch andere Tasten (z.B. Pfeiltasten) vorgesehen sein.
Der Systemfokus darf nicht unterdrückt werden, sondern muss übernommen oder per CSS verstärkt werden.

Navigation und Orientierung:

Jede Webseite benötigt einen beschreibenden <title>.
Jede Seite muss über zwei unterschiedliche Methoden erreichbar sein (außer in aufeinander folgende Seiten in einem Prozess). Zu diesen Methoden können Navigationsleisten, Suchfunktion, Sitemap oder andere Linklisten zählen.
Die Einordnung einer Seite innerhalb eines Webauftritts oder einer Webanwendung sollte verdeutlicht werden (nur nach BITV 2.0). Es können diverse Techniken dafür eingesetzt werden, etwa Hervorhebungen in den Navigationsleisten, Bread-Crumbs, eine Sitemap auf der Seite oder META-Tags.

Texte:

Linktexte (einschließlich Alternativtexte für verlinkte Grafiken und für <area> in Image-Maps) müssen alleine oder im Kontext Auskunft über den Linkzweck geben. Der Kontext wird
- durch Einbettung des Links in einen Satz,
- durch Text im umgebenden Absatz oder in der umgebenden Liste oder
- durch andere in Beziehung stehende Texte (<th> in Tabellen, übergeordnetes Listenelement, vorstehende Überschrift oder mit ARIA-Techniken verknüpfte Texte).
usw. technisch von einem Screenreader ermittelt.
Wenn Beschriftungen vorhanden sind, müssen die Beschriftungen (und – falls abweichend – Bezeichnungen) von Komponenten beschreibend sein.
Wenn Überschriften vorhanden sind, müssen die Überschriftentexte beschreibend sein.

Weitere Accessibility-Checklisten

Graue Haare

Dieser Beitrag ist Teil der Serie "Accessibility-Checkliste gegen graue Haare". Zuletzt musste ich mich mit der Barrierefreien Informationstechnik-Verordnung (BITV) 2.0 auseinandersetzen, die gerne als deutsche Fassung der Web Content Accessibility Guidelines (WCAG) 2.0 angesehen wird. Die BITV 2.0 weicht allerdings erstaunlich oft von den WCAG 2.0 ab.

Im Zuge der Untersuchung musste ich mich auch mit dem sogenannten "BITV-Test" der DIAS GmbH - eine Prüfanleitung für barrierefreies Webdesign - auseinandersetzen, um seine Zuverlässigkeit zu bewerten. Auffällig war insbesondere die deutliche Abweichung des "BITV-Tests" von der BITV 2.0 (und den WCAG 2.0).

Diese beiden Umstände haben mich dazu veranlasst, graue Haare für die BITV 2.0 und den "BITV-Test" wie folgt zu vergeben:

Ein graues Haar gibt es für die BITV 2.0, wenn eine Anforderung oder eine Bedingung inhaltlich von den WCAG 2.0 abweicht. Ein graues Haar gibt es auch für einzelne Prüfschritte im "BITV-Test", wenn
1. im Prüfschritt die Bedingung aus der BITV 2.0 nicht geprüft werden kann (z.B. weil nur eine Best-Practice-Technik geprüft wird),
2. im Prüfschritt etwas geprüft wird, das nicht in der BITV 2.0 verlangt wird und
3. der Prüfschritt so allgemein gehalten wird, dass er nicht zuverlässig eingesetzt werden kann.
Für solche Anforderungen und Bedingungen der BITV 2.0, die im Einklang mit den Richtlinien und Erfolgskriterien aus den WCAG 2.0 sind, und solche Prüfschritte im "BITV-Test", die eine Überprüfung der BITV 2.0 zulassen, gibt es drei farbige Haare und ein "OK".

BITV 2.0 (Anlage 1) und WCAG 2.0

Die Anforderung der BITV 2.0 „Navigierbar“ weicht ein wenig von der entsprechenden Richtlinie in den WCAG 2.0 ab, indem „Hilfen“ für Nutzer zur Verfügung zu stellen sind (im Gegensatz zur generischeren Ausdrucksweise „Mittel einsetzen“ nach den WCAG 2.0). Für die Praxis ist das nicht relevant, denn die konkreteren Bedingungen sind es, die erfüllt sein müssen.

Auf Priorität I der BITV 2.0 werden acht Bedingungen zu „Navigierbar“ formuliert:

Nach Bedingung 2.4.1 Umgehen von Elementgruppen müssen Tastaturnutzer sich wiederholende Inhalte auf Webseiten (dazu zählen insbesondere Navigationsleisten) überspringen können. Primär zielt dieses Kriterium auf die strukturelle Navigation in Screenreadern ab, die über Mechanismen verfügen, Strukturmerkmale einer Webseite anzuspringen und überspringen zu können. Wenn auf einer Webseite beispielsweise

die verschiedenen Regionen einer Webseite (Kopf, Navigation, Hauptinhalt usw.) mit Landmark roles oder den entsprechenden HTML5-Elementen (z.B. <nav>) ausgezeichnet werden oder
Die Regionen eine vorangestellte (unsichtbare) Überschrift erhalten oder
Navigationsmechanismen als Listen strukturiert werden,

können Screenreadernutzer diese Inhalte überspringen.

Für sehende Tastaturnutzer sind solche Mechanismen, die durch die Struktur im HTML ermöglicht werden, meist nicht zugänglich. Deshalb sollten Webseiten mit Sprunglinks ergänzt werden, um beispielsweise Navigationsleisten mit der Tab-Taste überspringen zu können.

Für Screenreadernutzer ist der Titel einer Webseite die erste Information über den Inhalt. Auch für andere Nutzer kann der Titel eine wichtige Orientierungshilfe sein (z.B. wenn der Titel in einem nicht geöffneten Reiter angezeigt wird). Nach Bedingung 2.4.2 Webseiten-Titel muss deshalb ein inhaltsbezogener und aussagekräftiger Titel für jede Seite eingesetzt werden. Das kann so weit gehen, dass in Prozessen der Titel für Status- und Fehlermeldungen genutzt wird (z.B. Fehlermeldung bei Formularen oder Ergebnis einer Suchanfrage).

Neben der Lese-Reihenfolge (Bedingung 1.3.2) muss nach 2.4.3 Fokus-Reihenfolge die Fokus-Reihenfolge stimmig sein, d.h. die Navigation mit der Tab-Taste muss auf eine Weise möglich sein, die mit der Bedeutung der Inhalte konsistent ist. Auf statischen Webseiten folgt im Allgemeinen die Fokus-Reihenfolge der Lese-Reihenfolge. Konkret geht es um folgende Aspekte:

Eine bestimmte Fokus-Reihenfolge ist nur dann notwendig, wenn die Reihenfolge Bedeutung und Bedienbarkeit beeinflusst.
Es kann mehr als eine „richtige“ Fokus-Reihenfolge geben.
Es muss nur eine richtige Reihenfolge berücksichtigt werden.

Die Fokus-Reihenfolge wird vor allem dann relevant,

wenn Inhalte zu einer Webseite dynamisch hinzugefügt werden (z.B. Modalfenster oder Kalender-Widgets) oder
wenn das tabindex-Attribut eingesetzt wird (das aber auch zur Korrektur der Fokus-Reihenfolge eingesetzt werden kann).

Über die Tab-Taste hinaus müssen in Widgets die Bedienkonzepte für die Tastatur zusätzlich berücksichtigt werden, etwa wenn in einer Baum- oder Reiternavigation der Fokus mit Pfeiltasten gesteuert wird.

Diese Bedingung ist nur anwendbar, wenn eine Webseite über die Tastaturschnittstelle navigierbar ist. Hinweis: Diese Voraussetzung fehlt in der BITV 2.0.

Nach 2.4.4 Zweck eines Links (im Kontext) müssen Linktexte – einschließlich Alternativtexte verlinkter Grafiken – aussagekräftig sein oder zusammen mit ihrem Kontext auf den Linkzweck schließen lassen. Der Kontext eines Links muss technisch betrachtet werden; wenn der Linkzweck nicht aus dem Linktext selbst hervorgeht, dann

Muss der Satz oder der Absatz, in dem der Link steht, Auskunft über den Linkzweck geben oder
Eine zugehörige Kopfzelle in einer Tabelle, ein übergeordneter Listenpunkt oder vorstehende Überschrift muss als Kontext herangezogen werden können oder
Der Linktext wird mit ARIA-Techniken für Screenreadernutzer ersetzt oder mit anderem Inhalt verknüpft, um einen Kontext herzustellen.

Im Gegensatz zum WCAG-Erfolgskriterium, in dem der Linkzweck ermittelbar sein muss, verlangt die BITV-Bedingung, dass sowohl Ziel und Zweck eines Links ermittelt werden muss. Warum diese Ergänzung berücksichtigt wurde, ist nicht klar, denn Browser und Screenreader können das Ziel eines Links problemlos anzeigen bzw. ermitteln.

Die BITV-Bedingung berücksichtigt darüber hinaus eine Ausnahme aus den WCAG 2.0 nicht, nämlich für Linktexte, die – auch im Kontext – für jeden mehrdeutig sind. Wenn beispielsweise in einem Artikel in dem Satz „Zwischenzeitlich wird WAI-ARIA von Browsern gut unterstützt.“ das Wort „WAI-ARIA“ verlinkt wird, und der Link zu einem Erläuterungstext auf der gleichen Webseite führt (und nicht etwa zur Spezifikation des W3C), dann ist der Linktext nicht eindeutig. Das Weglassen der Ausnahme stellt eine kaum zu erfüllende Anforderung dar und kommt in vielen Fällen einem Verbot von kontextuellen Links gleich; das entspricht dem Kriterium aus den WCAG 2.0 nicht.

Weil nicht jeder Nutzer mit jeder Art der Navigation klar kommt, müssen nach Bedingung 2.4.5 Alternative Zugangswege für jede aufrufbare Webseite mindestens zwei Navigationspfade vorhanden sein. Das kann ein Pfad über die Navigationsleiste und die Suchfunktion sein. Eine Sitemap oder weitere Techniken (z.B. mit <link>) können ebenfalls zur Erfüllung des Kriteriums eingesetzt werden.

Mit Bedingung 2.4.6 Beschreibungen wird einer besonderen Möglichkeit der Navigation Rechnung getragen, die in Screenreadern implementiert ist. Mit Screenreadern können u.a. Überschriften und Formularelemente aufgelistet werden, um sie direkt anspringen zu können.

Bei Beschriftungen ist zu unterscheiden:

Es kann eine sichtbare Beschriftung geben.
Eine Komponente kann eine andere Bezeichnung haben.

Eine Beschriftung ist nicht notwendigerweise mit einer Komponente verknüpft (vgl. Bedingung 1.3.1). In diesem Fall muss die Bezeichnung der Komponente ebenfalls beschreibend sein.

Überschriftentexte und Beschriftungen von Komponenten, die Thema oder Zweck beschreiben, können für jeden Nutzer eine wichtige Orientierung sein. Deshalb müssen Überschriftentexte und Beschriftungen – sofern Überschriften und Beschriftungen vorhanden sind – beschreibend sein.

Nach Bedingung 2.4.7 Sichtbarer Fokus muss gewährleistet werden, dass bei Tastaturbedienung stets ein Fokus-Indikator sichtbar ist. Das gilt sowohl bei Verwendung der Tab-Taste als auch bei der Bedienung von Widgets mit anderen Tasten.

Die BITV-Bedingung weicht von den Kriterien aus den WCAG 2.0 ab. Die WCAG 2.0 geben vor, dass der Fokus-Indikator entweder durch die Webseite oder durch den Browser sichtbar gemacht werden muss. Die BITV 2.0 schließt Browsereinstellungen nicht ein.

Warum Bedingung 2.4.8 Standort mit Priorität I belegt ist, wird in der BITV 2.0 nicht klar. Nach den WCAG 2.0 handelt es sich um ein Erfolgskriterium der Konformitätsstufe AAA, d.h. nach der Systematik der BITV 2.0 müsste das Kriterium die Priorität II erhalten. Darüber hinaus verlangt die BITV-Bedingung Angaben zum Standort innerhalb einer Webseite und nicht nur innerhalb eines Webauftritts.

Mit dieser Bedingung kann Nutzern bei der Orientierung innerhalb einer Website geholfen werden, indem die Einordnung einer Webseite innerhalb eines Satzes von Webseiten angezeigt wird. Hierzu könnenHervorhebungen in der Navigation, Bread-Crumbs oder Metatags genutzt werden.

„BITV-Test“ und BITV 2.0

Der „BITV-Test“ bietet neun Prüfschritte zu Anforderung 2.4 („Navigierbar“) an:

Der Prüfschritt 2.4.1a Inhaltsbereiche strukturiert bietet eine Prüfanleitung entsprechend der BITV 2.0. Hinweis: Es werden einige andere Bedingungen mitgeprüft, etwa beschreibende Überschriftentexte (Bedingung 2.4.6), der sichtbare Fokus (Bedingung 2.4.7) oder die Beschriftung von Frames (Bedingung 4.1.2).

Der Prüfschritt 2.4.2a Sinnvolle Dokumenttitel wird an zwei Stellen nicht von der BITV 2.0 abgedeckt:

Es werden zusätzliche Anforderungen an den Inhalt des <title> gestellt, indem der Name der Webseite berücksichtigt werden soll. Nach der BITV 2.0 ist es ausreichend, wenn Thema und Zweck der Seite (ein Inhaltsbezug) benannt werden.
Es werden außerdem <title> für per Frame-Element eingebundene Webseiten gefordert; der Nutzen ist dabei fraglich.

Mit Prüfschritt 2.4.3a Schlüssige Reihenfolge bei der Tastaturbedienung wird geprüft, ob die Tab-Reihenfolge nachvollziehbar ist. Der Prüfschritt ist nicht dafür geeignet, Widgets mit eigenem Bedienkonzept und insbesondere Fokus-Steuerung mit anderen Tasten zu prüfen. Insgesamt greift der Prüfschritt durch die Beschränkung auf die Tab-Taste zu kurz.

Der Prüfschritt 2.4.4a Aussagekräftige Linktexte bietet eine Prüfanleitung entsprechend der BITV 2.0. Hinweis: Dass die BITV-Bedingung vom WCAG-Kriterium abweicht, wird im Prüfschritt nicht berücksichtigt.

Mit Prüfschritt 2.4.4b Links informieren über Dateiformat wird etwas geprüft, das weder in der BITV 2.0 noch in den WCAG 2.0 verlangt wird. Obwohl die Angabe eines Formats in einem Linktext eine wichtige Information für den Nutzer sein kann, so handelt es sich bei der Angabe bestenfalls um eine Best-Practice-Technik. Die Prüfanleitung zielt auf eine Kontextänderung ab, aber in den Richtlinien sind lediglich dynamische Kontextänderungen angesprochen (vgl. Anforderung 3.2).

Der Prüfschritt 2.4.5a Alternative Zugangswege bietet eine Prüfanleitung entsprechend der BITV 2.0. Hinweis: Prozesse werden in der Prüfanleitung angesprochen, obwohl sie in der BITV 2.0 explizit ausgenommen werden.

Prüfschritt 2.4.6a Title-Attribut für Symbole stellt ein Rätsel dar. Dort wird geprüft, ob Symbole ein Tooltipp haben. Das ist sicher auch eine Best-Practice-Technik, aber mit Bedingung 2.4.6 hat das nichts zu tun. Im Abschnitt zur Einordnung des Prüfschritts wird die Anforderung 1.3 aufgeführt, aber da passt die Technik auch nicht hin. Unter dem Strich gibt es keine Bedingung in der BITV 2.0, die diesen Prüfschritt begründet.

Im „BITV-Test“ wird die Bedingung 2.4.6 nicht explizit geprüft:

Überschriftentexte werden in den Prüfschritten 1.3.1a und 2.4.1a geprüft.
Formularbeschriftungen werden in Prüfschritt 3.3.2a geprüft.

In Prüfschritt 2.4.7a Aktuelle Position des Fokus deutlich wird die Bedingung 2.4.7 aus der BITV 2.0 teilweise geprüft. Folgende Probleme weist die Prüfanleitung auf:

Sie ist nur für Links, nicht aber für Formulare oder Widgets anwendbar.
Sie ist an den Mouse-Over-Effekt gekoppelt. Die Bedingung verlangt aber, dass der Fokus immer sichtbar sein muss (unabhängig von Mouse-Over-Effekten).

Bei den Fragen zum Prüfschritt wird darüber hinaus auf die Frage, ob der Tastaturfokus nicht Sache des Browsers sei, missverständlich geantwortet, indem die „Verantwortung“ auf die Webseite geschoben wird. Im Browser kann aber ein Fokus-Indikator erzwungen werden.

Der Prüfschritt 2.4.8a Position im Webauftritt klar ist vergleichsweise vage formuliert, was beispielsweise durch die fehlenden Bewertungsalternativen gezeigt wird. Problematisch in diesem Prüfschritt ist aber, dass regelmäßig Bread-Crumbs und Links erwähnt werden, aber die Bedingung in der BITV 2.0 lediglich die Berücksichtigung von Informationen zum Standort vorgibt.

Zur Serie "Accessibility-Checkliste gegen graue Haare

Den Anlass für diese Serie finden Sie im einleitenden Beitrag Accessibility-Checkliste gegen graue Haare beschrieben.

Es ist wichtig, dass es in Deutschland Regelungen zur Barrierefreiheit im Web gibt. Allerdings steht die BITV 2.0 in Widerspruch zu internationalen Webstandards und weiteren Industrienormen, was in der Praxis durchaus ein Problem darstellt. Dass der "BITV-Test" diese Differenzen nicht relativiert, sondern verstärkt, hat zur Folge, dass barrierefreies Webdesign in Deutschland missverstanden wird. Die WCAG 2.0 sind stabile und international anerkannte Standards, die in den erläuternden Dokumenten laufend auf den aktuellen Stand der Technik gehalten werden. Die BITV 2.0 ist hingegen starr, und der "BITV-Test" bietet keinesfalls eine geeignete Basis, eine Konformität zu der BITV 2.0 (oder den WCAG 2.0) reliabel zu überprüfen.

Die Serie besteht aus einer Reihe von Checklisten, die jeweils die einzelnen Anforderungen der BITV 2.0 abbilden. Ergänzt werden die Checklisten mit Kritik an einzelne Bedingungen der BITV 2.0 und Kritik an einzelne Prüfschritte im "BITV-Test". Insgesamt handelt es sich bei dieser Serie um 12 Accessibility-Checklisten, die bei Bedarf auch aktualisiert werden: