Present

TOPIC inclusion exclusion issue in dragging gestures

Detlev: need to discuss this – I've taken a stand but getting less support than I expected. Want to make sure I'm not overstating the point. Wondering what people's positions are – whether I'm on the right track or not

<MarcJohlic> https://github.com/w3c/wcag/pull/714#issuecomment-492986018

Marc: latest comment

Detlev: path based gestures includes both swipe gestures, directional and also dragging gestures, so we would talk about things like control sliders with thumbs. That was my recollection that we included that and that our intention was to mandate single-point activation controls
... so some alternative to actually performing a drag on the screen
... then arguments that dragging gestures would not come under this – as long as you kept contact with the screen thumb along the axis but wouldn't matter where your finger was so not a gesture like a quick swipe – that was the argument
... 2.1 exception – signature to write a check etc.
... it was the starting point. Mike G picked it up changed and deleted an example, rough agreement on the call but I think people had not thought about it I was on the call but hadn't thought about it and didn't put a minus in so it seemed like agreement
... then Alister had another pull request which would keep control sliders in scope. Some in favor, some needs more discussion, but no objections
... indicates to me that people haven't really made up their mind on what to include and what to exclude
... so either exclude everything that's not a directional swipe regarding path based gestures or include swiping and dragging as long as they are directional, which I'm finding difficult to define because directional does that mean a straight line – if you veer from that line with that cell count is directional and how far can you therefrom that line
... it's very difficult to define Multidirectional.
... I've talked to some users, one has answered who cannot move at all, just uses his mouth to move the pointer and he has ways of simulating dragging and swiping options but it's very hard
... he was very strongly about keeping it in scope
... the normative text allows us to include both. We should look at the exception from 2.1.1 to use that. We should also define operation path based gestures as has directional intent. Control slider Or content slider.
... in my view it doesn't matter whether you can actually move your thumb up and down after you've made contact, people won't actually do that
... want to know what the consensus is in the group. Maybe middle position directional gestures in scope, which can include sliding. In scope as long as you keep it wider which is more usable you would not be required to have alternative activation for a slider maybe
... Jake points out that some of the content sliders you can slide by using drag-and-drop technique at the bottom of it. From a user perspective, experiential perspective this is not a division between dragging and dropping – it's good to keep these things in scope
... I wish that everyone who hasn't formed an opinion on this would come in to the conversation
... everything that's not free-form drag-and-drop should be in. As soon as you have a situation that's free-form that would be excluded because of the complexity. But would be encouraged to activated in such a way that it single point activation. That's a difficult cutoff point but I think it's doable. That's my point of view

Detlevv: other opinions?

Kathy: when we had these discussions originally drag-and-drop was definitely in there and we had an example for it. I'm in favor of your hybrid approach – drag-and-drop is in except for the free-form. I would get behind that
... we are doing that for keyboard access so it's not like were doing something different For pointer
... I agree with you that just because we have the keyboard side doesn't mean it's taking care of here
... I have had users very difficult usability testing on mobile

Detlev: drag-and-drop is the one thing that there is increased complexity

Kathy: I think free-form drag-and-drop needs to be excluded, and anything other than that is implementable, is reasonable enough to have in the guideline

Kim: adding my voice to the user email Detlev sent – difficult to drag and drop by speech, possible but very very cumbersome

Detlev: free-form you could probably argue that if you have slots right or left would be an easy thing to do. It's difficult. I would just say not to make it to demanding it would be all right to keep free-form drag-and-drop which could come in many different shapes, out of scope for now. But that's one of the things I'm not quite sure about. Listbox rearrangements are different from sliders because once you pick up one item you see others sliding [CUT]
... filling that space, so it's different. I'm not entirely sure what the best cutoff point would be.

Marc: I'm trying to think what would be considered a free-form. I can move something down left or right, next column or five columns over, really further than that just scroll the whole app horizontally. I was trying to figure out if that was considered free-form versus having a really set path.
... I'm in agreement with keeping free-form as the exclusion, but what is free-form

Detlev: and axis– everything that moves along that access is good. Silo, another silo further to the right, current position and then place that thing somewhere is more complex. I think that's a doable separation

Kathy: Marc, are you in agreement keeping free-form exclusion but the rest of it is in scope

Marc: I think so. Trying to find out from Mike What his disagreement is

Detlev: what he said is is hard to explain to developers and designers what's in scope and what isn't – look at existing apps and future apps and say we have a slider, why do we need to add increment buttons we don't have space
... that's the question he gets so he wants clarity. I agree with that, but I think the position should be

<MarcJohlic> Survey: https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/

Marc: it looks like the existing survey is still open

Detlev: three of The replies says there's more discussion needed – don't know if it will be a new survey from that

Kathy: better if Jake were here to discuss his
... anything else from anyone

Proximity of related

Detlev: I've put out a doodle for an initial discussion – if you want to be part of that new success criterion reply – · Tuesday around 5 o'clock

Kathy: I'll make sure to respond to the survey

Detlev: it would be good to get more people putting in their opinions

Kathy: thanks everybody – next call will go through Jake's

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: KimPatch, Jennifer, Kathy, Jake, Detlev, Marc
Present: KimPatch Jennifer Kathy Jake Detlev Marc
No ScribeNick specified.  Guessing ScribeNick: KimPatch
Inferring Scribes: KimPatch
Found Date: 23 May 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)