Per Tastatur zugänglich – "Für die gesamte Funktionalität ist Zugänglichkeit über die Tastatur sicherzustellen."

Komponente (Links, Formulare, Widgets usw.) müssen per Tastatur bedient werden können. Genauer gesagt, sie müssen über eine Tastaturschnittstelle zugänglich sein, denn neben der klassischen Tastatur – auf die bestimmte Nutzergruppen angewiesen sind – gibt es Spracheingabe, Bildschirmtastaturen und andere Eingabemöglichkeiten, die auf der Tastaturschnittstelle aufsetzen.

Accessibility-Checkliste: Per Tastatur zugänglich

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

Alle Links, Formularelemente und Widgets (auch innerhalb eingebetteter Objekte) müssen ausschließlich mit der Tab-Taste erreicht und wieder verlassen werden können. Dabei gilt:
- Links müssen per Eingabe-/Leertaste aufgerufen werden können,
- Formularelemente müssen per Eingabe-/Leertaste aktiviert oder deaktiviert werden können bzw. mit den üblichen Tasten (z.B. Pfeiltasten) bedient werden können.
- Widgets (von einfachen Tri-State-Checkboxen über Tab-Panels und Drag and Drop bis hin zu komplexeren Anwendungen wie Rich-Text-Editoren) müssen ebenfalls per Tab-Taste erreicht, aber mit einem Bedienkonzept (u.a. mit Pfeiltasten, Tastenkombinationen) für die Tastatur ausgestattet werden. Die Bedienung mit der Tab-Taste innerhalb von Widgets ist im Allgemeinen zulässig, aber oft nicht empfehlenswert.
Wenn Inhalte wie eingebettete Objekte oder eingeblendete Inhalte nicht mit typischen Tasten wie Tab-Taste oder Esc-Taste verlassen werden können, aber es eine per Tastatur zugängliche andere Möglichkeit gibt, dann muss der Nutzer darüber informiert werden.
Wenn die Eingabe bestimmte Eingabegeräte voraussetzt (z.B. Malen, Handschrift, Fingerabdruck) und die dahinterliegende Funktion per Tastatur möglich ist (z.B. Texteingabe bei der handschriftlichen Eingabe), dann muss es eine Möglichkeit geben, die dahinterliegende Funktion per Tastatur zu bedienen.

Hinweis: Die Erreichbarkeit und/oder Bedienbarkeit von Links, Formularelementen oder Widgets mit der Tastatur kann von Event-Handlern abhängig sein. Sofern es sich dabei um die Veränderung des Fokus durch Skripts handelt, greifen auf Konformitätsstufe AA die Erfolgskriterien 3.2.1 und 3.2.2.

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 ist im Einklang mit der Richtlinie aus den WCAG 2.0.

Auf Priorität I der BITV 2.0 werden zwei Bedingungen zu „Per Tastatur zugänglich“ formuliert:

Nach Bedingung 2.1.1 Tastaturbedienbarkeit müssen alle Links, Formularelemente und Widgets mit der Tastatur bzw. über eine Tastaturschnittstelle erreicht und bedient werden können. Das gilt insbesondere für:

Alle Links und Formularelemente müssen mit der Tab-Taste erreicht werden können. Das kann vor allem in Flash und PDF problematisch werden, aber auch auf Webseiten kann die Tastaturnutzung eingeschränkt und eine Reparatur mit tabindex=“0″ erforderlich sein.
Alle Links müssen mit der Eingabe- bzw. Leertaste aktiviert werden können. Auch hier gilt: Reparaturen können notwendig sein, indem das HTML-Element <a> für Links anstatt <span> eingesetzt wird oder zusätzliche tastaturspezifische Event-Handler berücksichtigt werden.
Sämtliche Komponente müssen per Tastatur bedient bzw. aktiviert werden können:
- Generell sollten Formularelemente mit den in HTML vorgesehenen Elementen aufbereitet werden, weil die HTML-Elemente die Tastaturbedienung „frei Haus“ liefern.
- Widgets (z.B. Tab-Panels, Akkordeons oder Baumstrukturen) benötigen i.d.R. ein eigenes Bedienkonzept für die Tastatur. Die Bedienung mit Tab-Taste und Eingabe- oder Leertaste reicht für die meisten Widgets nicht aus. Für Widgets gibt es ausführliche und besser geeignete Design-Patterns, die u.a. mit Pfeiltasten und Tastenkombinationen eine effizientere Bedienung erlauben.
Interaktive eingebettete Objekte (z.B. Multimedia-Player) müssen per Tastatur erreicht und die einzelnen Komponenten per Tastatur bedient werden können.

Zu vermeiden sind zeitabhängige Tastenschläge. Weder das Drücken mehrerer Tasten innerhalb einer bestimmten Zeit noch das Drücken einer Taste über eine bestimmte Zeitspanne können als barrierefrei angesehen werden. Wenn beispielsweise eine Webseite Shortcuts für bestimmte Aktionen bietet, dann sind sie solange kein Problem, wie die dahinterliegenden Funktionen auf anderer Weise per Tastatur aufgerufen werden können.

