MATF Minutes 14 April 2016

*MATF Minutes 14 April 2016 link: *
https://www.w3.org/2016/04/14-mobile-a11y-minutes.html
*
Text of minutes:*


  Mobile Accessibility Task Force Teleconference


    14 Apr 2016

See also: IRC log <http://www.w3.org/2016/04/14-mobile-a11y-irc>


    Attendees

Present
    Kathy, Kim, Detlev, Chris, Mark, David, Jeanne
Regrets
    Alistair, Alan
Chair
    Kathleen_Wahlbin
Scribe
    Kim


    Contents

  * Topics <https://www.w3.org/2016/04/14-mobile-a11y-minutes.html#agenda>
  * Summary of Action Items
    <https://www.w3.org/2016/04/14-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2016/04/14-mobile-a11y-minutes.html#ResolutionSummary>

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

Kathy: wrapping up touch and pointer.
... our guideline is about touch and pointer but not addressing pointer
... as I read through it were really touch focused -- not a lot on 
pointer. Start with Detlev email

Detlev: summarizing email -- moving pointer outside the control, 2.5.3 
was focused on both use with and without assistive technology. Then 
separated that out. Latest version states note: this is when screen 
reader is not running. If we take that focus then the issue is really is 
this something that we are justified to put under WCAG. It's clear that 
all users benefit from an undoable way of...
... implementing input

<marcjohlic> 
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3#Proposed_2.5.3

Detlev: Two use cases -- one benefits from touchup, one from touchdown. 
Also suggest rename to touchup activation, but that misses the point of 
having the broader range of including other mouse pointer events. Wider 
working group discuss whether this should be included or general 
accessibility issue

David: Link shows revised language. Long thread online a couple of 
things came up. Action item to contact BBC to find out what research is 
behind this. Haven't seen pushback online from that BBC requirement
... if a person is going through the air with hand moving toward target 
and has dexterity problems, easier to hit wrong target and move away 
than it is to hit the right target in the first place. There's an 
intuitive aspect that makes more sense on touchup. We could also call it 
touch/mouse up or touch/pointer up

Detlev: BBC guidelines more specific -- touch start, only if inside 
target will fire. Use the support of the screen to move the finger 
inside the target wouldn't be covered by BBC.

David: it's not covered by this either -- not saying that. But I'm 
saying is users are going to miss the target and if they have a big big 
problem missing the target they're going to use scanning software or 
keyboard or something else. If they have that much problems will 
probably not going to be able to help them This is to help people who 
generally get the right target but sometimes they...
... don't. And once they get on it, if they can hit the wrong target 
they can get away from it once their hand is stable

Detlev: use not touch up but touch and mouse up activation or something? 
The trouble is this is technology specific. Also other methods that 
should be mapped to this. The other abstract thing which we had before 
has an advantage even though it's hard to understand

David: previous language selection and activation are independent

Detlev: mind-boggling because you haven't stated thing from which it 
should be independent

David: independent activation just a hook line to remind you of 
something you should know anyway like focus visible -- to say that's the 
one were talking about. But we have to make it fairly clear in the 
language of the success criteria itself.

Kathy: the other thing is should we be calling out gestures. If we're 
going to be including pointer, we are really still talking about touch. 
If there's some future thing, do we want to have this in more general terms?

David: the word focus?

Detlev: not intuitive to say focus gesture means touch start

David: touch start is actually to activate something -- firing some 
JavaScript

Chris: Hovering. this is really about separating -- there's multiple 
gestures. You touch the screen, you remain touch and you stop touching. 
Those are three gestures that happen. This is really about making sure 
we are only firing one event on one action. Hover, focus, control, only 
one happening on one action. How to put that clearly

Detlev: Patrick's event listener thing -- numerous events being fired, 
first down then mouse move then finally touch end and click events -- 
technically there is all that. I don't know whether it helps to say we 
should have one event

Chris: I was trying to separate the technical into the user perceived 
portion. The operating system does dozens of things when you touch -- 
constantly sending you events. But as far as the user can perceive 
there's those three sets of things that can occur

David: when somebody goes after a button there's one thing they're 
trying to do -- activate with the button does. But we are saying in the 
success criteria is that would happen when your finger leaves the 
screen. That's the crux of this

Chris: what if I say it like this instead of touchup activation, what if 
I say don't activate on hover

David: hover is a mouse word -- I don't hover when I'm touching the 
screen. Equating the word hover when my finger is in contact with the 
screen but hasn't left it?

Chris: yes. It's a language in both native APIs for android and iOS
... the event that gets sent when your finger enters the screen is hover
... defining that would be good

David: we actually want to focus on when the finger leaves and comes up 
rather than what not to do when it goes down

