Tweaks/additions to Understanding Pointer Gestures #910
Conversation
While it's implied/is a subset of the existing first gesture (where points 1, 2 and 3 have to be in a straight line), having an explicit example here that calls these types of gestures out will make it more immediately obvious that these are also covered. As this is the simplest subset of the existing first figure, this was also made the first example (so the complexity builds up from the 1-to-2 straight line example, to the 1-2-3 example). Some added `<strong>` and `<em>` added to make it more immediately clear when something IS or ISN'T path-based/free-form.
talking about scope/scoped SC is rather obscure/technical language (that word is used only one more time, in the WCAG2ICT document, but nowhere else in WCAG). this makes it a bit more comprehensible to laypeople.
|
ping @alastc (while i'm going through my PR left hanging open for ages) |
|
Ping @alastc |
|
ping @alastc |
|
thanks @detlevhfischer ... have to admit, as this was such a long time ago, I can't even remember the exact context of this PR now, but I think it related to discussions we had at the time |
|
Sorry, almost through the 2.2 CFCs, then I can turn my attention to other issues/PRs. |
|
@alastc this is probably one of my oldest PRs on hold (september 2019)...any chance this could be looked at? |
| <p>A <strong>path-based gesture</strong> involves an interaction where not just the endpoints matter. If going through an intermediate point (usually near the start of the gesture) also affects its meaning then it is a path-based gesture. The user engages a pointer (starting point), carries out a movement that goes through at least one intermediate-point before disengaging the pointer (end point). The intermediate point defines the gesture as requiring a specific path, even if the complete path is not defined.</p> | ||
| <p>A <strong>path-based gesture</strong> involves an interaction where not just the endpoints matter, but how the pointer moves between these points.</p> | ||
|
|
||
| <p>If the gesture is only recognised if the user moves in a (mostly) straight line from the start point to the end point, it is a <strong>path-based gesture</strong>.</p> |
There was a problem hiding this comment.
This seems in conflict with other types of gesture subsumed under path-based gesture, like drawing a particular shape.
|
|
||
| <figure id="figure-path-based-gesture-2"> | ||
| <img src="img/path-based-gesture-2.png" width="400" alt="Hand showing a starting touch, 1. Moving through a second point, 2. Going to one of several points,3." /> | ||
| <figcaption>A <strong>path-based gesture</strong> involves starting a pointer movement that goes through at least one intermediate point before the end-point. The end-point may be a continuation, or allow for various movements.</figcaption> | ||
| </figure> | ||
|
|
||
| <p>Examples of path-based gestures include swiping, sliders and carousels dependent on the direction of interaction, and other gestures which trace a prescribed path such as drawing a specific shape. Such paths may be drawn with a finger or stylus on a touchscreen, graphics tablet, or trackpad, or with a mouse, joystick, or similar pointer device.</p> |
There was a problem hiding this comment.
Those "other gestures which trace a prescribed path" are in conflict with the definition of path-based gesture above.
|
/me goes back to look at this PR from 4 years ago to see what it was even about... and yes, it's quite likely that things have now moved on, particularly in light of the new Dragging Movement SC ... |
Co-authored-by: Alastair Campbell <ac@alastc.com>
Co-authored-by: Wilco Fiers <WilcoFiers@users.noreply.github.com>
| <img src="img/path-based-gesture-1.png" width="400" alt="Hand showing a starting touch, 1. Moving through a second point, 2. Going to one of several points,3." /> | ||
| <figcaption>A path-based gesture involves starting a pointer movement that goes through at least one intermediate point before the end-point. The end-point may be a continuation, or allow for various movements.</figcaption> | ||
| <img src="img/path-based-gesture-1.png" width="400" alt="Hand showing a starting touch, 1. Moving in a straight line to a second point, 2." /> | ||
| <figcaption>A <strong>path-based gesture</strong> where pointer movement is only allowed in a straight line from the start-point to the end-point. If the user strays from the straight directional path, the gesture is not recognised, has no effect, or is aborted.</figcaption> |
There was a problem hiding this comment.
The trouble is this still does not differentiate clearly between dragging movements and pointer gestures - because sliders in touch environments may also require (initial) directional movement.
But these can be moved in both ways so that indicates another (better) differentiator - uni-directionality. As said elsewhere, I think there are benefits in moving away from the "intermediate point" definition because I have seen it cause lots of confusion. My alternative suggestion has been to define a path-based gesture in another way (DRAFT):
"A pathbased gesture requires a particular direction of movement of the pointer across the display. It may in addition require a particular speed of operation or length of path for attached functions to be triggered."
That would differentiate better from axis-constrained dragging movements, because in these, there can be in principle two directions of movement (as in an image slider).
Not that it matters that much, because 2.5.1 and 2.5.7 now both require a single pointer alternative.
There was a problem hiding this comment.
If a slider can be moved both ways, I think that's an example of two path-based-gestures (PBG), one for the first direction, another for the second direction.
Overall, we could consider the slider as either a PBG or dragging depending on the implementation, that's why it doesn't make a good example.
I think this example description is ok though, because most sliders wouldn't fit into the "If the user strays from the straight directional path, the gesture is not recognised, has no effect, or is aborted."
Regarding the alternative description:
A pathbased gesture requires a particular direction of movement of the pointer across the display.
Didn't we have examples where, so long as you started in a direction, it didn't require you to finish in that direction? That's why we used the intermediate point.
Also, what about multi-direction gestuers, e.g. up and left.
|
Noting that there are some comments above, but the commenter is happy to merge this and come back with a different update. |
alastc
dismissed
detlevhfischer’s stale review
Detlev was happy to merge and come back to it.
There was a problem hiding this comment.
+1 to be able to close this and move on and tackle again. As my comments to the PR make clear I still think that the "intermediate point" definition causes a lot of confusion, particularly since behaviour differs depending on the OS/UA wher the gesture (or movement) is carried out.
mbgower
deleted the
patrickhlauke-understanding-pointer-gestures-addition
branch
Two proposed changes to https://www.w3.org/WAI/WCAG21/Understanding/pointer-gestures.html (first one discussed with @alastc yesterday)
Preview of pointer gesture understanding