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

Dragging movement definition might be improved #2669

Closed
yatil opened this issue Sep 7, 2022 · 15 comments · Fixed by #2770
Closed

Dragging movement definition might be improved #2669

yatil opened this issue Sep 7, 2022 · 15 comments · Fixed by #2770

Comments

@yatil
Copy link
Contributor

yatil commented Sep 7, 2022

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.

@yatil yatil changed the title Dragging movement definition unclear Dragging movement might be improved Sep 7, 2022
@bruce-usab
Copy link
Contributor

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
Copy link
Contributor

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

@bruce-usab bruce-usab added this to To do in WCAG 2.2 via automation Sep 7, 2022
@yatil
Copy link
Contributor Author

yatil commented Sep 7, 2022

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
Copy link
Contributor Author

yatil commented Sep 7, 2022

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.

@yatil yatil changed the title Dragging movement might be improved Dragging movement definition might be improved Sep 7, 2022
@bruce-usab
Copy link
Contributor

bruce-usab commented Sep 7, 2022

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
Copy link
Contributor Author

yatil commented Sep 7, 2022

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
Copy link
Contributor

bruce-usab commented Sep 7, 2022

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
Copy link
Contributor Author

yatil commented Sep 7, 2022

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
Copy link
Contributor

bruce-usab commented Sep 12, 2022

...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
Copy link
Contributor Author

yatil commented Sep 12, 2022

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
Copy link
Contributor

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
Copy link
Contributor Author

yatil commented Sep 12, 2022

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

@yatil yatil closed this as not planned Won't fix, can't repro, duplicate, stale Sep 12, 2022
WCAG 2.2 automation moved this from To do to Done Sep 12, 2022
@bruce-usab
Copy link
Contributor

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.

@yatil yatil reopened this Sep 21, 2022
WCAG 2.2 automation moved this from Done to To do Sep 21, 2022
@detlevhfischer
Copy link
Contributor

detlevhfischer commented Oct 25, 2022

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.

WCAG 2.2 automation moved this from To do to Done Nov 15, 2022
@mraccess77
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
WCAG 2.2
  
Done
Development

Successfully merging a pull request may close this issue.

6 participants