Overlap of 2.5.1 Pointer Gestures and 2.5.7 Dragging Movements

[patrickhlauke]

If we have something like a path-based slider (where, as soon as you move your pointer out of the track, the slider "knob" doesn't follow the mouse anymore), 2.5.1 applies...but does 2.5.7? Or is the thinking that because it's path-based, it doesn't count as a pure "dragging movement", hence 2.5.7 does not apply?

and If so, should the definition for "dragging movement" be tweaked to make it clear that path-based movements (that still involve "dragging") are excluded from that definition?

https://w3c.github.io/wcag/guidelines/22/#dfn-dragging-movements

or should the normative wording for 2.5.7 be tweaked/clarified (probably too late now)

"All functionality that uses a dragging movement" > "All functionality that uses a dragging movement that is not path-based"

[bruce-usab]

Bruce will try and find related conversation issue. Dragging moving definition is very specific with mouse up/down. So if following stops without mouse up, might not meet definition. Moving mouse pointer away can be a cancellation.

@patrickhlauke we discussed on backlog call 8/18 -- can you provide another example?

[patrickhlauke]

having a hard time parsing that first sentence of yours, but to be clear: in general, any time you grab something and then have to follow a specific path and then release (sliders being the most obvious ones, when/if they are truly path-based and bail out of the interaction when you leave the slider track). it then is both a path-based interaction, and a dragging interaction, so assume that it then falls under both SCs. and if so, should be acknowledged in the respective understanding documents (happy to do a PR, but not until I hear if this take is "correct" based on other folks' understanding of these here)

[bruce-usab]

Also from call, adding example to Understanding with using finger as pointer would be helpful to make it clearer that SC is not only for mouse.

[bruce-usab]

@patrickhlauke in the conversation today, we focused on the glossary definition; emphasis added:

An operation where the pointer engages with an element on the down-event and the element ... follows the pointer until an up-event

Agreed, sliders in some kind of frame is a common example. The usual pattern, that bails out of the interaction when you leave the slider track, is not covered under 2.5.7.

Because there is no mouse-up, there is no dragging movement. From the SC, again emphasis added:

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging.

As defined, within the context of 2.5.7, by cancelling the operation before the mouse-up, that's not using a dragging movement. The 2.2 term, dragging movement, does not describe all dragging interactions. This distinction is part of how we were led to define "dragging movement" and not merely "dragging".

[patrickhlauke]

Because there is no mouse-up, there is no dragging movement. From the SC, again emphasis added:

there is an up movement if you pointer down, move along the track (to avoid it bailing), and then pointer up. that is a dragging movement.

[patrickhlauke]

i.e. this case https://codepen.io/patrickhlauke/pen/yMpbXa of a slider that:

• relies purely on dragging the slider knob
• doesn't provide a non-dragging way of setting a value
• is path-based (as it bails out when you stray out of the track while dragging)

fails both 2.5.1 (for being path-based and not providing a non-path-based alternative) and 2.5.7 (for just using dragging movement with no alternative). which is fine, but needs to be explained/mentioned in understanding

[detlevhfischer]

@patrickhlauke It also bails out if you drag a bit too fast - I suggest to adapt the script so it won't bail out if there is no up event and the pointer remains within the track.

[patrickhlauke]

@detlevhfischer ah, noted, but that's beside the main point here...

[detlevhfischer]

I had assumed a core aspect of dragging movement was that it is not path-dependent, but the definion of dragging movement does not include that bit of disambiguation. It is only the Dragging Movements Understanding doc that does this:

"In contrast, for dragging movements, only the start and end point of the movement matters, not the actual path"

[patrickhlauke]

Personally, I think it's better to accept that there might be a small overlap (where a path-based, drag-only widget fails both 2.5.1 and 2.5.7), and explaining that in the understanding, rather than trying to now redefine unintuitively that "dragging movement doesn't cover dragging movements that are also path-based", which would just open up a whole other can of worms making the SC inscrutable

[detlevhfischer]

Ah, gone back to the start of the issue now, I see. My understanding was always that gestures and movements will be either / or (and the difficulty that content may behave differently on different UA / input methods has always been a problem here, especially concerning directionality, where it may seem required in a touch context, and not required in a mouse pointer context). Having said that, I think your codepen example would fail Dragging Movements and not Pointer Gestures since the thumb will just follow the pointer in any (both) directions within the given track - it is just a limitation of the field in which it can follow by constraining movement to a line. So there is no evaluation of duration, speed, or length of the engagement as you see it with typical pointer gestures (take those used for deleting mails or bringing up additional menu options like mark or file or "more")?

[patrickhlauke]

I think your codepen example would fail Dragging Movements and not Pointer Gestures since the thumb will just follow the pointer in any (both) directions within the given track - it is just a limitation of the field in which it can follow by constraining movement to a line

didn't we have lengthy conversations that this also falls under "path-based" ?

From the examples in https://w3c.github.io/wcag/understanding/pointer-gestures.html

A custom slider requires movement in a strict left/right direction when operated by dragging the thumb control. [...]