Re: Telco result, resolution

Detlev,
I’ll add that we did not resolve the survey item as to option 1, 2, or 3, but did resolve (based on lengthy discussion and multiple verbal questions to the group on the call about the discussion) that The WG intended that path-based gestures in 2.5.1 does not include gestures that only depend on the start and end points.

So, we will be discussing the options for how to convey this in the Understanding document, but I believed at the time of the call that everyone on the call agreed with this resolution, and given the information presented on the call I believed that your concerns were addressed even if the conclusion was not in line with what you wanted. You seem to feel otherwise so we can continue the discussion but I do encourage you to keep separate what you want the SC to say from what the group agreed to when developing WCAG 2.1 – this was a challenge on the call and is often a challenge in these sorts of discussions.

Thanks,
AWK

Andrew Kirkpatrick
Head of Accessibility
Adobe

akirkpat@adobe.com
http://twitter.com/awkawk


From: Alastair Campbell <acampbell@nomensa.com>
Date: Sunday, June 2, 2019 at 7:07 PM
To: Detlev Fischer <detlev.fischer@testkreis.de>
Cc: Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
Subject: RE: Telco result, resolution

Hi Detlev,

On the process: We’re adjusting non-normative text so don’t require a CFC, we’re aiming for agreement and progress. However, once we have fully defined an option we could use a CFC as a final escalation point, if needed, to draw it to a close.

On the substance: We’ve got a variety of possible interactions and we can be confident that:

  1.  Swipes (e.g. swipe right) and multipoint gestures are in scope.
  2.  Free-form paths (like drawing) are not in scope.

The awkward aspect is trying to work out what people *think* has been in scope between those 2 examples based on the term “path-based gestures”.

The normative text did not go down the route of something like “Any function activated by a dragging a pointer is available by a tap/click”, I assume because that wasn’t the original intent?

Your question about drag & drop [1] caused Patrick to respond:
> “I'd note that the intention for the SC is to prohibit path-based gestures. i.e. where a user has to follow a specific path / make a specific gesture (e.g. a precisely timed and executed swipe or similar). Dragging/dropping is more of a freeform interaction...while the user is dragging, it doesn't matter if they stray off a specific path or not, what counts is only the start and end points.”

In combination with 2.1.1, that intent covers a lot ground. I also note that doesn’t seem to match Patrick’s (or your) most recent comments in the survey [2].

Towards the end of the newer thread [3] you said:
> “We have excluded drag-n-drop not because there is no user need, but because having simple gestures for it is very tricky and likely to meet strong resisitance from developers.”

Which is fine as far as that goes (and I think there was a vote in support of that), but it doesn’t help clarify why that is out of scope based on ‘path based gestures’. That is the critical part of the SC text to define scope. You were saying that drag & drop doesn’t fit ‘essential’ but should be excluded.

If something isn’t ‘essential’, and we are excluding it via ‘path-based gestures’, then we need a clear way to define that. My attempt needs work, but was:
“A path-based gesture involves an interaction where the user engages a pointer with the display (down event), carries out a directional movement in a pre-determined direction before disengaging the pointer (up event).”

That was updating from the current: “a user interaction where the gesture's success is dependent on the path of the user's pointer movement and not just the endpoints.”

The aim of the update was to say that if you engage (down event), and can move in any direction without triggering a function, it is not a ‘path-based gesture’. If you have to move right (for example), then it would be a gesture.

The tricky ones to classify with drag and drop (or not) are:

  *   Sortable lists [4] (a vertical equivalent of a horizontal slider).
  *   Native HTML scrolling, e.g. where you put overflow-x on a box that can then scroll right.
  *   Panning a map.

I agree with (John’s?) comment about including examples, but we do need to pin down the path-based gestures definition first so we understand what it includes...

Cheers,

-Alastair

1] https://github.com/w3c/wcag21/issues/937

2] https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/results#xq27

3] https://github.com/w3c/wcag/issues/403

4] https://jqueryui.com/sortable/



From: Detlev Fischer

Hi Andrew, Alastair,
cc WG
This is mainly about process.

The last call (in which I could not take part) discussed the dragging issue and came to a resolution, squeezed in right at the end without straw poll, which looks like accepting option 2 (although I am not sure from the minutes whether it tries to settle that question definitively). The survey had, at the time of the call, a majority for option 3. If I am not mistaken, the points made by Jake, Patrick and me where not discussed in the call.
I understand the reluctance to devote more time to something that may begin to resemble a pet peeve, but the ramifications of excluding dragging as soon as there is no strict directionality technically implemented are potentially far-reaching; as I see it, they would make it impossible to fail common type content and control sliders without single point activation alternative, despite the existence of best practice language and potentially sufficient techniques for sliders.

So I would like to get some clarity about process: what is the status of that resolution; what is it based on despite a different option favoured by a majority in the survey and the absence of a straw poll in the call; will there be a continuation of the debate and/or a CFC summarising options and giving all WG members a final say?
Detlev