Re: Telco result, resolution

Hi Andrew, Alastair,

Presuming Detlev can make our next call, can we add this to our next agenda
for 'conclusion'?

Please and thanks.

JF

On Mon, Jun 3, 2019 at 7:48 AM Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> 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
>
>
>
>

-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com