See also: IRC log
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[End of scribe.perl diagnostic output]