Chris: problem I have with the success criteria as it's written now -- I 
have a hard time with a truly objective defense of it. What I like about 
don't do things on hover is it has a solidly objective defense. The idea 
of don't activate things on hover seems solid, doing things on touchup 
harder to objectively defend
... long press is formally defined as a hover that occurs on the same 
object for a period of time, which becomes a standard event at that point

Detlev: if we focus on not doing things on hover it could still be -- if 
we look at mouse -- the situation where you hover and nothing happens. 
But we also want to capture when you press the mouse and initiate a 
caption or fire on mousedown but don't want to activate. It's more than 
just don't do anything if you click and hold down the mouse and then go 
out -- that wouldn't be covered

Chris: why are we concerned about a mouse -- any trouble users have with 
mouse should be covered by WCAG generally.

David: whole touch and pointer event is a bucket

Chris: in that case some of the things I said would only apply to 
mobile/touch users interacting with a touchscreen

Detlev: touch specific language is good with techniques but success 
criterion should be more general
... so general usability issue or does it need to be inside WCAG because 
it supports people who need accessibility in some way

David: when you first put your hand on it it's a hover state.
... that's the language to use. We've been using selection, and some of 
us had a little trouble with the word selection. Do we want to go with 
the word hover or does that seem technology specific?

Detlev: however doesn't cover mouse because mousedown

Kathy: what about the up event versus the down event?

David: up event activation

Detlev: we could try that

Kim: I like up/down -- clear language

David: editing in wiki to up event activation...
... is up event too wide -- selection events

Chris: easy to see -- if selection event and focus event are the same 
thing, you have broken this criteria

Kathy: there's a way to separate activation from non-activation events
... or we could add that to the understanding document

Detlev: wording of understanding -- may be Touch specific things in there

David: fixing, touch and mouse events

Detlev: map more specific terms to our up event thing

Chris: I was trying to think that we could just call it control 
activation instead of up event activation

David: this really is about the up event

Chris: one of the things that would make it completely objectively 
defendable is making the criteria about separating those events and in 
the understanding and the failures lift up the touch event as the best 
practice

David: understanding and failure techniques are to help people 
understand what we are getting at but we can't really have success 
criteria that doesn't say what we really mean. Like saying you can 
separate the success criteria, then they could just do it on the down 
event. it's not wrong, but then you just have to make sure there's 
another way to do things. In a bizarre situation like say...
... it's a piano keyboard they would have to have a little switch on it 
that could say you can come up from it.
... if we don't go on a touchup activation I don't think we have a lot 
to hang on. The larger community says we can't do that -- but I just 
don't see that you can do it any other way than touchup

Detlev: control would be an umbrella term for links, checkboxes whatever?

Chris: yes

Kathy: if we keep up event in the name I think we have to address it in 
the actual body of the success criteria
... if we start looking at this were not mentioning up or down anywhere 
except in the heading

David: how about in the first sentence function activation is on event 
up or has one of the following characteristics

Marc: maybe up events and touchdown events (phone dialer) and long touch 
events are just handled individually -- just separate all those out

Kim: to finger touch and three finger touch too

Marc: all addressed sufficient technique somehow, how a touchup event 
works, touchdown...

Detlev: long presses will often also activate things on touchup -- bring 
up menu, but not always

David: are we limiting developers from using these and is that what we 
meant to do

Marc: I like everything after the: -- that's what we've been trying to 
get to this whole time -- touch event is separate from activation

Kathy: are we getting into two separate things -- two separate success 
criteria?

David: I'm trying to limit this -- concerned that it's too wide -- are 
we prohibiting other types of activation that could be necessary and 
useful. I think we dealt with the activation of touchdown sufficiently 
-- the four criteria

Detlev: exception -- this does not apply to long press where user holds 
down for extended period -- That could be cut off point because there's 
an intention to be doing something
... to abstract if we try to find a wording for this which covers all 
possible events. I like touchup and mapping mouse and touch to it

Marc: event activation and then handle those in the understanding -- 
nuance between up down long, 1 2 3 fingers etc.

David: problem we have separate from non-activation events. Couldn't put 
activation events after touchdown. We're trying to get it at the end of 
it all, which is the up event
... I'm nervous to take away the word up.
... there might be some type of activation is completely legitimate that 
we are forgetting here. But we can say this is our concern can anybody 
shoot a hole in it.

Kathy: would we be limiting it for innovation
... maybe we send out both options on the list and get people's opinions 
on it
... put both versions and side-by-side and continue the discussion on 
the list and next week
... one version taking up out

David: going to put both versions

Kathy: we will continue this conversation on the list


    Summary of Action Items


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> 
version 1.144 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/04/14 16:08:17 $


___________________________________________________
Kimberly Patch
President
Redstart Systems
(617) 325-3966
kim@redstartsystems.com <mailto:kim@redstartsystems.com>

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

Blog: Patch on Speech
+Kim Patch
@RedstartSystems
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________