Obwohl fast alle Aktionen, die mit der Maus ausgeführt werden können, auch per Tastatur zugänglich gemacht werden können, so gibt es bestimmte Eingabefunktionen (z.B. Zeichnen mit dem Mauszeiger, Handschrift, Fingerabdruck), die per Tastatur nicht eingegeben werden können. Für einige Eingabefunktionen gibt es alternative (per Tastatur zugängliche) Eingabemöglichkeiten (z.B. Texteingabe statt Handschrift), aber das gilt nicht für jede solche Funktion (z.B. Fingerabdruck). Solche besonderen Eingabefunktionen werden in Bedingung 2.1.3 auf Priorität II behandelt.

Die Tastaturbedienung gehört sicher zu den wichtigsten Kriterien des barrierefreien Webdesigns. Deshalb wird mit 2.1.2 Keine Tastaturfalle ein besonders kritischer Aspekt der Tastaturbedienung gesondert aufgeführt. Wenn über eine Tastaturschnittstelle zwar ein bestimmtes Element oder eine Gruppe von Elementen erreicht, aber nicht mit den üblichen Tasten (u.a. Tab- oder Esc-Taste) verlassen werden kann, dann befindet sich ein Tastaturnutzer in einer Tastaturfalle und die Webseite kann nicht mehr der Reihe nach navigiert werden. Das kommt bei eingebetteten Plugins (z.B. Flash-Player) vor, aber eine Tastaturfalle kann auch in dynamischen Anwendungen mit JavaScript entstehen.

Sollte die Tastaturfalle per Tastatur verlassen werden können, aber nur durch besondere (nicht offensichtliche) Tastendrucke, dann müssen Tastaturnutzer über diese Möglichkeit informiert werden.

Dieses Kriterium ist nach den WCAG 2.0 einer von vier Erfolgskriterien, die für eine Konformität zwingend einzuhalten sind. Wenn Bedingung 2.1.2 der BITV 2.0 nicht erfüllt wird, werden Tastaturnutzer gezwungen, die Seite neu zu laden, die Zurückfunktion des Browsers zu tätigen oder die Webseite nicht zu nutzen. In der BITV 2.0 selbst wird diese Grundvoraussetzung für die Barrierefreiheit nicht berücksichtigt.

„BITV-Test“ und BITV 2.0

Der „BITV-Test“ bietet einen Prüfschritt zu „Per Tastatur zugänglich“ an:

In Prüfschritt 2.1.1a Ohne Maus nutzbar werden einzelne Aspekte der beiden oben beschriebenen Bedingungen sowie Bedingungen der Anforderung 3.2 aus der BITV 2.0 angesprochen. Insgesamt ist der Prüfschritt nicht präzise genug formuliert. Beispiele sind:

In der Prüfanleitung sollen nur „wesentliche“ Links und Formularelemente geprüft werden. Dabei wird in der BITV 2.0 klar formuliert, dass die gesamte Funktionalität bei der Tastaturbedienbarkeit einzuschließen ist.
Es gibt nur zwei Hinweise auf Tastaturfallen (Flash und Google-Maps in Firefox), obwohl dieses Kriterium auch in anderen Situationen auftreten kann – vor allem bei dynamisch eingeblendeten Inhalten.

Abgesehen von einigen nicht zuverlässig anwendbaren Prüfanleitungen greift der Prüfschritt deutlich zu kurz und lässt keine ausreichende Überprüfung der Bedingungen aus der BITV 2.0 zu:

Der Prüfschritt lässt nur eine minimalistische Prüfung der Tastaturbedienbarkeit zu. Gerade Widgets werden mehr oder weniger vernachlässigt. Es gibt dazu lediglich zwei Hinweise in der Prüfanleitung:

Im Prüfschritt wird im Abschnitt zur Bewertung die Anzeige von Inhalten in Tab-Panels per Pfeiltaste als Mangel aufgeführt. Zum einen müssen Tab-Panels nach WAI-ARIA mit Pfeiltasten bedient werden (und nicht etwa mit der Tab-Taste) und zum anderen werden in den Prüfanleitungen keine Hinweise geliefert, wie eine solche Bewertung als Mangel begründet werden kann.
Überhaupt wird die Tastaturbedienung von Widgets nur anhand eines einzigen Beispiels (Drag and Drop) in den Hinweisen erläutert. Der Hinweis müsste dabei als Prüfanleitung formuliert werden.

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:

1 Gedanke zu “Per Tastatur zugänglich – "Für die gesamte Funktionalität ist Zugänglichkeit über die Tastatur sicherzustellen."”

Jacob Wagner sagt:

1. Juli 2020 um 13:43 Uhr

Herzlichen Dank für den hilfreichen Post!
Sehr schön Blog.

Antworten