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) DasWCAG 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. DieBIENE (Kriterium 19) spricht hierbei eher von der Tastatur her, dass jegliche Funktion über die alleinige Verwendung der Tastatur erreichbar sein muss. Auch derBITV-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. DieWCAG 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). DieBIENE (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 dasWCAG 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. DasWCAG 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.

DieBIENE (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. DerBITV-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. DasWCAG 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 imWCAG 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 dieBIENE (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.

DerBITV-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. DasWCAG 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 dieBIENE (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. ImBITV-Test rangieren die Accesskeys mittlerweile unter der Rubrik Fragwürdige Bedingungen und sind im aktuellen Test nicht mehr anwählbar. Auch imWCAG 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. DasWCAG 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 dieBIENE (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.

DerBITV-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 WAI-ARIA 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.

Sylvia Egger - 20.09.09 - 9:39 | Barrierefreiheit | BIENE, BIK, BITV-Test, kompakt, Screenreader, Tastatur, Tastaturnavigation, Überschrift, WCAG2 | Kommentar schreiben - Trackback - Kommentare verfolgen -