Webseite ohne Maus nicht bedienbar: Fokus weg oder gefangen

Das Symptom

Die Maus liegt daneben, und plötzlich wird die Seite zum Rätsel. Der Tabulator springt irgendwohin, aber wohin, ist nicht zu sehen — der Umriss um das aktive Element fehlt. Ein paar Anschläge weiter ist der Fokus in einem eingebetteten Kartenfenster verschwunden und kommt nicht mehr heraus: Tabulator dreht sich im Kreis, Umschalt-Tabulator ebenso, Esc tut nichts. Der Rest der Seite liegt dahinter und ist ab jetzt unerreichbar. Nichts davon meldet einen Fehler. Es hört einfach auf zu funktionieren.

Die „Layer 8“-Wahrheit

Die Tastatur ist nicht die Notlösung für Leute ohne Maus. Sie ist die Schnittstelle, an der praktisch jede assistive Technik hängt. Das W3C schreibt das in seinem Verständnisdokument unverblümt hin: Zu den Tastaturemulatoren zählen Spracheingabe, Blas-Saug-Steuerungen, Bildschirmtastaturen, Abtastverfahren und eine Vielzahl alternativer Tastaturen. Wer die Tastaturbedienung kaputt macht, macht damit nicht ein Eingabegerät kaputt, sondern die gesamte Klasse. Erfolgskriterium 2.1.1 verlangt entsprechend, dass alle Funktionen über eine Tastaturschnittstelle bedienbar sind — ohne Zeitvorgaben für einzelne Anschläge, mit einer einzigen Ausnahme für echte Bahnabhängigkeit wie Freihandzeichnen. Gerade Linien und Grundformen zeichnen, Fenster in der Größe ändern und Objekte an eine Stelle ziehen — sofern der Weg dorthin keine Rolle spielt — fallen laut demselben Dokument ausdrücklich nicht darunter.

Was gern als Ausrede kommt, steht sogar dabei: Niemand verlangt den Verzicht auf die Maus. Die Anmerkung zu 2.1.1 sagt wörtlich, das Kriterium verbiete zusätzliche Eingabearten nicht und solle nicht davon abhalten. Es geht um „zusätzlich“, nicht um „stattdessen“. Und die naheliegende Ausflucht, das System könne den Zeiger doch per Ziffernblock steuern, hat das W3C ebenfalls vorweggenommen: Diese Funktion erfüllt das Kriterium nicht, weil sie kein Tastaturäquivalent zur Anwendung ist, sondern ein Mausäquivalent. Für das Programm sieht sie aus wie eine Maus. Das Problem bleibt also exakt bestehen, es dauert nur länger.

Der spektakulärere Fehler ist die Falle, und 2.1.2 beschreibt sie präzise: Wenn der Fokus mit der Tastatur in ein Bauteil hineinbewegt werden kann, muss er sich allein mit der Tastatur auch wieder herausbewegen lassen — und falls dafür mehr nötig ist als unveränderte Pfeiltasten, der Tabulator oder andere übliche Ausstiegswege, muss dem Benutzer der Weg mitgeteilt werden. Bemerkenswert daran ist, was das Kriterium nicht verbietet. Ein Dialogfenster, das den Fokus absichtlich festhält, ist nach dem Verständnisdokument ausdrücklich in Ordnung, solange der Benutzer weiß, wie er wieder herauskommt. Der Standard legt dabei bewusst nicht fest, was als übliche Ausstiegsmethode gilt — das hänge von Hardware, Browser und Betriebssystem ab —, nennt aber Esc als das, was in Umgebungen mit körperlicher Tastatur verbreitet erwartet wird. Der Fehler ist also nicht das Festhalten. Der Fehler ist das Verschweigen.

Und dann kommt der Punkt, der erklärt, warum dieses eine Kriterium so unverhältnismäßig hart wiegt. Die WCAG führen die Tastaturfalle in der Konformitätsanforderung zur Nichtbeeinträchtigung — zusammen mit der Lautstärkeregelung, der Blitzgrenze und dem Anhalten bewegter Inhalte. Diese vier gelten für sämtliche Inhalte einer Seite, auch für solche, auf die sich die Seite zur Erfüllung anderer Kriterien gar nicht stützt, weil ihr Versagen jede Nutzung der Seite stören kann. Übersetzt: Eine Falle in einem beliebigen eingebetteten Ausschnitt macht alles unerreichbar, was dahinter liegt. Der Werbebanner am Seitenende kann den Bezahlvorgang abschneiden, obwohl er mit ihm nichts zu tun hat.

Der Rest sind Kleinigkeiten mit großer Wirkung. Die eine Zeile, die den Fokusumriss abschaltet, weil er im Entwurf störte — danach springt der Fokus zwar, aber unsichtbar. Der von Hand vergebene positive Reihenfolgewert, der ein Element vor alle anderen zieht und die Reihenfolge des gesamten Dokuments verdreht. Die fest oben klebende Kopfleiste, die sich beim Tabben über genau das Element schiebt, das gerade den Fokus bekommen hat — seit WCAG 2.2 ein eigenes Kriterium, weil es so oft passiert. Und die fehlende Sprungmarke, die jeden Tastaturbenutzer auf jeder einzelnen Unterseite durch dieselben vierzig Navigationslinks schickt.

Das Beste an dieser ganzen Fehlerklasse: Sie ist die einzige in der Barrierefreiheit, die man ohne Werkzeug, ohne Schulung und ohne Budget vollständig selbst prüfen kann. Maus weglegen, den Weg abgehen, an dem für den Betrieb etwas hängt. Wenn du selbst nicht durchkommst, brauchst du über den Rest nicht mehr zu diskutieren.