Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

5.5.1 Möglichkeiten der Bedienung - mit operable parts ist nicht nur Hardware und Zubehör gemeint #135

Open
stefanFarnetani opened this issue Mar 28, 2024 · 12 comments

Comments

@stefanFarnetani
Copy link

Soweit ich das verstanden habe, können "Operable part" auch Software sein.
Bietet also die App eine Möglichkeit, um mit Drehen des Handgelenks etwas zu bewerkstelligen, dann fällt das auch unter diesem Prüfschritt.

Sie Diskussion bzw. Klärung in diesem Thread:
https://labs.etsi.org/rep/HF/en301549/-/issues/70

@detlevhfischer
Copy link
Contributor

@stefanFarnetani Danke für den Hinweis, da hast Du wohl recht. Kommt halt zurzeit bei Apps kaum vor, aber mir dem Aufkommen von AR-Anwendungen u. Interaktionsmöglichkeiten zukünftig sicher relevant.

@stefanFarnetani
Copy link
Author

@detlevhfischer wenn ich es richtig verstehe, sind damit auch digitale Bedienelemente gemeint. Ich habe es so verstanden, dass Bedienkonzepte wie z.B. die pinch-zoom-Geeste oder an die geste des rotos auf iOS darunter fallen würden.
Für diese beidne GEsten gibt es glaube ich alternative vom betreibsystem selbst.
Würde eine App soetwas ähnliches selbst implementieren, würde das darunter fallen.

@johannesFischer84
Copy link
Contributor

Bietet also die App eine Möglichkeit, um mit Drehen des Handgelenks etwas zu bewerkstelligen, dann fällt das auch unter diesem Prüfschritt.

Sehe ich auch so. Aus meiner Sicht wird das zudem in WCAG 2.5.1 (Alternativen für komplexe Gesten) bewertet. Gibt es einen Fehler, würde dieser dann also außerdem in WCAG 2.5.1 bemängelt.

@stefanFarnetani
Copy link
Author

@johannesFischer84 Danke für die Erinnerung. Die Verknüpfung hatte ich im Kopf gerade nicht mehr präsent.
Das wäre ja ein Argument, den Text so zu belassen.
Ich finde, dass die Überschneidungen in der EN die Arbeit unnötig komplizieren.
Und könnte mir vorstellen diesen Aspekt in diesem Prüfschritt mit Absicht wegzulassen, um es übersichtlicher zu gestalten.
Vielleicht war das sogar die Intension von der Prüfschrittautor*in. Wenn dem so war, dann entschuldigt die Diskussion und wir können den Thread schließen.

@johannesFischer84
Copy link
Contributor

Ich finde, dass die Überschneidungen in der EN die Arbeit unnötig komplizieren.
Und könnte mir vorstellen diesen Aspekt in diesem Prüfschritt mit Absicht wegzulassen, um es übersichtlicher zu gestalten.

Ein Hinweis in 5.5.1 ist zumindest sinnvoll, dass man auch Bedienelemente von grafischen Nutzeroberflächen bewerten muss und dass Fehler evtl. sowohl in 5.5.1 der EN als auch in 2.5.1 der WCAG als Fehler zu werten sind.

Verkompliziert wird es, aber das haben die EN-Kriterien teilweise eben so an sich, dass man da mal Dinge aus den WCAG nochmal als Fehler anmerken muss. Um die Dopplungen zu vermeiden, müssten wohl die Autoren der EN ein paar Dinge verändern ...

@detlevhfischer
Copy link
Contributor

detlevhfischer commented Apr 2, 2024

@stefanFarnetani schrieb:

Ich habe es so verstanden, dass Bedienkonzepte wie z.B. die pinch-zoom-Geeste oder an die geste des rotos auf iOS darunter fallen würden.

