Beiträge von MaxHe

Hallo,

ich melde mich heute mit einer Auffälligkeit, die seitens eines unserer Webentwickler entdeckt wurde.

Vorab zur Information: aktuell stellt diese Auffälligkeit kein technisches Problem dar und "Es bedarf schon eines speziellen Ablaufs, damit das Problem auftritt", es wäre jedoch interessant zu wissen, ob es sich hierbei um einen Bug oder ein gewünschtes Verhalten handelt.

Im Anhang ist ein simpler Reproducer zu finden (inkl. HowTo), mit dem das Verhalten nachgestellt werden kann (bitte in .html wandeln).

Insgesamt geht es um eine zu übernehmende Wertänderung auf Basis eines Auswahlfeldes (nach meinem Verständnis, ich bin selbst leider kein Webentwickler). In chromiumbasierten Browsern tritt das gewünschte Verhalten auf (Wertänderung wird erkannt und korrekt dargestellt), in Firefox leider nicht (Wertänderung wird nicht erkannt, alter Wert wird weiterhin angezeigt).

Die zugehörigen, relevanten Fragen der Entwickler wären folgende:

• Hat Firefox einen Bug und implementiert die Spezifikation nicht korrekt? (1)
• Hat Chromium einen Bug und Firefox funktioniert korrekt entsprechend der Spezifikation? (2)
• Funktionieren sowohl Firefox und Chromium korrekt, weil die Spezifikation einfach einen gewissen Spielraum lässt? (3)

Entwicklungstechnischer Hintergrund:

"Die Fälle (2) und (3) bedeuten letztlich, dass sich das Verhalten von Chromium jederzeit ändern könnte. Der Problem ist aber sehr fies und schwer zu erkennen. In der Beispiel-HTML-Datei würde ein Anwender denken, dass er „Alte Auswahl“ ausgewählt hat, denn das sieht er. Drückt er nun auf einen Speichern-Button, dann würde er davon ausgehen, dass er „Alte Auswahl“ speichert. Moderne Web-Anwendungen machen im Hintergrund viel mit JavaScript und haben eine interne Darstellung der Daten, die auf der Oberfläche angezeigt werden (das ist das, was die Anzeige unter „Neuer Wert“ versucht zu simulieren – der interne Zustand der Anwendung). Wenn dann gespeichert wird, dann wird der interne Zustand in der Anwendung genommen, denn dieser interne Zustand und die UI sollten synchron zueinander sein. Oder anders: Die UI ist eine Repräsentation des internen Zustands. - Wegen des Problems sieht der Nutzer das eine und der interne Zustand enthält aber etwas ganz anderes.

Wird nicht geklärt, ob überhaupt und falls ja wo (Firefox VS Chromium) ein Bug vorliegt, dürfte man solche Vorbelegungen nicht mehr vornehmen, denn man könnte nicht ausschließen, dass ggf. irgendwann – z.B. mit dem Ausrollen einer neuen Chromium-Version – plötzlich dieses Problem in der Anwendung auftaucht und ab dann fehlerhafte Daten ins System kommen."

Sollten weiterführende Informationen benötigt werden, versuche ich gerne, diese zeitnah in Erfahrung zu bringen.

Die ESR-Versionen wurden mit einem bestehenden Policy-Set getestet, die "Consumer" Version auf einer Standardinstallation ohne Veränderung von Einstellungen, Flags etc. In allen Fällen ist das Verhalten identisch.

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.

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.

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?

Hallo und herzlichen Dank für die schnelle Hilfe sowie die Tipps!

Ich werde die notwendigen Anpassungen vornehmen und die Installation nach dem Signierungsprozess erneut ausprobieren.

Hallo liebe Community,

ich stehe vor der Aufgabe, eine Erweiterung im Unternehmensumfeld einzusetzen (WebAPI Manager). Vorab: die Verteilung erfolgt via Firefox Policy und ich habe leider keinerlei Erfahrung mit dem Signierungsprozess bzgl. Erweiterungen.

Die Installation der "offiziellen" Erweiterung funktioniert aus dem Firefox Addon-Store (via Link unter "zu installierende Erweiterungen" per Policy) problemlos. Leider kann ich diese offizielle Version als solche aber nur eingeschränkt verwenden, da bei dieser den Anwendern noch das Konfigurationsmenü der Erweiterung zur Verfügung steht. Dies ist seitens des internen Auftraggebers nicht gewünscht, die intern vorgegebene Konfiguration sollte - zumindest per GUI - nicht veränderbar sein.

Um dies zu realisieren, wurde ein Button der Erweiterung, welcher einen Link zum Konfigurationsmenü der Erweiterung darstellt, versteckt und dies innerhalb der Erweiterung angepasst ("hidden").

Dieses Vorgehen hat allerdings zur Folge, dass Firefox bei der Installation der modifizierten Erweiterung eine entsprechende Warnmeldung anzeigt: "Warnung: Dieses Add-on wurde nicht verifiziert. [...]". Dadurch ist die automatische Realisierung des Installationsvorhabens nur noch eingeschränkt möglich, da davon auszugehen ist, dass viele Anwender die Installation der Erweiterung anschließend via Klick ablehnen. ("xpinstall.signatures.required" und "xpinstall.whitelist.required" -> "false", 68.2.0esr 64-Bit).

Als einzige Möglichkeit, dieses Verhalten zu umgehen, erschließt sich für mich die Signierung der angepassten Erweiterung. Gleichzeitig kommen folgende Fragen für mich hinzu:

1. Darf ich eine modifizierte Version einer bereits Firefox Addon-Store erhältlichen Erweiterung überhaupt signieren lassen?

2. Würde diese Version dadurch im Firefox Addon-Store zur Verfügung stehen? Dies wäre nicht das Ziel der Aktion, da meinerseits für diese Version kein globaler Support übernommen werden kann. Die modifizierte Version soll nur im internen Umfeld des Unternehmens eingesetzt werden, um Vorgaben realisieren zu können.

Für Tipps zum weiteren Vorgehen oder ggfs. Verbesserungsvorschläge wäre ich sehr dankbar!