Re: Telco result, resolution

Am 03.06.2019 um 14:45 schrieb Andrew Kirkpatrick:
>
> 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.*
>
Hi Andrew,
OK, I see. I still find it not easy to grasp what is actually meant by 
that.*
*
>
> 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
>
It is always difficult to fully picture what happened in a call based on 
the written minutes. In the survey I had made the point that I felt the 
2.1.1 exception language was not helpful as a starting point for a 
definition of "path-based", and reading the minutes, it seemed that this 
had not been discussed. I think outside the WG, people will have a hard 
time understanding that language.
>
> 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.
>
I agree, this is a real challenge. The mobile a11y TF had originally 
intended to mandate single point activation for *all* path-based 
gestures (including dragging) - this was couched in the term "complex 
gestures" at the time. A distinction between swipe and drag simply 
wasn't discussed at the time in MATF (and the distinction is still 
difficult from a experiential user perspective - it may depend on how 
fast your finger happens to come down and then move on the screen. 
Things like content sliders that can be swiped can usually also be 
dragged). Later in the development of 2.5.1, it surfaced that a single 
point activation requirement for free-form drag-n-drop would be hard to 
implement and make the interface considerably more complex - hence the 
proposal to exclude free-form drag-n-drop, which then brought up the new 
question "How do we then differentiate between dragging per se and 
drag-n-drop actions?"

So the whole discussion is a moving target which has over time changed 
our understanding of what would or wouldn't be in scope of 2.5.1. For 
example, I realised only recently that defining path-based gestures as 
being 'directional' might allow an interpretation where nearly *all* 
path-based gestures (see Alastair's recent video examples) could be seen 
as out of scope of 2.5.1. This is something that I would like to avoid, 
in order to stick to the original intention and meet users' needs. Our 
evolving understanding, in my view, justifies going back to WG 
resolution like 
https://github.com/w3c/wcag21/issues/478#issuecomment-348069753 which 
seemed reasonable a the time. We should reconsider whether the language 
proposed there still expresses what the WG wants to achieve, both in 
order to arrive at clear language that readers will understand, and in 
order to define the scope in a way that it does not offer a huge 
loophole for authors. Of course, there is the option to include dragging 
in another, additional SC for 2.2, but I wonder whether the 
proliferation of SCs which do very similar things is really desirable. 
Then there is the aspect of accessibility for pointer users with AT on, 
that Patrick has highlighted, which might be worked into 2.5.1 or a new 
SC for dragging, or both - another point that supports a return to 
single point activation for any kind of path.
>
> 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 disengagingthe 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
>

-- 
Detlev Fischer
Testkreis
Werderstr. 34, 20144 Hamburg

Mobil +49 (0)157 57 57 57 45

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites