Die Schwachstellen von Tools zum Testen der Barrierefreiheit – Der Fokus

Im letzten Artikel wurde das heutige Thema schon angesprochen: die Verwendung der Tastatur auf Websites. Es hat sich herausgestellt, dass keines der Testtools erkannt hat, ob ein Bypass-Element vorhanden war. In diesem Artikel schauen wir uns an, was die Testtools zum Thema Fokus zu sagen haben.

Fokus

Der Fokus bezieht sich auf das Element auf einer Webseite, das gerade bereit ist, Eingaben vom Nutzer zu empfangen. Er ist der heilige Gral der Barrierefreiheit im Web.
Du glaubst das nicht? Stell dir vor, du hattest einen Unfall und deine Hände sind eingegipst. Du kannst nur einen Finger bewegen, um die Tastatur zu benutzen. Jetzt schau dir deine Website an.

Die Anforderung von WCAG 2.2 ist klar: Alle Funktionen müssen über die Tastatur verfügbar sein.

In dieser Ausgabe fragen wir: Können automatische Testtools Probleme bei der Tastaturbenutzung finden?

Wie in früheren Artikeln dieser Reihe verwenden wir kostenlose Browser-Add-ons für Tests: WAVE, IBM Accessibility Checker, Lighthouse und wir aktivieren den integrierten Joomla-Barrierefreiheitsprüfer jooa11y.

Um es kurz zu machen: Das Erkennen von Problemen bei der Tastaturbenutzung liegt ganz beim menschlichen Tester.

Die Größe des Touch-Ziels

In WCAG 2.2 muss die Größe des Touch-Ziels mindestens 24px betragen. https://www.w3.org/TR/WCAG22/#target-size-minimum

Nur ein Tool erkennt dieses Problem auf einer Testseite und gibt einen Hinweis darauf: Lighthouse (basierend auf AXE). Alle anderen Tools akzeptieren kleinere Touch-Ziele.

Der versteckte Fokusring

https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance kurz gesagt heißt es dort, dass interaktive Elemente ihr Aussehen ändern müssen, wenn sie den Fokus erhalten.

In diesem Joomla! Magazinartikel findest du Beispiele für die richtige Verwendung des Fokusrings auf einer Joomla-Website und die Warnung: Verwende niemals die CSS-Anweisung a:focus { outline:none }, die den Fokus ausblendet.

Heutzutage ist das selbstverständlich, aber vor zehn Jahren war es eine der am häufigsten verwendeten CSS-Regeln auf Websites. Warum? Viele Grafikdesigner dachten, dass der Fokusring ihre sorgfältig gestalteten Layouts ruiniert, und haben nicht gemerkt, wie sehr das die Barrierefreiheit beeinträchtigt hat. Aber eigentlich ist es ihre Aufgabe, den Fokusindikator in das Design zu integrieren.

Und die Testtools? Keines meiner Testtools erkennt einen versteckten Fokusring. Das ist überraschend, denn das sollte für diese Tools ein Kinderspiel sein.

Das Aussehen des Fokus

Bei Joomla wollen wir die WCAG 2.2 AA-Konformität erfüllen. Wir müssen also nicht die Empfehlungen der AAA-Konformität erfüllen, die besagen: Der Fokus muss mindestens 2 Pixel dick sein und seine Farbe muss einen Kontrast von mindestens 3,1 zum Hintergrund haben.

Trotzdem ist es eine gute Idee, den Fokus sichtbar zu machen. Die Cassiopeia-Vorlage nutzt Browserstandards, was Designern und Entwicklern erlaubt, das Aussehen des Fokus anzupassen. Und wir ermutigen jeden Entwickler, den Fokus zu einem Designelement der Website zu machen.

Sieh dir den Unterschied an: Auf der rechten Seite Cassiopeia in Firefox.

Der versteckte Fokusbereich

Eine Empfehlung der WCAG 2.2 besagt, dass das Element, das den Fokus hat, nicht komplett von einem anderen Element überdeckt werden darf. Zumindest ein Teil des Elements muss sichtbar sein.
Das kann passieren, wenn ein Mega-Menü aufklappt und einen großen Teil der Seite verdeckt oder wenn eine Sticky-Header einen Teil des Bildschirms verdeckt.

Es ist klar, dass Tools diese Probleme nicht erkennen können.

Die Fokusfalle

Wenn ein modales Fenster geöffnet wird, muss der Fokus auf das modale Fenster gesetzt werden.
Manchmal kann der Benutzer das Fenster nicht mit der Tastatur verlassen, sondern muss auf einen Bereich außerhalb des modalen Fensters klicken. Dann ist der Fokus gefangen.
Tools haben keine Möglichkeit, ein solches Problem zu erkennen.

Die Tab-Reihenfolge

WCAG verlangt eine logische Tab-Reihenfolge. Standardmäßig ist die Tab-Reihenfolge von einem Element zum nächsten, was einfach und verständlich ist. Manchmal entscheiden sich Entwickler bei Formularen dafür, die Tab-Reihenfolge zu ändern. Wenn zum Beispiel ein Eingabefeld für den akademischen Titel vor dem Namensfeld liegt, wird der Cursor beim Laden der Seite auf das Namensfeld gesetzt.
Das kann sinnvoll sein, aber ein Tool kann nicht entscheiden, was in einem bestimmten Kontext eine logische Reihenfolge ist.

Die gute Nachricht: Ein Tester muss nicht die ganze Seite durchgehen. Testtools können die Tabulatorreihenfolge einer Website anzeigen, was sehr hilfreich ist, und sie zeigen Warnungen an, wenn sie feststellen, dass der Tabindex vom Benutzer festgelegt wurde. 

Beispiel mit IBM Accessibility Checker.

Das WAVE Tool zeigt eine Warnung in der Übersicht an, sodass sie auf den ersten Blick sichtbar ist:

Verschiedene Tools haben unterschiedliche Visualisierungen. Du kannst auch nach speziellen Add-ons Ausschau halten, wie zum Beispiel taba11y, einem weiteren Tool, das die Tabulatorreihenfolge sichtbar macht.

Fazit

Das ist ein bisschen frustrierend, oder? Tatsächlich ist die komplette Tastaturbedienung ein blinder Fleck der Barrierefreiheitstest-Tools, nur die Visualisierung der Tabulatorreihenfolge hilft dem Tester.

Originalartikel im Joomla! Magazin: https://magazine.joomla.org/all-issues/september-2025/the-blind-spots-of-accessibility-testing-tools-the-focus