-
Notifications
You must be signed in to change notification settings - Fork 55
single pointer definition includes path-based gestures? #868
Comments
I think seen from the context of 2.5.1 Pointer Gestures it looks indeed odd to have path gestures included in the definition of „single pointer“. I don‘t know when that crept in, and why. Having said that, the SC text says „ single pointer without a path-based gesture“ so it can bee seen as referring to the single Pointer definition while at the same time excluding the path-based aspect of it. Is there some reason why „path-based“ must remain in the definition? I would prefer to get rid of it....
Sent from phone
… On 18. Apr 2018, at 21:54, Becky Gibson ***@***.***> wrote:
This relates to #634 which is closed. I am confused by the how definition of single pointer is used in the Pointer Gestures SC because the single pointer definition includes path-based gestures?
The definition in the 17 April 2018 editor's draft is:
pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures
But 2.5.1 Pointer Gestures says:
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
How can this be achieved if the definition of single pointer includes path-based gesture?
I get the intent, the user must be able to operate using a single point of contact but without moving it along a path. But the wording of the SC implies that a single pointer definition can be split into two parts - single point of contact with no movement and single point of contact with movement along a path. Isn't that really two separate definitions?
I suspect I am splitting hairs.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Proposed WG response: |
Personally, I'd prefer that instead of talking around it, our response would be honest and straightforward enough to admit that the definition is badly written and should not include the reference to path-based gestures, even though it may be too late in the process to remove it from the document. |
Well, two SCs use the definition so either: It would be the current definition and take away the path-based-gestures, or you'd remove the "path based gestures" part of the definition and have to add it to the other SC. Pointer cancellation would have to start: "For functionality that can be operated using a single pointer including path based gestures, at least one of the following is true:" If you define 'single pointer', to me it makes logical sense to include paths, as that is a thing you can do with a single pointer. So of the two options, this seems to be the preferable one. |
This issue was moved to w3c/wcag#394 |
This relates to #634 which is closed. I am confused by the how definition of single pointer is used in the Pointer Gestures SC because the single pointer definition includes path-based gestures?
The definition in the 17 April 2018 editor's draft is:
pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures
But 2.5.1 Pointer Gestures says:
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
How can this be achieved if the definition of single pointer includes path-based gesture?
I get the intent, the user must be able to operate using a single point of contact but without moving it along a path. But the wording of the SC implies that a single pointer definition can be split into two parts - single point of contact with no movement and single point of contact with movement along a path. Isn't that really two separate definitions?
I suspect I am splitting hairs.
The text was updated successfully, but these errors were encountered: