Vorhersehbar  

"Webseiten sind so zu gestalten, dass Aufbau und Benutzung vorhersehbar sind."

BITV 2.0, BITV - Test. Tastatur mit großer, roter Download-Taste. Smiley mit 3 grauen Haaren.

Menschen mit Behinderungen können Webseiten effizienter benutzen, wenn sie unter bestimmten Gesichtspunkten vorhersehbar funktionieren und aufgebaut sind. Tastaturnutzer müssen beispielsweise stets über die Kontrolle des Tastaturfokus verfügen, und Inhalte dürfen nur auf expliziten Wunsch des Nutzers dynamisch ausgetauscht werden. Vor allem beim Einsatz von Screenreadern oder Vergrößerungssystemen, aber auch für Menschen mit Lernbehinderungen ist eine konsistente Gestaltung ebenfalls förderlich für die Bedienbarkeit der Seite.

Accessibility-Checkliste: Vorhersehbar

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

Tastatur:

  1. Wenn Komponenten den Tastaturfokus erhalten (z.B. mit der Tab-Taste), findet keine Kontextänderung statt, z.B.:
    • Es findet keine automatische Weiterleitung (z.B. automatisches Abschicken eines Formulars) statt,
    • es findet keine automatische Aktualisierung der Seite statt,
    • es findet kein automatischer Aufruf eines neuen Anwendungsfensters statt,
    • der Inhalt der Seite wird nicht automatisch ausgetauscht oder
    • der Tastaturfokus wird nicht verändert
  2. Bei der Bedienung von Formularelementen und Widgets mit der Tastatur (z.B. Auswahl in einer Auswahlliste, Texteingabe) dürfen Kontextänderungen nur dann vorkommen, wenn der Nutzer vorher darüber informiert wurde.

Linearisierbarkeit:

Für alle Navigationsmechanismen (z.B. Navigationsleisten oder Sprunglinks) gilt:

  • die Reihenfolge der Navigationsmechanismen im Quellcode ist seitenübergreifend konsistent und
  • die Reihenfolge der Komponenten innerhalb einzelner Navigationsmechanismen bleibt seitenübergreifend unverändert.

Hinweis: Diese Kriterien gelten nur dann nicht, wenn Nutzer die Reihenfolge selbst eingestellt haben (z.B. mit Optionen auf der Website).

Visuelle Darstellung:

  1. Für alle Navigationsmechanismen (z.B. Navigationsleisten) gilt, dass die visuelle Anordnung der Navigationsmechanismen am Bildschirm seitenübergreifend konsistent ist.

    Hinweis: Dieses Kriterium gilt nur dann nicht, wenn Nutzer die Reihenfolge selbst eingestellt haben (z.B. mit Optionen auf der Website).

  2. Wenn grafische Komponenten eingesetzt werden, müssen sie konsistent gestaltet sein (z.B. Hilfefunktionen nur als Fragezeichen oder nur als Glühbirne, aber nicht gemischt).

Bezeichnungen:

  1. Komponenten mit gleicher Funktionalität müssen seitenübergreifend einheitlich bezeichnet werden.
  2. Grafiken, die als Komponenten mit gleicher oder ähnlicher Funktion eingesetzt werden, müssen einheitliche Alternativtexte erhalten (z.B. Hilfe-Icons erhalten Alternativtexte wie „Hilfe zu Ticketnummer“ und „Hilfe zu Signatur“).

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 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.
  • kein graues Haar (OK) 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

kein graues Haar (OK) Die Anforderung der BITV 2.0 ist im Einklang mit der Richtlinie aus den WCAG 2.0.

Auf Priorität I der BITV 2.0 werden vier Bedingungen zu „Vorhersehbar“ formuliert:

kein graues Haar (OK) Vor allem Tastaturnutzer sind auf den Tastaturfokus für die Durchwanderung einer Seite angewiesen. Deshalb darf nach Bedingung 3.2.1 Bei Fokussierung das Fokussieren einer Komponente (z.B. mit der Tab-Taste) nicht zu unerwarteten Kontextänderungen kommen. Kontextänderungen sind z.B.:

  • der Austausch von Inhalten auf der Seite, wenn eine Komponente den Fokus erhält,
  • das automatische Abschicken eines Formulars oder eine automatische Weiterleitung, nachdem eine Komponente den Fokus erhält,
  • das automatische Öffnen neuer Anwendungsfenster, wenn eine Komponente den Fokus erhält, oder
  • die Veränderung (Entfernung) des Fokus, nachdem eine Komponente den Fokus erhalten hat.

Das bedeutet unter dem Strich, dass der Nutzer immer die volle Kontrolle über den Tastaturfokus haben muss.

Hinweis: Der Fokus wird normalerweise durch Drücken der Tab-Taste (und in Widgets oft durch Drücken der Pfeiltasten) oder durch einen Mausklick gesetzt. Wenn ein Mausklick den Aufruf eines Links oder Abschicken eines Formulars bezweckt (und nicht dem Fokus), dann ist die Bedingung nicht anwendbar. Wenn hingegen der Mausklick der Eingabe dient (z.B. Auswahl eines Radio-Buttons) dann ist Bedingung 3.2.2 anwendbar.

kein graues Haar (OK) Wie bei Bedingung 3.2.1 geht es in Bedingung 3.2.2 Bei Eingabe in erster Linie um die Tastaturbedienung: Bei der Bedienung von Formularen (z.B. Auswahl in einer Auswahlliste) und Widgets (z.B. Bedienung einer Baumnavigation mit Pfeiltasten) soll es nicht zu Kontextänderungen kommen.

