Menüps schliessen nicht mehr bei <CR> - nicht mehr barrierefrei

[Elektrolurch]

Hallo,

habe gestern, nach drei Wochen ein Update gemacht, dabei wurde auch fhemweb aktualisiert.
Nun tritt folgender Effekt auf:

(Da ich auf einen Screenreader angewiesen bin, ist die Bedienung für mich über Tastatur wichtig - Barrierefreiheit)

1. TAB ein Menü wird selektiert.
2. Mit Pfeil hoch/runter ein Eintrag ausgewählt.
3. Mit <CR>  wird / wurde das Menü geschlossen und der Menüwert an fhem übergeben. Das funktioniert nun nicht mehr. Bei <CR> bleibt das Menü nun offen und es passiert nichts.
Mit ESC kann man zwar das Menü wieder schliessen, dann wird aber kein Wert an fhem übergeben.
Mit TAB springt man zwar in das nächste auswählbare Element, aber es erfolgt wiederum keine Aktualisierung der Oberfläche auf Grund des ausgewählten Wertes.


Damit ist nun leider die Oberfläche nicht mehr barrierefrei.

Wäre schön, wenn das rückgängig gemacht werden könnte.

Gruß


Elektrolurch

[rudolfkoenig]

Ich habe bisher auf eine Tastaturbedienung kein Wert gelegt, wenn es funktioniert hat, dann ist es Zufall.
Ich habe gerade versucht was nur via Tastatur zu bedienen, und bei mir geht es, allerdings nicht sehr elegant, Schalten geht nur im Detail-Mode, und ESC reagiert gar nicht. Kannst Du bitte dein Problem genauer beschreiben, evtl. direkt mit fhem.cfg.demo als Beispiel? Ich verstehe z.Bsp. nicht, was du mit Menü meinst. Und welchen Browser verwendest Du?

[Elektrolurch]

Hallo,

also, verwenden tue ich den Firefox-Browser und den Browser auf meinem Nokia Symbian Handy.

Menüs:
Sind die, die entweder per
attr d setList Werte:1,2,3,4
oder per
attr myreadingsGroup commands {'Wert' => 'Wert:1,2,3,4'}

definiert wurden (Benutzen das gleiche fhem-Menü Widgets).

Funktionsweise Screenreader:

1. Ich rufe bspw. eine Webseite auf, sagen wir mal die von fhem.
Mit Pfeiltaste unten kann ich nun durch die Webseite navigieren und bekomme so jedes Element vorgelesen (statischer Text oder bedienbare Elemente).
Handelt es sich bspw. um einen Link, reicht es <CR> zu drücken, um den Link auszuführen.
Ist es ein fhem-Menü (s.o.), so wird durch
Leertaste das Menü geöffnet und mit den Pfeiltasten (hoch/runter) kann ich einen Menüeintrag  auswählen und mit <CR> bestätigen.
Mit ESC wird  der Auswahlvorgang im Menü abgebrochen und das Menü klappt wieder zu.
Wird die Leertaste auf dem Menü nicht gedrückt, so kann auch nichts ausgewählt werden und mit der Pfeiltaste unten wird das nächste Element auf der Webseite angesprungen und vorgelesen.
Die Auswahl des Menüeintrages per <CR> funktioniert nun nicht mehr, das Menü bleibt offen und fhem bekommt auch die Änderung nicht mit. (<CR> - Taste beendet nun nicht mehr den Fokus auf dem Objekt)


Diese Navigation hat m.K.n. nichts mit dem Screenreader selbst zu tun, sondern gehört zu Windows dazu (Bedienung über Tasten).

Ich kann mich so dunkel daran erinnern, dass es vor einigen Wochen in einem Beitrag um die Aktualisierung von slider und anderen Widgets ging und da einiges umgestellt wurde. Das könnte die Ursache dafür sein, dass nun im Widget "Menü" von fhem die <CR>-Taste nicht mehr zur Selektion des ausgewählten Menüeintrages aus der Liste der Menüpunkte führt.

Das gleiche gilt sinngemäß im übrigen auch für Textfeld, da wird der eingegebene Wert nur dann an fhem übertragen, wenn woanders geklickt wird oder mit TAB auf das nächste Eingabefeld gesprungen wird.

In den Java-Skripten für diese Widgets wird wohl <CR>-Taste nicht als "Fokus verlässt Objekt" ausgeführt, obwohl dieses meines Wissens Windos - Standard ist. (Leuchtet sofort ein, wenn z.B. ein normaler Button über Tastatur selektiert wird, dann löst <CR> die Aktion des Buttons auch aus).

Hoffe, dass ich jetzt das Problem ausreichend eingekreist habe. Wäre schön, wenn die Barrierefreiheit wieder hergestellt werden könnte.

Elektrolurch

[Elektrolurch]

Hallo,

habe jetzt mal mit älteren Version herumgespielt:

a) an der www/pgm2/fhemweb.js vom 1.12.2014 liegt es nicht.
b) Mit der Version $Id: 01_FHEMWEB.pm 6884 2014-11-04
funktioniert das Menü bezüglich der Bedienung mit Tasten noch einwandfrei. Mit der aktuellen Version vom 1.12.14 nicht mehr.

Das fhem - TextField geht wie bisher bei beiden Versionen nicht korrekt: Bei Eingabe von <CR> wird nichts an fhem übermittelt.

Vielleicht hilft das ja weiter, fhem wieder "tastenbedienbar" zu machen.

