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

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: Kim
Inferring Scribes: Kim

WARNING: No "Topic:" lines found.

Present: Kathy Kim Detlev Chris Mark David Jeanne
Regrets: Alistair Alan
Found Date: 14 Apr 2016
Guessing minutes URL: http://www.w3.org/2016/04/14-mobile-a11y-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report