Ob man die Pinch-Geste als Zusammendrücken im Sinne von 5.5.1 bewerten kann, ist grenzwertig - es ist eher eine komplexe Geste im Sinne von 2.5.1 als ein eigentliches Drücken oder Greifen. in 5.5.1 Die iOS-Rotorgeste wir i.d.R. durch gegenläufige Fingerbewegung ohne Drehen des Handgelenks bewerkstelligt und betrifft nicht den Autor, sondern den UA bzw. das OS.
Klar ist aber, dass Greifen, Drücken, Drehen in den Bereich der Software-Controls fallen und damit hier geprüft werden würde, wenn von einer App AR- oder VR-Gesten impementiert würden (etwa über Sensoren in einem Handschuh oder eine andere Erfassung einer Handwegegung im Raum über Geräte-Sensoren oder Kamera).

Die auf der Displayfläche ausgeführten Gesten scheinen hinreichend in 9.2.5.1 / 11.2.5.1 erfasst, und Bewegungen des Geräts zur Aktivierung in 9.2.5.4 / 11.2.5.4. Die Bedienelemente von grafischen Nutzeroberflächen, welche physische Metaphern wie Umschalter oder Schieberegler aufgreifen, sind oft ja auch durch einfaches Antippen, Tippen auf die gewünschte Thumb-Position o.ä. zu betätigen, verlangen also oft nicht einmal ein Äquivalent der physischen Interaktion mit den physischen Bedienelementen, denen sie gleichen. Ob es auch einfach geht, wäre dann wenn überhaupt hier als erstes zu prüfen.

Die physischen Bedienelemente am Gerät könnten ggf. eingesetzt werden, in Frage kommen wohl aber nur die Laut/Leise-Tasten - so wie das bei Android /Talkback zu Verschieben des Cursors unterstützt ist (bzw. war). Aber in diesem Fall fiele es unter die Bedienung des Hilfsmittels Talkback, für die der Autor nicht mehr zuständig wäre. Ich kenne keine App, die sonst explizit die physischen Tasten des Geräts nutzt (und auch dann wäre es in der Regel kein Greifen, Zusammendrücken oder Drehen, sondern eher simples Drücken - das mobile Gerät müsste allerdings fixiert sein dafür).

@johannesFischer84 Ein Hinweis in 5.5.1 ist möglich, scheint mir zurzeit nicht zwingend notwendig. Es wird auch nicht einfach zu ermitteln sein, ob etwa die Pinch-Geste einer Karte in einer App von den Autoren der App spezifisch umgesetzt wurde oder Funktionalität nutzt, die UA / OS bieten. Und man müsste dann hier UND in 11.2.5.1 prüfen, ob Alternativen zur komplexen Geste vorhanden sind.

@johannesFischer84
Copy link
Contributor

@detlevhfischer

Ob man die Pinch-Geste als Zusammendrücken im Sinne von 5.5.1 bewerten kann, ist grenzwertig - es ist eher eine komplexe Geste im Sinne von 2.5.1 als ein eigentliches Drücken oder Greifen.

Die Pinch-Geste ist meines Wissens ein Zusammenziehen oder Auseinanderziehen von zwei Fingern für Verkleinerung/Vergrößerung. Damit ist es eine Mehrpunkt-Geste und ein Fehler nach WCAG 2.5.1, sofern die Geste entwicklungsseitig implementiert wurde und keine Alternative vorhanden ist. Im normativen Text von EN 5.5.1 ist direkt das Wort "pinching" als Bedienmethode genannt, für die es eine Alternative braucht.
Ich verstehe nicht, warum du einen Fehler nur bei WCAG 2.5.1 siehst, aber nicht bei EN 5.5.1.

Die Bedienelemente von grafischen Nutzeroberflächen, welche physische Metaphern wie Umschalter oder Schieberegler aufgreifen, sind oft ja auch durch einfaches Antippen, Tippen auf die gewünschte Thumb-Position o.ä. zu betätigen, verlangen also oft nicht einmal ein Äquivalent der physischen Interaktion mit den physischen Bedienelementen, denen sie gleichen. Ob es auch einfach geht, wäre dann wenn überhaupt hier als erstes zu prüfen.

