Dragging movement definition might be improved

[yatil]

The definition for dragging movement is defined as the following in the CR version of WCAG 2.2:

an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer

NOTE Examples of draggable elements include list items, text elements, and images.

Now per that definition, clicking an element which follows the pointer is a “dragging movement”, even if an up event occurs during the movement, if the element keeps following the pointer. I don’t think that this is what is meant with dragging movement and the Understanding is backing my understanding up with this explanation:

When an interface implements functionality that uses dragging movements, users perform four discrete actions:

1. tap or click to establish a starting point, then
2. press and hold that contact while...
3. performing a repositioning of the pointer, before...
4. releasing the pointer at the end point. Not all users can accurately press and hold that contact while also repositioning the pointer. An alternative method must be provided so that users with mobility impairments who use a pointer (mouse, pen, or touch contact) can use the functionality.

I would therefore suggest the following rewrite of the definition for dragging movement:

an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer, and the engagement ends on a subsequent up event

(I’m also not super sure what the note does here, everything that can be draggable is a draggable element, right? So I don’t find it helpful and would suggest to remove it.)

I’m not sure if that is the right language for this, but I’d like to make sure that this WCAG SC does not accidentally cover discrete two step processes.

[bruce-usab]

For the purposes of SC 2.5.7 I think we only need to capture the initiation of the dragging movement, and not the whole dragging operation. My preference is keep the term as-is and avoid overlap with 2.1.1 and its concept of input that depends on the path of the user's movement (of which, the whole dragging operation is but one example).

[bruce-usab]

This issue is good fodder for Understanding. Ping to @a11ydoer as she and I have voluntold to work on 2.2 Understanding docs.

[yatil]

So, to click (down event + up event) and then click somewhere else (to deposit the item that follows the cursor) would be a “dragging movement” and not allowed? (Because there was an engagement on down and then the element followed the cursor.) Because that would be one way I would interpret to implement the alternative for “single pointer without dragging”. I seriously question if this SC is implementable with this definition.

[yatil]

Or to put it differently: Is something a dragging movement when no continuous button needs to be pressed? I would say no, and the Understanding agrees.

[bruce-usab]

Or to put it differently: Is something a dragging movement when no continuous [mouse] button needs to be pressed? I would say no, and the Understanding agrees.

I agree, that is not a dragging movement. The definition describes the default behavior, and is not applicable to AT virtually holding down the mouse button.

So, to click (down event + up event) and then click somewhere else (to deposit the item that follows the cursor) would be a “dragging movement” and not allowed?

No, that is not a dragging movement, because (typically) there is not the second half of the definition. The and the element ... follows the pointer is not true. This describes a click-select, followed by another click-select (not a click-hold-move-release).

Apple OS X fudges some of the distinction between click/select and click/drag with its menus. In some situations, it treats click-hold (pause) release as Windows might treat click-hold-drag (i.e., the menu stays open, rather than collapsing on mouse-up). But OS X does not do that with, for example, icons for files. Moving files is drag-and-drop, same as Windows. I think the definition is okay, but I am happy to keep picking this apart.

[yatil]

So, to click (down event + up event) and then click somewhere else (to deposit the item that follows the cursor) would be a “dragging movement” and not allowed?

No, that is not a dragging movement, because (typically) there is not the second half of the definition. The and the element ... follows the pointer is not true. This describes a click-select, followed by another click-select (not a click-hold-move-release).

Just so we are clear the behavior in this Codepen would fall under the definition of dragging movement here: https://codepen.io/yatil/pen/ExLVpLr

This would be a suggestion I would give to clients who want an alternative to dragging. But it is itself dragging (in the current definition).

Apple OS X fudges some of the distinction between click/select and click/drag with its menus. In some situations, it treats click-hold (pause) release as Windows might treat click-hold-drag (i.e., the menu stays open, rather than collapsing on mouse-up). But OS X does not do that with, for example, icons for files. Moving files is drag-and-drop, same as Windows. I think the definition is okay, but I am happy to keep picking this apart.

Unsure how this relates to this issue as there is no following in those menus and we are talking about web accessibility guidelines.

[bruce-usab]

Just so we are clear the behavior in this Codepen...

My first impression is that is a model technique for meeting the SC. Very nice!

My OS X example is a bit OT. I offered it only to illustrate that click and drag is not always so clear cut. Your Codepen is an example of that as well!

[yatil]

Just so we are clear the behavior in this Codepen...

My first impression is that is a model technique for meeting the SC. Very nice!

Okay, but the definition says that the technique is a dragging motion (down event, element follows), and the SC says such dragging motions must have alternatives. Hence my suggestion for clarification.

[bruce-usab]

...the SC says such dragging motions must have alternative

The SC does not require an alternative. Your CodePen example is an operation [that] can be achieved by a single pointer without dragging so it is a technique that meets the SC. You are meeting the requirement directly, so no alternative is needed.

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

I agree that Understanding should provide clarification that content can meet the requirement of the SC directly.

[yatil]

We go in circles now. Dragging motion as defined would include the example I put on CodePen:

an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer

Hence my asking for a better definition. 🤷‍♂️

[bruce-usab]

Yes, your example is dragging. But that is okay.

I am of the opinion that both the definition and the SC are fine as-is. The AGWG has been reviewing (and repairing) instances where there is (was) some recursion, mostly flagged by @patrickhlauke to my recollection. This SC/definition seems fine to me -- regardless of your example of dragging using only a single pointer.

The only patch I could see is taking out one use of dragging, so:

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

But I think I like that less -- because it is kind of denying that your CodePen example is dragging.

[yatil]

OK. I don’t agree but I will close this issue now. I can’t waste that much time in a 1:1 discussion.

[bruce-usab]

I can’t waste that much time in a 1:1 discussion.

Fair enough! I had hoped your raised concern might have attracted some additional conversation from others as well.

[detlevhfischer]

Just so we are clear the behavior in this Codepen would fall under the definition of dragging movement here: https://codepen.io/yatil/pen/ExLVpLr

In my view this implementation would not fall under dragging, so I would support @yatil s amendation of the definition.

[mraccess77]

Some dragging movements appear to work prior to the up event. For example, a volume slider can be adjusted with still dragging without dropping. The up event is used to finalize the action but the action - adjusting volume still works before the end/down event. Are there any situations were dragging doesn't include a drag and is not a gesture. Drag and item to a box and once in the box you don't have to release before performing another action.