Da manche Kontextänderungen und automatische Fokusveränderungen aus Gründen der Usability vorteilhaft sind (z.B. der Fokus wird zum nächsten Eingabefeld bewegt, nachdem fünf Zahlen in ein Feld „Postleitzahl“ eingegeben wurden) muss das dynamische Verhalten textlich angekündigt werden. Kontextänderungen sind im barrierefreien Webdesign nur dann angemessen bei der Bedienung von Komponenten, wenn der Nutzer sie erwarten kann.

kein graues Haar (OK) Die Bedingung 3.2.3 Einheitliche Navigation spricht die Reihenfolge von Navigationsmechanismen aus zwei verschiedenen Perspektiven an. Außer wenn Nutzer eine Möglichkeit nutzen, die Reihenfolge selbst einzustellen,

  1. muss die Reihenfolge von Links innerhalb eines Navigationsmechanismus konsistent sein. Während Untermenüs bei Bedarf beispielsweise innerhalb eines übergeordneten Menüs angezeigt werden dürfen (z.B. in verschiedenen Rubriken einer Website), darf die Reihenfolge innerhalb der einzelnen Navigationsmechanismen nicht unterschiedlich sein (z.B. indem die aktuelle Rubrik vor allen anderen Einträgen steht).
  2. Die Position einzelner Navigationsmechanismen muss ebenfalls gleich sein. Das betrifft einerseits die Position im Quellcode (z.B. am Anfang der Seite steht zuerst ein Sprunglink, dann ein Suchformular, usw.), und andererseits die visuelle Positionierung am Bildschirm.

ein graues Haar Komponenten mit gleicher oder ähnlicher Funktion sollten nach 3.2.4 Einheitliche Bezeichnung seitenübergreifend konsistent aufbereitet werden. Das betrifft vor allem

  • die Beschriftung von Komponenten (z.B. „Suchen“ für entsprechende Schaltflächen und nicht mal „Suchen“ und mal „Finden“),
  • den Einsatz von Icons (z.B. immer das gleiche Icon für eine Hilfefunktion und nicht etwa mal ein Fragezeichen und mal eine Glühbirne) und
  • die Alternativtexte von grafischen Komponenten (z.B. beginnt der Alternativtext eines Hilfe-Icons immer mit den Worten „Hilfe zu …“).

Die textlichen Anforderungen (Bezeichnungen und Alternativtexte) sind deshalb wichtig, weil sie dann mit der üblichen Suchfunktion (z.B. Strg+F auf Windows-Systemen) schneller gefunden und per Tastatur erreicht werden können.

In den WCAG 2.0 wird die konsistente Erkennung von Komponenten in den Vordergrund gestellt. Nach der BITV 2.0 werden die visuellen Aspekte nicht berücksichtigt, indem nur die konsistente Bezeichnung gefordert wird.

„BITV-Test“ und BITV 2.0

Der „BITV-Test“ bietet drei Prüfschritte zu Anforderung 3.2 („Vorhersehbar“) an:

ein graues Haar Prüfschritt 3.2.1a Kein Öffnen neuer Fenster beim Laden der Seite stellt ein Rätsel dar. Dort wird geprüft, ob kein zweites Fenster beim Laden einer Webseite angezeigt wird. Das ist sicher auch eine Best-Practice-Technik, aber mit Bedingung 3.2.1 hat das nichts zu tun. Dieser Prüfschritt prüft einen Teilaspekt von Bedingung 3.2.5 auf Prioritätsstufe II.

Überhaupt wird die Kontextänderung bei Fokus im „BITV-Test“ nicht behandelt und bestenfalls in Prüfschritt 2.1.1a gestreift.

kein graues Haar (OK) In Prüfschritt 3.2.2a Keine unerwartete Kontextänderung bei Eingabe wird die Grundidee von Bedingung 3.2.2 aufgegriffen, aber interessanterweise werden Aspekte der bedeutungstragenden Reihenfolge (Bedingung 1.3.2) als Erklärung genutzt. Abgesehen von der unklaren Abgrenzung ist der Prüfschritt auf Formulare beschränkt und schließt beispielsweise Widgets nicht ein. Mit gutem Willen lässt sich die Bedingung 3.2.2 aber prüfen.

ein graues Haar In Prüfschritt 3.2.3a Navigation einheitlich wird ein Sammelsurium von Aspekten der Webgestaltung geprüft:

  • Zahlreiche Allgemeine Usability-Kriterien, die nicht von der BITV 2.0 abgedeckt sind
  • Einheitliche Bezeichnung von Links (leitet sich von Bedingung 3.2.4 ab)
  • Linktexte in Menüs (Bedingung 2.4.4)
  • Bezeichnung von Frames (Bedingung 4.1.2)

Die Reihenfolge von UI Komponenten und Optionen zur Änderung der Reihenfolge, um die es in Bedingung 3.2.3 geht, werden nicht behandelt. Lediglich an einer Stelle wird erwähnt, dass Navigationsleisten „gleich angeordnet“ sein sollen, was sich ein wenig wie „nachträglich hinzugefügt“ liest. Wie aber an vielen anderen Stellen auch, ist das eigentliche Problem die nicht zuverlässige Anwendbarkeit des Prüfschritts. Prüfer sollen beispielsweise die Einhaltung von Konventionen oder die Nutzung eingebürgerter Bezeichnungen bewerten, ohne dass solche Begriffe erläutert werden.

Mit diesem Prüfschritt kann im Übrigen die Bedingung 3.2.4 bedingt geprüft werden (es kann die konsistente Erkennung von Links, aber nicht von anderen Komponenten geprüft werden), aber der Prüfschritt bezieht sich insgesamt nicht auf die BITV 2.0.

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:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert