sprungmarker testet

Tastaturbedienbarkeit: ein Vergleich (WCAG 2, BIENE, BITV-Test)

Wie so vieles in der Barrierefreiheit, wenn wir uns die gesetzlichen oder testbaren Rahmenbedingungen ansehen, wird unterschiedlich gewichtet. Da ich mich derzeit verstärkt mit der Tastaturbedienbarkeit auseinandersetze (Stichwort: A-Tag), habe ich mir die Anforderungen zur Tastaturbedienbarkeit von WCAG 2, BIENE und dem BITV-Test der BIK vorgenommen.

Für den BITV-Test habe ich auch schon die Neuentwürfe des Tests berücksichtigt, auch wenn diese noch nicht in Kraft getreten sind. Leider konnte ich die BITV 2 immer noch nicht einbeziehen, weil es ja bis dato noch nicht zur Verfügung steht.

Freilich sind es oft nur Nuancen in den Anforderungen zur Tastaturbedienbarkeit, aber ich war schon etwas überrascht darüber – denn auch Nuancen können im Entwickleralltag entscheidend sein.

Erreichbarkeit mit Hilfe der Tastatur

In der Erreichbarkeit sind sich eigentlich alle grundsätzlich einig. Erreichbarkeit meint, dass alle Funktionen und Inhalte mit Hilfe der Tastatur benutzbar – erreichbar – sein müssen (WCAG 2, 2.1.1) Das WCAG 2 macht hier wieder die hübsche Schere auf. Auf Level AA sind Ausnahmen noch erlaubt, auf Level AAA nicht. Es differiert eher nur die sprachliche Begrifflichkeit. Die BIENE (Kriterium 19) spricht hierbei eher von der Tastatur her, dass jegliche Funktion über die alleinige Verwendung der Tastatur erreichbar sein muss. Auch der BITV-Test (Prüfschritt 9.2.1) spricht von der Ausschließlichkeit, mit der mit Hilfe der Tastatur die Webseite benutzbar sein muss. Eine kleine Einschränkung macht der BITV-Test hierbei noch: die Nutzung muss nicht exakt der Mausbedienung entsprechen. Als Beispiel wird das Selectfeld angeführt, es wird nicht negativ gewertet, wenn in einem Aufklappmenü per Tastatur die Unterpunkte nicht erreicht werden können, also ein Tastaturnutzer quasi mehr Arbeit investieren muss, bis er zu den Unterpunkten kommt. Das ist zwar nur ein Beispiel, aber macht schon die Problematik ganz gut auf. Diese Einschränkung ließe sich durchaus auf weitere Skripte ausdehnen. Sollte man überdenken, es gibt durchaus genug Ausklappmenüs, die per Tastatur bedienbar sind. 🙂

Vermeidung von Sackgassen

Erreichbarkeit meint natürlich auch, dass man sich mit Hilfe der Tastatur nicht in eine Sackgasse manövriert. Die WCAG 2 formuliert das immer so schön einfach, dass jedes fokussierte Element auch wieder verlassen werden kann – und das schon ganz richtig für Level A der Fall (WCAG 2, 2.1.2). Die BIENE (Kriterium 19.4) formuliert das noch ein wenig interaktiver, dass man in alle Bereiche hinein und auch wieder hinaus navigieren können sollte. Das WCAG 2 dehnt die Vermeidung von Sackgassen auch auf nicht barrierefreie Bereiche der Webseite aus. Solange man diesen nicht barrierefreien Bereich auch wieder verlassen kann oder in einer Hilfe klar gemacht wird, wie man diesen wieder verlassen kann, ist das in Ordnung. Der BITV-Test äußerst sich nicht explizit zur Sackgassen-Problematik.

Schlüssige Reihenfolge in der Tastaturnavigation

Wenn alle Funktionen und Inhalte ohne Sackgasse erreichbar sind, kann man sich quasi den Feinheiten widmen. Dass sie aber gar nicht wirklich so fein sind, erkennt man daran, dass das WCAG 2 (1.3.2) auf einer sinnvollen Abfolge besteht und das schon auf Level A. Freilich bezieht sich dieses Kriterium sehr allgemein auf eine sinnvolle Lesefolge, aber das betrifft ja besonders auch Tastaturnutzer, die eher verwirrt sind, wenn die Lesereihenfolge visuell gänzlich anders ist als via Tastatur. Oder etwa ein Screenreader-Nutzer eine ganz andere Lesefolge präsentiert bekommt und dadurch den inhaltlichen Zusammenhang verpasst. Das WCAG 2 wird in der Semantik hier noch konkreter und fordert zumindest einen sinnvollen Weg durch den Inhalt auf Level A. Einer der möglichen Techniken, um die Lesefolge für alle verständlich zu halten, ist, dass die DOM-Ordnung der visuellen Ordnung der Webseite entspricht (WCAG 2, C27). Wie immer ist das WCAG 2 eher kulant und schließt die Möglichkeit nicht aus, mit Hilfe eines Styleswitchers den Inhalt so zu linearisieren, dass etwa Tastaturnutzer eine lineare Lesefolge erhalten. Wie immer sollte das nur der letzte gangbare Weg sein.

Die BIENE (Kriterium 19.2) hält sich in Sachen Schlüssigkeit eher bedeckt und gibt die Entscheidung an den Entwickler und Nutzer ab, der selbst entscheiden soll, ob die Reihenfolge schlüssig und nachvollziehbar ist. Ein eher weiches Gusto-Kriterium. Der BITV-Test (Prüfschritt 9.4.1) fordert auch eine schlüssige und nachvollziehbare Reihenfolge, die der Anordnung – wohl der visuellen – auf dem Bildschirm folgt. Auch hier wieder eine Einschränkung im BITV-Test, die kleinere Abweichungen akzeptiert. Genauer ausgeführt werden diese jedoch nicht, es fehlen die Beispiele. Der Hinweis, dass aus einer visuellen Präsentation nicht immer eine zwingende Reihenfolge abzuleiten ist, ist richtig. Jedoch gibt es doch Standards in der Lesefolge, wie es wird von oben nach unten und von links nach rechts gelesen. 🙂 Ich finde, hier ist Beispielbedarf vorhanden.

Erkennbarkeit des aktuellen Fokus

So schön eine gute Erreichbarkeit per Tastatur ist, nutzt sie wenig, wenn man nicht erkennt, wo man sich aktuell überhaupt aufhält. Das WCAG 2 (2.4.3) fasst den Fokus etwas weiter, er muss erkennbar sein in der schlüssigen Abfolge. Was meint, es sollte kein Element den Fokus haben, das außerhalb der schlüssigen Abfolge liegt. Eine nachvollziehbare Begründung, weil diese Forderung ja schon eher in die Rubrik Sackgasse führt. Ich denke auch, dass mit diesem Kriterium, noch keine besondere Hervorhebung oder Kennzeichnung gemeint ist. Diese wird dann im WCAG 2 (2.4.7) erst auf Level AA gefordert: dass irgendein Indikator sichtbar und klar macht, wo man sich befindet und was aktuell fokussiert ist. Hier bietet das WCAG 2 durchaus an, dass man sich der browsereigenen Kennzeichnung von fokussierbaren Elementen wie Links und Formularen bedient. Leider ist der browsereigene Fokus – je nach farblicher Gestaltung der Webseite – oft schwer bis kaum zu erkennen. Patrick H. Lauke hat in seiner Präsentation Keyboard Accessibilty aktuell Beispiele geliefert, wie unterschiedlich Browser per Default Links darstellen. Und: welche Webseite greift noch auf den Default zurück. Insofern wird als weitere Technik empfohlen, auf CSS und a:focus zurückzugreifen und den Fokus entsprechend hervorzuheben.

Auch die BIENE (Kriterium 19.3) fordert, dass der Fokus für jede Position auf der Webseite deutlich sichtbar sein muss. Besonders gilt das für Formulare, die werden ja auch immer gerne vergessen. Ähnlich wie das WCAG 2 macht die BIENE eine gewisse Einschränkung auf die Standardeinstellung der Browser, geht aber nicht so weit wie das WCAG 2 auf die Defaults zu setzen. Nur wenn der Hintergrund weß oder sehr hell ist, könne man überhaupt den Fokus defaultmässig als ausreichend betrachten. Im Grunde eine ähnliche Argumentation wie das WCAG 2, jedoch noch etwas zu unpräzise.

Der BITV-Test (Prüfschritt 9.3.1) setzt hier schon einen härten Akzent. Testet man die Webseite mit Mausfokus, muss auch per Tastatur ein äquivalenter Fokus vorhanden sein. Diese Gleichsetzung von Maus- und Tastaturfokus ist durchaus ein schwierigeres Kriterium, weil es auch meint, dass man sich keinen ähnlichen oder alternativen Tastaturfokus erstellen sollte, sondern ein Äquivalent zur Mausaktion. Ich habe jetzt nicht sofort Beispiele an der Hand, aber im Einzelfall könnte das durchaus auch schwierig sein. Wenn bei Links keine Mausreaktion zu sehen ist, sollte sich der Tastaturfokus trotzdem vom Hintergrund erkennbar abheben. Auch weist der BITV-Test ausdrücklich auf die Unsitte hin, den Tastaturfokus mit Hilfe von onblur zu deaktivieren. Hier fehlt jedoch auch noch der Hinweis auf outline:none.

Tabindex und Accesskeys

Der Tabindex diente bis dato im klassischen Sinne nur dazu, die Lesereihenfolge der Webseite nachzujustieren oder bestimmte Elemente der Webseite wie Formulare bevorzugt an erster Stelle anzusteuern. Von diesem klassischen Verfahren wird durch die Bank abgeraten. Das WCAG 2 (2.4.3) macht zwar klar, dass man mit Hilfe des Tabindex die schlüssige Reihenfolge beeinflussen kann, aber sollte nur genutzt werden, wenn der Default der Lesefolge nicht mehr greift. Ähnlich argumentiert der BITV-Test. Wenn der Tabindex zu einer schlüssigen Reihenfolge beiträgt, ja – aber sonst nicht einsetzen. Bei der BIENE findet man dazu keine Entsprechung.

Der Einsatz von Accesskeys hat eine ähnlich negative Entwicklung durchgemacht wie der Tabindex. Heute setzt man sie sehr begrenzt ein. Nur noch die BIENE (Kriterium 20) spricht sie noch explizit an: Sie sollten dort einsetzt werden, wo es sinnvoll ist und wenn, dann muss der Einsatz konsistent und transparent sein. Im BITV-Test rangieren die Accesskeys mittlerweile unter der Rubrik Fragwürdige Bedingungen und sind im aktuellen Test nicht mehr anwählbar. Auch im WCAG 2 (2.4.1) werden sie nur noch für das gezielte Ansteuern von inhaltlichen Blöcken angeführt (advisory).

Strukturelle Navigation

Sowohl für Tastaturnutzer als auch Screenreader-Nutzer ist es wichtig, sich etwa mit Sprunglinks oder zusätzlichen Überschriften schnell durch die Webseite bewegen zu können und die inhaltliche Struktur damit sicher zu erfassen. Das WCAG 2 (2.4.1) empfiehlt daher, dass für Bereiche der Webseite, die sich überall wiederholen wie Navigationen, Links bereit gestellt werden, um diese Bereiche zu überspringen. Offen dabei bleibt, wie man das realisiert und wie sich das letztlich technisch nennt. Wir nennen das bis dato Sprunglinks, entweder einen oder mehrer Links am Anfang der Seite, um direkt zum Inhalt oder auch zu anderen Bereichen der Webseite zu springen. Interessanterweise wird immer noch empfohlen, auch vor jedem größeren Block einen Sprunglink zum Überspringen anzulegen. Letzteres – so dachte ich jedenfalls – wäre schon eher wieder im Abflauen. Ebenso wird die Technik empfohlen, vor jeden größeren Bereich der Webseite eine Überschrift zu setzen, dann kann mit Hilfe der Überschriftenhierarchie schnell durch die Bereiche navigiert werden.

Auch die BIENE (Kriterium 24.2) formuliert das Konzept der Sprunglinks eher allgemein als Mechanismus, der das unmittelbare Erreichen bestimmter Inhalts- und Navigationsbereiche möglich macht. Sie spricht dabei von verdeckter Sprungnavigation, die erst bei Tastaturnutzung sichtbar wird. Die Ziele sollen möglichst knapp formuliert sein etwa „zum Inhalt“. Interessant hier, dass die BIENE sehr genau auf die Formulierung der Sprunglinks und deren Sichtbarkeit eingeht, aber weniger die Bandbreite der Möglichkeiten aufgreift wie das WCAG 2. Auf den Einsatz von Überschriften als Sprungmöglichkeit geht die BIENE nicht ein.

Der BITV-Test (Prüfschritt 3.5.1) setzt ebenfalls auf eine Strukturelle Navigation, Überschriften sollen für alle Inhaltsbereiche der Webseite gesetzt werden, vor allem aber für Navigationen. Geprüft wird hauptsächlich, ob der Inhalt und die Navigationen mittels Überschriften erreicht werden können. Sind für die Navigationen keine Überschriften gesetzt, dann müssen die Menübereiche am Seitenanfang angeordnet sein oder sonst über Sprunglinks angesteuert werden können. Interessant hierbei ist, dass eine Abhängigkeit aufgebaut wird, sind keine Überschriften gesetzt, erst dann greifen Sprunglinks. Sowohl bei WCAG 2 und BIENE ist beides einsetz- und erwartbar. Innovativ im Neuentwurf greift der BITV-Test bereits auf den Einsatz von WAIARIA zurück und prüft, ob Landmarks wie navigation oder main einsetzt werden.

Fazit

Auch wenn es mitunter nur Nuancen sind, wie WCAG 2, BIENE oder BITV-Test die Tastaturbedienbarkeit ausloten, sind sie doch aufschlussreich und zeigen, dass viele Argumente zum einen historisch gewachsen und zum anderen noch unschlüssig ausgearbeitet sind. Schließlich warten wir ja alle auf die BITV 2 und erwarten, dass sie sich wieder an das WCAG 2 hält, aber auch dabei werden die Nuancen interessant werden. Sowohl BIENE als auch BITV-Test versuchen sich zu aktualisieren, was mal mehr mal weniger gut gelingt. Das Problem bei beiden ist, dass sie sich sehr stark an die aktuelle Browsersituation annähern müssen. Dadurch entstehen sehr schnell technische Unschärfen und Altlasten.

Einerseits fehlen die Beispiele – das macht das WCAG 2 in den technischen Dokumenten offener -, andererseits sind sie diskussionswürdig. Der Hinweis auf die schwierige Erreichbarkeit von Unterpunkten in Ausklappmenüs ist richtig, aber es wäre besser, darauf zu setzen, dass man es auch für Tastaturnutzer ausklapp- und erreichbar macht. Im Bereich der Sackgassen gibt es zu wenige Beispiele, man kann sich aus dem Entwickleralltag was zusammensuchen, aber besser wäre es, hier welche anzuführen. Schwierig sind auch immer so allgemeine Fragestellung wie schlüssige Lese- und Reihenfolgen zu bewerten, weil es dabei natürlich um mehr als Quellcodeabfolgen geht. Andererseits, wenn man sich schon auf so gewagtes Terrain begibt, sollte man da auch ausführlicher und kompetenter werden. Begriffe wie schlüssig, zwingend, nachvollziehbar sind eben dann schon interpretationswürdig.

Auch darf man die Frage stellen, warum man sich mit den Defaults des browserinternen Fokus aufhalten soll, wenn der bei 99% der Webseiten ohnehin nicht hinreichend erkennbar ist. Ich verstehe zwar den Ansatz des WCAG 2, dass die Fokussierung vor allem eine Aufgabe des User Agents sein müsste. Aber dann sollte man mehr in die Richtung argumentieren, dass der browserinterne Default auch per CSS unterstützt wird. Ich weiß, auch nicht wirklich eine gangbare Lösung, aber sie wäre konsistenter. 🙂

Letztlich fehlen die Innovationen. WAI-ARIA und die Semantik von HTML 5 sollte viel mehr herausgestellt werden, vor allem bei der BIENE. Der BITV-Test geht ja einen ersten Weg mit den Landmarks. Bei hinreichender Screenreader-Unterstützung könnte sich bald der Einsatz der klassischen strukturellen Navigation stark reduzieren, was auch zu wünschen ist. Die strukturelle Navigation ist ja immer ein Hilfskonstrukt gewesen und es wäre erfreulich, wenn es bald durch hinreichende Semantik und hilfreichere Interaktion ersetzt wird.

8 Antworten auf “Tastaturbedienbarkeit: ein Vergleich (WCAG 2, BIENE, BITV-Test)”

  1. Eine gelungene Übersicht. Viel Erfolg beim A-Tag und bei der BITV2 werden wir wohl einige Abweichungen erwarten dürfen.

  2. […] Dieser Eintrag wurde auf Twitter von Sylvia Egger. Sylvia Egger sagte: Tastaturbedienbarkeit: ein Vergleich (WCAG 2, BIENE, BITV-Test) by @sprungmarkers http://url.ie/2gw3 […]

  3. Hallo Jan,

    ja, bin wirklich gespannt, Du scheinst da ja schon mehr zu wissen in Sachen BTIV2 – schade, dass ich nicht auf BOA sein kann, ich nehme an, Du lüftest da sicherlich einige Fakten.

    Ja, ich freu mich auf den A-Tag in Wien und mein Vortrag hat schon eine inhaltliche Zuspitzung erfahren, die man aus diesem Artikel durchaus ableiten kann. 🙂

  4. zu: es wäre besser, darauf zu setzen, dass man Ausklappmenüs auch für Tastaturnutzer ausklapp- und erreichbar macht, ein übliches Gegenargument:

    Möglicherweise ist es komfortabler bei Navigation nur mit der Tastatur, wenn nur die Hauptmenüpunkte eines sehr umfangreichen Ausklappmenüs beim „Durchtabben“ erreichbar sind. Ein zusätzliches „statisches“ Submenü benötigt man sowieso, und man erspart Tastaturbenutzer/innen, alle Submenüpunkte immer wieder durchnavigieren zu müssen.

    Andererseits: Tastenkürzelerfahrene tun das vermutlich gar nicht, sondern springen hin, wo sie hinwollen.

    Auch zu bedenken: JAWS, als gängiger Screenreader, kennt auch eine Tastenkombination für mouse-over. Man kann also, muss aber ein Dropdownmenü nicht aufklappen.

    Es gibt kein immer gültiges Rezept. Generell: Guidelines, die keinerlei Interpretationsspiel mehr lassen, können technischer Weiterentwicklung nicht standhalten.

  5. Ja, stimmt. Kommt auf die Untiefen der Ausklappmenüs an. Ist mir bei den letzten Recherchen immer wieder aufgefallen, eher gruselig, wenn man alles abklappern muss. Dazu würde man aber nicht gezwungen sein, wenn es etwa Sprungmarken oder Landmark Roles gäbe.

    Ich denke, das ist alles eine Frage des Handlings. Einfach durchtabben und sehen, ob man gut und schnell durchkommt.

    Das war ja auch ein Argument des BITV-Tests, dass es reicht, wenn man die erste Ebene im ersten Durchlauf erreicht, weil ein Untermenü hat man im zweiten Durchlauf nach Auswahl sowieso. Ganz richtig. Ich stimme Dir und dem BTIV-Test da vollkommen zu. 🙂
    Ich vermeide aber eher Aufklappmenüs.

    Das Problem ist, soweit ich das in den letzten Tests bei Seiten gesehen habe, ist man einmal im Aufklappverfahren, kam man auch als Tastaturnutzer nicht mehr wirklich raus aus dem Menü. Wenn dann müsste man das quasi überspringen im Vorfeld.

    Ja, ich stimme Dir zu, dass es Interpretationsspielraum geben muss, den wird es ja ohnehin geben. Das war ja mein Ausgangspunkt im Artikel, dass er eben sehr unterschiedlich ist, auch letztlich der jeweilige Fokus, der vom je eigenen Schwerpunkt abhängt. Andererseits finde ich es schon wichtig, dass es klarerer Richtlinien gibt, als BIENE oder BITV-Test das oft zu schwammig versuchen.

    Wenn der Interpretationsspielraum zu gross ist, ist es auch wieder etwas haklig. Und ganz letztlich sind es ja öffentliche Kriterien, die auch einem bestimmten Zweck dienen. 🙂 Sei es eine BIENE zu erlagen oder einen BITV-Test zu bestehen. Und wenn es sich um einen klaren Zweck handelt, erwarte ich einfach auch klare Kriterien. Das ist nicht immer erreicht, wenn man sich diese genauer ansieht.

Schreibe einen Kommentar

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