Problem bzgl. Barrierefreiheit (Tabulator-Kreislauf)

MaxHe

Hallo Community,

im Firmenumfeld wurde heute eine Problematik bzgl. der Barrierefreiheit an mich herangetragen. Es handelt sich hierbei um ein Problem mit der Tastaturnavigation auf einer Seite (interne Website). Aktuell tritt das Phänomen in ESR 68.2 auf.

Vorab: ich weiß, dass es schwierig ist, hier direkten Support zu verlangen, da die Nachstellung des Verhaltens aufgrund eines fehlenden Beispielaufrufs meinerseits kaum möglich ist, aber vielleicht hatte jemand schon ein ähnliches Verhalten nachstellen können oder ähnliches.

Es handelt sich um eine Website, welche an der linken Seite eine Navigationsleiste hat, als Hauptcontent ein Formular mit verschiedenen Feldern.

Navigiert man nun per Tabulator-Taste durch die Website, erfolgt der Sprung in die Navigationsleiste. Nach dem letzten Punkt sollte der Fokus von der Navigationsleiste direkt in das erste Eingabefeld des Formulars springen. Stattdessen landet dieser aber an einem (vermeintlich) unsichtbaren Punkt, erst bei einem weiteren "Tab-Druck" landet der Fokus im Formular und die Eingabe kann erfolgen. Nach Analyse mittels "JAWS2019" landet der Fokus beim "Zwischensprung" an der h1-Überschrift über dem Formular.

Laut Aussage der Barrierefreiheitskollegen sollte dies nicht der Fall sein und ist damit ein abnahmeverhindernder Punkt.

Auffällig ist an dieser Stelle, dass das Verhalten in Chrome nicht auftritt, hier funktioniert der Tab-Kreislauf ohne Probleme und der Fokus landet im Formular.

Ist dieses Verhalten bekannt oder handelt es sich ggfs. einfach um einen internen Entwicklungsfehler meiner Kollegen, da Firefox hier etwas anders interpretiert als Chrome?

Sören Hentzschel

Hallo,

diese Frage lässt sich ohne reproduzierbaren Test-Case tatsächlich nicht gut beantworten. Könntest du einen solchen bereitstellen? Der kann ruhig auf das Kernproblem reduziert sein und muss keine reale Website sein.

MaxHe

Hallo,

ich bitte die lange Verzögerung zu entschuldigen. Mittlerweile haben weitere Tests stattgefunden, jedoch besteht das Phänomen noch weiterhin.

Gestestet wurde in Firefox ESR 68.8.0 & Firefox 74.0.1.

Im Anhang befindet sich eine ganz simple Website (bitte in .html) umbenennen, welkche das Verhalten verdeutlichen soll.

Es handelt sich nach wie vor um das Verhalten des Tab-Sprungs (Navigation per Tabulator-Taste). Zum Vergleich wurden noch Chrome sowie EdgeChromium herangezogen:

"Chrome:

1. Tab-Sprung aktiviert Link

2. Tab-Sprung aktiviert Eingabefeld Vorname (innerhalb des scrollbaren Bereich)

Firefox:

1. Tab-Sprung aktiviert Link

2. Tab-Sprung aktiviert scrollbaren Bereich

3. Tab-Sprung aktiviert Eingabefeld Vorname"

Laut der hauseigenen Abteilung, die sich um die Barrierefreiheitsprüfung kümmert, würde das Verhalten des Firefox eine Barriere darstellen, da ein sehbeeinträchtigter Anwender beim zweiten Tab-Sprung theoretisch erwarten würde, im Eingabefeld "Vorname" zu landen. Dadurch, dass der scrollbare Bereich in den Fokus gerät, weiß der Anwender nicht mehr, wo er sich auf der Website befindet. Hier wäre das Verhalten des Google Chrome / EdgeChromium der "Soll-Zustand", welches auch als barrierefrei angesehen wird.

Meine Frage wäre nun, ob dies einfach seitens unserer Web-Entwickler nicht elegant gelöst wurde, oder ob hier tatsächlich ein Fehlverhalten des Browsers vorliegt, bzw. ob dieses Verhalten ggfs. über einen Config-Eintrag behoben werden kann.

Sören Hentzschel

Tatsächlich liegt hier kein Fehlverhalten, sondern im Gegenteil gewünschtes Verhalten von Firefox vor. Ich habe gerade einen a11y-Experten von Mozilla dazu befragt, der erklärt hat, dass das overflow: scroll; ein Element in Firefox fokussierbar macht, so dass der Inhalt dann mit den Pfeiltasten gescrollt werden kann. Es handelt sich dabei also, entgegen der Einschätzung in eurer Abteilung, um keine Barriere, sondern ganz im Gegenteil um ein Feature, um beeinträchtigten Menschen zu helfen.

In Chromium/Chrome ist es notwendig, tabindex auf 0 zu setzen, damit sich Chrome wie Firefox verhält. Was merkwürdig ist, da es sowohl ein gelöstes Ticket im Bugtracker von Chromium als auch eine Intent to Ship-Ankündigung gab, in der davon die Rede war, dass Chromium das Verhalten von Firefox adaptiert, sprich der tabindex sollte in dem Fall, wie bei Firefox, implizit 0 statt -1 sein. Aber ganz offensichtlich stimmt das im Falle von Chromium/Chrome nicht mehr.

Im Umgekehrschluss heißt das jedenfalls, du könntest den tabindex auf -1 setzen, um das a11y-Feature auch in Firefox abzuschalten.

MaxHe

Herzlichen Dank für die Analyse des Verhaltens und die Befragung des Experten zu diesem Thema, das hilft mir (uns) auf jeden Fall weiter!

Scheinbar liegt hier dann zusätzlich auch eine Fehlinterpretation einzelner Barrierefreiheitsfunktionen vor. In Verbindung mit dem Tool "Jaws" wurde das Verhalten kritisch betrachtet.

Ich habe die Rückmeldung sowie den Tipp "tabindex auf -1 zu setzen" an die Kollegen weiter geleitet. Dies erzeugte auch den gewünschten Effekt, allerdings kam es hierdurch wohl zu unerwünschten Nebeneffekten:

"So hatten wir ein custom-Select-Element, dass sich dann schloss, wenn man innerhalb des Select-Elements scrollen wollte." (vermutlich nicht auf der von mir gelieferten Demo-Seite, sondern in deren Testseite, auf welcher das Verhalten auffiel). Die Lösung wird daher als "nicht befriedigend" bewertet...

So langsam vermute ich, dass der Ansatz unserer Entwickler in eine falsche Richtung geht. Wir haben einige selbst entwickelte Webanwendungen im Einsatz, aber ich kann mich bislang an keine erinnern, welche vor ähnlichen Problemen stand, bzw. welche das nicht irgendwie lösen konnte (zumal ich von der beschriebenen Problematik intern zum ersten Mal höre).

Abschließende Frage: Gibt es spontan noch einen weiteren/alternativen Lösungsansatz? Falls nein, ist das absolut kein Problem, ich möchte auch nicht zu tief in die Thematik eingehen. Gegebenenfalls müssen unsere Entwickler über einen alternativen Ansatz zum Ziel kommen und eine andere Lösung finden.