Ich stimme zu. Wenn es nur einfach geht, ist keine komplexe Geste nötig und beide Prüfkriterien sind nicht anwendbar. Wenn es zwar einfach geht, aber auch eine komplexe Geste funktioniert, ist die einfache Alternative vorhanden und beide Prüfkriterien sind konform.

@johannesFischer84 Ein Hinweis in 5.5.1 ist möglich, scheint mir zurzeit nicht zwingend notwendig. Es wird auch nicht einfach zu ermitteln sein, ob etwa die Pinch-Geste einer Karte in einer App von den Autoren der App spezifisch umgesetzt wurde oder Funktionalität nutzt, die UA / OS bieten.

Ok, ihr entscheidet, was ihr in die Anleitung einfügt. Es stimmt aber, einfach ermittelbar ist das nicht, was entwicklerseitig implementiert wurde und wo nur an User-Agenten bzw. das Betriebssystem delegiert wird.

Und man müsste dann hier UND in 11.2.5.1 prüfen, ob Alternativen zur komplexen Geste vorhanden sind.

Dass man es in beiden Kriterien prüfen bzw. ggf. als Fehler anmerken muss, da stimme ich zu. Bzw. ist das meine Interpretation der normativen Texte in beiden Kriterien.

@detlevhfischer
Copy link
Contributor

Ich verstehe nicht, warum du einen Fehler nur bei WCAG 2.5.1 siehst, aber nicht bei EN 5.5.1.

Die Bewegungen sind natürlich sehr ähnlich - nur dass die Geste auf dem Display ein sehr viel geringen Kraftaufwand braucht als etwa das Greifen meines physischen Schalters. Ich finde es aber auch nachvollziehbar, das bei beiden Prüfkriterien bewerten.

@johannesFischer84
Copy link
Contributor

nur dass die Geste auf dem Display ein sehr viel geringen Kraftaufwand braucht als etwa das Greifen meines physischen Schalters

Ich glaube nicht, dass in 5.5.1 der EN der Kraftaufwand eine Rolle spielt. Davon steht in der Anforderung nichts. Der Kraftaufwand wird im EN-Kriterium 8.4.2.2 (Force of operation of mechanical parts) erwähnt, wobei das kein Kriterium ist, welches für Webseiten oder Apps nach EU-Vorgaben relevant wäre.

@detlevhfischer
Copy link
Contributor

detlevhfischer commented Aug 28, 2024

@stefanFarnetani @johannesFischer84

Stefan schrieb eingangs:

wenn ich es richtig verstehe, sind damit auch digitale Bedienelemente gemeint. Ich habe es so verstanden, dass Bedienkonzepte wie z.B. die pinch-zoom-Geeste oder an die geste des rotos auf iOS darunter fallen würden.

Ich habe noch mal in die EN in den Bereich 5.5 Operable parts geschaut. Ich denke, dass pinching im Kontext von 5.5.1 "operable parts that require grasping, pinching or twisting" ziemlich klar auf die physische Manipulation dreidimensionaler, taktil erfassbarer Bedienelemente abzielt.

Bei 5.5.2 sieht es anders aus - hier wäre ein typisches FAIL virtuelle, nicht fühlbare Bedienelemente auf dem Touchscreen eines Zubehörs, das ja i.d.R. hier keine Sprachausgabe hat. Hier stand vorher (als ich vorhin den Kommentar schrieb) noch was anderes, aber jetzt versteh ich das so.

Um das endgültig zu klären, werde ich bei ETSI noch mal ein Issue dazu anlegen.

@detlevhfischer
Copy link
Contributor

Hier das ETSI issue zu 5.5.1 Means of operation:
https://labs.etsi.org/rep/HF/en301549/-/issues/295

@detlevhfischer
Copy link
Contributor

Das Issue ist immer noch ohne Antwort, deshalb warte ich noch mit Aktualisierungen der Anforderung 5.5.1 (ohnehin sind ja Softwareseitige Pinch_Gesten bei 11.2.5.1 erfasst).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants