MATF Minutes 23 May 2019

*MATF Minutes 23 May 2019 link: 
https://www.w3.org/2019/05/23-mobile-a11y-minutes.html

*


  Mobile Accessibility Task Force Teleconference


    23 May 2019


    Attendees

Present
    KimPatch, Jennifer, Kathy, Jake, Detlev, Marc
Regrets

Chair
    Kathleen_Wahlbin
Scribe
    KimPatch


    Contents

  * Topics <https://www.w3.org/2019/05/23-mobile-a11y-minutes.html#agenda>
     1. Proximity of related
        <https://www.w3.org/2019/05/23-mobile-a11y-minutes.html#item01>
  * Summary of Action Items
    <https://www.w3.org/2019/05/23-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2019/05/23-mobile-a11y-minutes.html#ResolutionSummary>


------------------------------------------------------------------------

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


    Summary of Action Items


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------

___________________________________________________

Kimberly Patch

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

PatchonTech.com <http://www.linkedin.com/in/kimpatch>
@PatchonTech
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________