Jede Seite hat einen Weg, den die meisten Besucher nie sehen: die Reihenfolge, in der die Tab-Taste von einem Bedienelement zum nächsten springt. Wer ohne Maus surft, für den ist dieser Weg die ganze Website.

Eine Tastaturfalle ist die Stelle, an der der Weg endet: Der Fokus geht in eine Komponente hinein und kommt nicht wieder heraus. Auf einem Screenshot sieht die Seite korrekt aus, aber alles hinter dieser Stelle ist unerreichbar.

Zwei Stellen, an denen es fast jede Website trifft

Die erste ist die Cookie-Leiste. Sie legt sich über die Seite und hält den Fokus, solange sie offen ist, was richtig ist. Das Problem kommt gleich danach: Der Besucher tabbt an „Akzeptieren“ und „Einstellungen“ vorbei, landet wieder auf „Akzeptieren“ und bleibt dort, weil die Leiste den Fokus behält und sich nur per Mausklick schließen lässt. Der Besucher erreicht weder die Seite, noch kann er das schließen, was sich davorgelegt hat.

Die zweite ist das Mega-Menü. Ein Kategorie-Flyout öffnet sich per Maus und bleibt in der Tab-Reihenfolge, auch nachdem es optisch verschwunden ist. Der Fokus wandert in ein unsichtbares Panel mit vierzig Links und taucht irgendwo wieder auf. Auf dem Bildschirm ist nicht zu sehen, wo der Fokus gerade steht.

Beides sind gewöhnliche Fehler in gewöhnlichem Code, und keiner erscheint in einem automatischen Bericht.

Warum eine Regelprüfung das nicht bemerkt

axe-core, die Engine hinter vielen automatischen Barrierefreiheits-Prüfungen, unserer eingeschlossen, liest die Seite. Sie durchläuft das Document Object Model, wendet rund hundert Regeln auf die gefundenen Elemente an und meldet die Elemente, die eine Regel verletzen. Sie sagt Ihnen, dass ein Bild keinen Alternativtext oder ein Formularfeld keine Beschriftung hat.

Was sie nicht tut, ist eine Taste zu drücken. Jede Regel ist eine Frage nach dem Zustand des Markups in einem Moment. Eine Tastaturfalle ist aber kein Zustand, sondern ein Verhalten über die Zeit: Tab drücken, schauen, wohin der Fokus ging, noch einmal Tab drücken und feststellen, dass er nirgendwohin geht. Kein Attribut im Markup sagt: „Diese Komponente gibt den Fokus nicht frei.“ Diese Weigerung steckt in einem Event-Handler, der erst bei einem echten Tastendruck läuft.

Es gibt einen zweiten Grund: Den Fokus einzusperren ist manchmal richtig. Ein modales Fenster soll den Fokus halten, solange es offen ist, eine Regel, die jede Fokusfalle meldet, läge also meistens falsch. Der Unterschied liegt darin, ob die Komponente den Fokus freigibt, wenn sie es soll, und das zeigt sich nur beim Ausprobieren.

Was das Inkluso-Audit aufzeichnet

Das kostenpflichtige Audit tut, was der Scanner nicht kann: Es drückt Tab. Ein echter Browser lädt die Seite und läuft sie Tastendruck für Tastendruck durch, bis zu drei Seiten, bei einem Shoptet-Shop vier, beginnend mit der Startseite.

Der Bericht enthält unter der Überschrift Aufgezeichnete Fokusreihenfolge eine Tabelle über die ersten vierzig Stationen jeder Seite: das fokussierte Element, sein Text oder seine Beschriftung und die Angabe, ob ein sichtbarer Fokusindikator gezeichnet wurde, nicht gezeichnet wurde oder sich nicht bestimmen ließ. Diese Tabelle ist oft nützlicher als die Befunde: Sie zeigt den Weg, den ein Tastaturnutzer durch Ihren Checkout nehmen muss.

Der Durchlauf meldet vier Dinge:

  • Fokus blieb an einem Element hängen, WCAG 2.1.2 Keine Tastaturfalle, EN 301 549 V3.2.1 Abschnitt 9.2.1.2
  • Fokus kreist, ohne den Großteil der Seite zu erreichen, WCAG 2.1.2 Keine Tastaturfalle, EN 301 549 Abschnitt 9.2.1.2
  • Fokus verschwand mitten auf der Seite, WCAG 2.4.3 Fokusreihenfolge, EN 301 549 Abschnitt 9.2.4.3
  • Kein sichtbarer Fokusindikator, WCAG 2.4.7 Fokus sichtbar, EN 301 549 Abschnitt 9.2.4.7

Neben jedem Befund steht die zugehörige Anforderung: der Abschnitt aus EN 301 549 und das nationale Gesetz Ihres Berichts. Das ist das BFSG in Deutschland, zákon č. 424/2023 Sb. in Tschechien, ustawa z 26 kwietnia 2024 r. in Polen, das BaFG in Österreich oder zákon č. 351/2022 Z. z. in der Slowakei. Es wird pro Bericht gewählt, nicht pro Sprache.

Der Drei-Minuten-Tastaturtest

Die beiden schlimmsten Fälle prüfen Sie sofort selbst.

  1. Klicken Sie in die Adressleiste des Browsers und drücken Sie Tab. Der Fokus sollte auf das erste Element der Seite springen.
  2. Drücken Sie weiter Tab und achten Sie darauf, ob immer sichtbar ist, wo der Fokus gerade liegt.
  3. Öffnen Sie Menü und Cookie-Leiste nur mit der Tastatur und schließen Sie sie mit Escape. Bleibt der Fokus hängen, haben Sie eine Falle.

Was wir nicht behaupten

Der Durchlauf ist ein heuristischer Befund aus einem automatisierten Durchgang. Er fließt weder in Punktzahl noch Note ein, er erscheint nie als bestätigter Verstoß, und jeder Befund bittet Sie, ihn vor einer Meldung als Mangel manuell zu bestätigen. Ein langsam ladendes Widget kann dasselbe Muster erzeugen wie ein echter Fehler. Der Durchlauf erfasst höchstens drei Seiten, bei einem Shoptet-Shop vier, in der Reihenfolge des Crawlers, findet also keine Falle auf einer Seite oder in einem Ablauf, den er nie erreicht hat, und ein sauberer Durchlauf ist kein Beweis, dass es keine gibt. Es ist kein vollständiges manuelles Audit, und wir verkaufen es nicht als eines. Es ist ein Protokoll davon, was passiert, wenn jemand auf Ihrer Website wirklich Tab drückt.

Sehen Sie, wo Ihre Website steht

Der kostenlose Scan prüft Ihre Website gegen WCAG 2.1 AA und zeigt erste Ergebnisse in wenigen Minuten.

Website kostenlos scannen Musterbericht herunterladen

Dieser Artikel dient der Information und stellt keine Rechtsberatung dar.