Prüfschritt 9.2.5.1 Alternativen für komplexe Zeiger-Gesten

[anatom5]

Auf der Seite der Prüfschrittbeschreibung https://ergebnis.bitvtest.de/pruefschritt/bitv-20-web/bitv-20-web-9-2-5-1-alternativen-fuer-komplexe-zeiger-gesten findet sich der Text "Lassen sich Slider oder andere Inhaltselemente durch Wischgesten bewegen? Werden durch Wischgesten vom Rand her Menüs oder andere Webinhalte eingeblendet?". Dafür wird eine Alternative gefordert. Ich halte das für falsch. Das ist nicht mit komplexer Zeigergeste gemeint. Auf der Seite https://www.w3.org/WAI/WCAG21/Understanding/pointer-gestures.html wird eigentlich ausführlich beschrieben, was damit gemeint ist. Allerdings finden sich auch dort unter https://www.w3.org/WAI/WCAG21/Understanding/pointer-gestures.html#examples viele Beispiele, die ich nicht zu komplexen Gesten zählen würde. Ich gehe mal davon aus, davon aus, dass wir alle einig sind, dass eine vertikale Einfinger-Wischgeste zum Scrollen einer Seite keine komplexe Geste darstellt. Mit welcher Begründung sollte dann eine simple horizontale Einfinger-Wischgeste zum "Blättern" in Content-Slidern oder Image-Slidern eine Alternative notwendig sein. Mir scheint, hier wurde der Pfad der Intention diese Prüfschritts bei den Beispielen in den WCAG21 Understanding-Docs fälschlicherweise verlassen und im BITV-Test übernommen. Die Erläuterungen und grafischen Beispiele auf der Seite sprechen auch eine andere Sprache. Falls ich mich hier irre, wäre ich dankbar für eine gut Erklärung, die man auch Kunden vermitteln kann. Vielleicht übersehe ich etwas oder ein bestimmte Behinderungsart in Kombination mit einer bestimmten Hilfstechnologie? Bin gespannt auf eure Meinung.

Gerade gesehen, es gibt von Detlev dazu schon ein W3C/WCAG Issue: https://github.com/w3c/wcag/pull/3148. Noch offen. Wenn überhaupt würde ich es auch hier sehen: https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements. Siehe auch: https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements#examples

[MarcHaunschild]

Schließe mich Jörg hier an. Es geht doch eher um einen konkreten Pfad womöglich mit festgelegten Start- und Zielpunkten, nicht darum irgendwo mit einer wischbewegung beginnen und irgendwo enden zu können, ohne dabei streng horizontal oder vertikal sein zu müssen (mehr so in etwa eher horizontal oder vertikal - die Betriebssysteme sind da sehr großzügig). Sonst müsste man das ja bei jeder Seite abstrafen, die nicht in den viewport passt und dadurch horizontales scrollen notwendig macht.

[ThomKoeh]

Habe auch immer Probleme mit der Erklärung, warum und horizontale Wischgesten eine einfache Alternative brauchen und vertikales Scrollen nicht.

[detlevhfischer]

@ThomKoeh @anatom5

Ich gehe mal davon aus, davon aus, dass wir alle einig sind, dass eine vertikale Einfinger-Wischgeste zum Scrollen einer Seite keine komplexe Geste darstellt.

Vertikales Scrollen einer Seite oder Ansicht ist eine Geste, die vom Betriebssystem unterstützt wird. Die Anforderung erfasst nur Gesten, die von Web-Autor:innen programmatisch umgesetzt werden.

@anatom5 Die Unterscheidung zwischen "echter" Zeigergeste und Ziehbewegungen ist schwierig. da auf Elementen. de sich z.B. horizontal verschieben lassen, bei manchen User Agents (Touch) eine vertikale Bewegung vom Betriebssystem "verbraucht" wird, also tatsächlich eine horizontal gerichtete Bewegung zum Aktivieren notwendig ist, wärend es in anderen User Agents keine bestimmte Richtung gibt (also die Bewegung nicht durch einen bestimmten zweiten Punkt laufen muss) und damit die Eingabe nicht unter Zeigergesten fallen würde. Ich habe deshhalb in den AGWG Issues eine andere Definition von Pointer Gesture angeregt: https://github.com/w3c/wcag/issues/3344#issuecomment-1686471087

Nach dem Verständnis der Working Group fallen überigens Slider, die über Bereiche mit CSS overflow umgesetzt sind, ebenfalls nicht unter Zeigergesten, da die horizontale Bewegung auch hier vom Betriebssystem unterstützt wird und nicht über Autor-Scripting umgesetzt wird.

Da nun mit WCAG 2.2 sowohl für Dragging Movements als auch Pointer Gestures eine einfache Pointer-Alternative gefordert wird, ist es in praktischer Sicht, was den Mangel betrifft, zukünftig nicht mehr so wichtig (auch wenn Hinweise / Bewertungen natürlich in den passenden Prüfschritten auftauchen sollten).