Werde wohl bis zur Behebung des Fehlers keine Updates mehr machen können.

Gruß

Elektrolurch

[rudolfkoenig]

Ich habe das mal naeher angeschaut. Ich gehe davon aus das du mit "Menü" das HTML <select> Element meinst, ich verwende dafuer lieber den Ausdruck Werteliste, da ich mit Menü was anderes assoziiere.

Die Aenderungen die dir Probleme verursachen stammen von Hoschiq (wie Du das auch erkannt hast). Ich habe folgende Tests durchgefuehrt:
- Firefox@Linux:Werteliste klappt bei hoch/runter NICHT aus, aber die sichtbaren Werte werden geaendert. CR sendet den  aktuell sichtbaren Wert zu FHEM.
- Chrome@OSX: Werteliste klappt bei hoch/runter aus, CR klappt die Liste zu, und sendet den selektierten Wert zu FHEM.
- Firefox@OSX: wie Firefox@Linux
- Safari@OSX: Links kann man nicht per tab auswaehlen(?? und damit auch nicht in FHEM-Raeume navigieren!), sonst wie Chrome@OSX.
- Chrome@WinXP: Werteliste klappt bei hoch/runter nicht aus, aber die sichtbaren Werte werden geaendert _UND_ sofort an FHEM gesendet. CR ist nicht mehr moeglich/noetig. Falls man in der Werteliste was nicht auswaehlen will, dann hat man Pech.
- Firefox@WinXP: wie Firefox@Linux.
Selbst mit longpoll=0 funktioniert es ueberall, mit dem Unterschied, dass man nach einer Aenderung von vorne anfaengt, weil die Seite ja neu geladen wurde. Das ist mit longpoll=1 nicht notwendig (dank Hoschiq).

=> Ich habe keinen Browser gefunden, um deine Probleme zu reproduzieren.

[Elektrolurch]

Hallo Rudi,

50/50.

Also:
Ist longpoll 1 gesetzt, so passiert folgendes (für mich nur schwer nachvollziehbar, wg. Screenreader):

1. Mit TAB komme ich an eine "Werteliste".
2. Mit Space öffnet sich die Liste.
3. Mit Pfeil hoch/runter kann ein anderer Wert ausgewählt werden.
4. MitCR schließt sich bei longpoll 0 die Liste und der Wert wird übernommen. Mit longpoll 1 schließt sich zwar die Liste bei CR auch, es wird aber nicht angesagt und ich kannn mit den Pfeiltasten nicht zum nächsten Element auf dem Screen navigieren, d.h. der eigentliche Selektionsvorgang ist noch nicht abgeschlossen. Erst wenn ich ESC drücke, kann ich dann mit den Pfeiltasten zum nächsten Element auf dem Screen springen.

Zusammengefaßt:
Der Unterschied im Verhalten besteht zwischen longpoll 1 und 0.
Bei longpoll 1 wird der 'Selektionsmode durch CR nicht beendet, welches aber der Fall sein sollte.

Und wie oben schon geschildert, für das TextField wird durch CR die eingegebenen Daten garnicht an fhem gesendet.

Der slider sollte eigentlich auch per Tastatur bedienbar sein:
1. Mit den Pfeiltasten auf den Slider gehen.
2. Space drücken.
3. Nun sollte man mit den Pfeiltasten links/rechts den Schieber verstellen können.
4. Mit CR wird die Selektion beendet.

Der fhem-slider geht aber nicht ab Punkt 2.

Browser: Aktueller Firefox auf Win 8.
Dass das oben geschilderte "Standardmechanismen sind, sieht man daran, dass mein altes Nokia-Telefon ohne Touchscreen die meisten Webseiten auch über Tastatur bedienen kann. Da funktioniert die Auswahl und Bedienung von grafischen Eleementen (Werteliste, Textfeld) genauso wie ich es oben beschrieben habe.

Die Änderung, die sich in der aktuellen 01-FHEMWEB.pm  befindet, hat das Selektionsverhalten bei longpoll 1  geändert. Die Selektion wird durch CR nicht bezüglich der Tastennavigation korrekt abgeschlossen.

Gruß

Elektrolurch

[rudolfkoenig]

Ich vermute dass der Screenreader Einfluss auf die Navigation hat, weil ich mit einem aktuellen Firefox@WinXP mit Pfeiltasten nicht navigieren kann (nur mit Tab/Shift-Tab), und Space oeffnet auch keine Liste fuer mich. Dafuer funktioniert bei mir <CR>, es sendet die Werte ans Backend. In deiner "funktionierenden" Version hat die Werteliste sich auch bei longpoll so verhalten wie ohne longpoll, deswegen empfindest Du das jetzt als Bug. Unter dem Strich weiss ich nicht wie ich das Problem beheben kann. Falls jemand konkrete Vorschlaege hat, dann hoere ich das gerne an. Solange schlage ich den Workaround "longpoll 0" vor.

Zu den anderen Bemerkungen:
- ein Textarea _kann_ auf CR nicht reagieren, da es mehrzeilige Eingaben ermoeglichen soll.
- die Slider funktionieren nicht, weil es selbstgebaut ist, und ich an Tastatursteuerung nicht gadacht habe. Slider ist mAn eher was fuer Tochscreens, bei der Tastatur wuerde ich ein Eingabefeld vorziehen. Auch weil ich nicht weiss, wie ich dem Screenreader sagen soll, dass er meine Zahlen vorlesen soll. Patches nehme ich aber gerne entgegen