[sweckenmann]

@anatom5 Vielleicht hilft auch die Erklärung im Blogartikel von Tetralogical:

A person moves slides into view by swiping left or right on the screen. The angle or direction of the swipe gesture has no impact on whether the carousel moves. Even if the gesture is performed at a slight angle, the carousel will still operate in the same way as if the person had swiped straight across the screen. Therefore, a single pointer-based, non-path-based alternative is not required to meet 2.5.1 Pointer Gestures (Level A).

Note, however, the lack of an alternative may cause the carousel to fail 2.5.7 Dragging Movements (Level AA) if the carousel also relies on dragging movements to operate. [...] The following screenshot shows the same carousel. This time, however, the angle of the swipe gesture must be perfectly straight from left-to-right or right-to-left. If there is deviation, for example a person swipes at a slight angle, the carousel does not move as expected. Therefore, in this case, a single pointer-based, non-path-based, alternative is required. [...] That said, it is good practice to provide single-pointer, non-path-based alternatives in all cases, even if the gesture's angle, direction, or accuracy has no impact on the success of the gesture. Doing so benefits everyone, particularly people who may find gestures difficult to perform, even when the gestures are not path-based. Additionally, remember that alternatives are required if operating the component requires some form of dragging movement.

Im Understanding Document 2.5.7 Dragging Movements wird explizit auf die overflow-Ausnahme hingewiesen:

This criterion does not apply to scrolling enabled by the user-agent. Scrolling a page is not in scope, nor is using a technique such as CSS overflow to make a section of content scrollable.

[anatom5]

@sweckenmann, @detlevhfischer: Danke für die ausführliche Erläuterung, aber wer soll das noch verstehen? Mir erscheint das hypothetisch und nicht an tatsächlichen Problemen orientiert. Vielleicht liest ja hier auch die Pfennigparade mit und prüft das Szenario mal in ihrem Test.Labor Barrierefreiheit mit echten Menschen mit unterschiedlichen motorischen Einschränkungen. Und vielleicht können wir die Prüfbeschreibung konkretisieren. Ich lese sie nämlich derzeit so, dass ein Caroussel ohne Alternative immer durchfällt. Wir sollten doch prüfen, wie fehlertolerant dann so ein einfacher Slider ist. Vorschlag für eine Ergänzung zur Testbeschreibung: "Wenn eine Geste nicht exakt an einem bestimmten Punkt beginnen und enden muss und mit einem Finger ohne einem bestimmten Pfad folgen zu müssen ausgeführt werden kann und wenn die Bewegung nicht exakt horizontal ausgeführt werden muss, dann gilt die Wischgeste nicht als komplex".

[sweckenmann]

@anatom5 Praktisch merkst du es am Smartphone, wenn du beim Wischen im Karussell mit dem Finger einen Haken nach unten schlägst (also leicht nach unten bevor du nach links gehst und nicht nur horizontal wischst) und damit versehentlich die Seite scrollst.

Prüfschritt-Beschreibung können wir uns natürlich nochmal vornehmen und verbessern, ja.

[detlevhfischer]

@anatom5 Hallo Jörg

"Wenn eine Geste nicht exakt an einem bestimmten Punkt beginnen und enden muss und mit einem Finger ohne einem bestimmten Pfad folgen zu müssen ausgeführt werden kann und wenn die Bewegung nicht exakt horizontal ausgeführt werden muss, dann gilt die Wischgeste nicht als komplex".

Dein Vorschlag ist so leider zu spezifisch und nicht passend.

• Zeigergesten sind nicht notwendig horizontal (auch wenn es in der Praxis die meisten sind)
• "bestimmter Pfad" ist recht vage, entscheidend ist die initiale Richtung (intermediate point), aber ich halte die Definition auch für schwer verständlich und habe, wie erwähnt, eine Änderung angeregt.
• Wischgesten müssen auch oft nicht exakt an einem Punkt beginnen - siehe etwa das Verhalten in Mail-Anwendungen, wo eine Wischgeste erst Optionen anzeigt oder auch, voll durchgezogen, eine Mail löscht.

Wir bleiben dran an dem Thema. Content-Slider, die mit CSS overflow umgesetzt sind, würden (wenn ich es richtig verstanden habe) übrigens keine single pointer Alternative brauchen, da hier Gesten der zugrundeliegenden Plattform reichen.

[detlevhfischer]

• Siehe Aufnahme einer Ausnahme für Bereich mit CSS overflow in https://github.com/BIK-BITV/BIK-Web-Test/pull/414
• Siehe auch Ergänzung zur Anwendbarkeit von 9.2.5.7 Ziehbewegungen: Anwendbar, sobald Ziehbewegungen implementiert sind https://github.com/BIK-BITV/BIK-Web-Test/pull/407