See also: IRC log
Kathy: goal today is to finalize
touch and pointer. Goal is to have that all ready to go
... April 26 date to talk about it with WCAG working group, so
those on that group please make sure to be there for that
call
... on wiki – link to all of the different conversations that
we had on the mailing list as well as linking to any of the
other documentation we have
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/HISTORY:_Touch_and_Pointer
Kathy: ultimate goal is to have that pulled together by the 26 so when people are looking at this they can see conversations – back and forth. There were lots of good conversations and back and forth in email
David: not sure whether will have
it mature enough for the 26. There's enough instability around
what people think that there seems to be a lot pulled in
different directions. I'm just not sure where it's going to
land. My experience with success criteria and WC3 things like
this when there's a lot of things pulling in different
directions usually doesn't solve itself right away.
There's...
... quite a bit of direction – Chris was saying he was
concerned about the whole touchdown versus touchup. My proposal
is still the same. In other words the way it's written right
now is a very open – there's a lot of ways to meet the success
criteria
<Kathy> https://w3c.github.io/Mobile-A11y-Extension/#touch-and-pointer
David: telephone guy on the phone
I can go back a couple numbers and it's no problem. So I'm not
sure if we understand what were trying to do with it and if we
do that maybe I'm not saying something right. Patrick has some
concerns, and he was sort of thinking of it as more of
UAAG
... But when I can I have control over that until at least WCAG
3
Jon: keep it touchup touchdown, need to figure out what authors need to do given the current state of accessibility. Need to give them instruction to do that
Kathy: is there changes that you'd like to see John on 2.5.3 based on what we have there today
<David_> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3#Proposed_2.5.3
<Detlev> Can you paste a link to the latest version of SC 2.5.3?
Jon: some notes about touchup – just broaden that to say for some users touchup, touchdown
David: adding a couple sentences to understanding?
Kathy: I agree with you David
that we have a lot of varying opinions on this and we may not
have this in a final state by the time we go to the working
group but I think it's worthwhile getting the reaction of the
working group and saying this is something that we've done and
we can list out the back and forth that we've got in history as
well, and kind of bring it up and see where – and...
... maybe get the advice of others on the working group, see
what people think. Going back and forth in task force right now
and end up revisiting that in working group. Better get
reaction now. Not necessarily looking for things to be final
final. It's okay if there are things we still have some
questions on
... anybody else have comments on 2.5.3. Marc, Detlev
... email thread 2.5.3 from this week or last week
https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2016Apr/0008.html
David: hand shaking issue with
touchup touchdown
... touch than want to get off of it, that's why most functions
are on touchdown
Jon: I'm okay with it but it doesn't address Chris's concern – give user different options
David: as success criterion more difficult because then they can either operate on touchup or touchdown, that's a higher requirement for authors. touchup important thing – BBC required only touchup
Detlev: I can't really see the use case – can someone sum up Chris's argument
David: I was reading his email
closely – think about a geriatric person – might not get the
target when they go down, or get it and then move off of it –
they're going to lose their focus if it's on touchup. That was
his point – Gregg said that also.
... my feeling in response to that is the person might try to
hit a button and they won't get it right because their hand
shook, but they might need to move off it – I think it's the
same person. And if it is, the issue is what gives us more
support. If you have a handshake and you go through midair
there's a lot more chance that you're going to get it wrong
before you hit it than after...
... you hit it
Detlev: we might just drop this,
touchup and touchdown – might be the case where we can't
require. BBC thought it had a case and included – let's go back
to Henny and see if there's research backing this up, how they
came up with this. Or one could try to separate reversible
things from nonreversible things. If this is just a link for
example then obviously could just use back to get out
of...
... it. If it's a form to submit something the confirmation
thing would come in but that could be independent of the type
of touch activation, so I'm not really sure whether we have a
case here, even if it's the case where we have both types of
users, one benefit from touchdown, the other from touchup.
David: I don't think that's
generally the case. I think the touchup is 10 times or maybe 20
times more beneficial than a touchdown. And there are very few
situations where a touchdown would be the best thing. Because
that's when the person is selecting something. We want to have
a difference between selecting an activation. So you should be
able to put your hand on something and say I don't...
... want to do that – change your mind and move your finger off
of it
Jon: why don't we come up with wording similar to other criteria
Detlev: predictable touch?
Jon: say a checkbox, press it and it didn't work, so you press it again, but it toggles and unchecks. If we could put something in there to help users accurately work with touch events so it didn't require a certain length of time for a press and that would help prevent them from activating and then deactivating
Detlev: some touch gestures where
you hold finger down longer – is there a clear recommendation
for dwell time? We have a recommendation which was put into
question by Chris which is trigger things on touchup rather
than touchdown. If that holds then is there anything similar to
dwell time which can be put in a few words? Say don't use the
duration of touch to do anything – if some systems...
... have something happening when you hold your finger for
longer that's putting us into a difficult position – might want
to use that dwell time and potentially do something – do we
have a clear recommendation for that case?
... is there something we could put is a simple do or don't for
dwelltime
Jon: session – people pushing off of the screen, dwell time huge issue. Accidentally activate need to be able to recover. Just like keyboard access needs to be doable without having the user hold down the key for a certain amount of time
Detlev: alternative for actions that are triggered through given dwell time – but that would be a different success criterion if it becomes one
David: making changes in
wiki
... the intent of the success criterion
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3#Proposed_2.5.3
David: this is really the crux of it – somebody gets their hand on it, they change their mind and they want to move their hand away
Jon: so I think the idea that we
want to support touchup or provide another mechanism is good –
that allows for touchdown as long as you have one of those
other actions
... trying to look up other research on this – Jennifer's
research is not published it
David: maybe we can write down a couple of questions to ask them
Kathy: or just send them this and ask their opinion – if they would recommend anything different
Detlev: you wouldn't press your finger for a length of time and then lift up and expect something to happen – does that really apply
Kathy: take out long press in example? add another example about long press or 3-D touch or something like that?
Detlev: one idea is do not require long press – give users an alternative, but that something different it would confuse to have that as example
Alan: can we say with the exception of long press and 3-D
Detlev: lump long touch and 3-D
Kathy: failure in there about actions only being available through long touch and 3-D touch
Detlev: do we have a failure sketched for long press already – something like long presses should not be the only way to do things
Kathy: we have a failure now
David: think that through in context of the success criterion – if there's a way they can turn off long press so that it will happen on touchup – I think with a little bit of work in a couple examples here on this we could be ready for presenting this to a larger group if everybody on our committee is on board with it
Kathy: I think we might want to add a little bit more to the explanation or examples about 3D and long touch. Even if we have it as a failure, having it in the explanation might help more
Detlev: also would be good to
find examples of that failure. I'm not aware of anything where
something you can trigger with long presses is not available in
a different way anywhere
... if we don't have a single example than just a hypothetical
failure – still valid
Kathy: tough – even if we come up with an example things change quickly. Telephone dialer, Backspace
Detlev: aim at web authors trying to calculate long presses to do certain things – difficult to find examples of that
Kathy: in touchup intent, talk about long press gestures can be used but they need to provide a way that either provides confirmation is reversible or makes another mechanism available
long press on app, changes to the mode where you can delete
David: system level
Kathy: one of the big complaints people have in general is it's not simple enough – how do you feel now about the language that's in there
Detlev: easier – I immediately know what touchup means. I think it's better than before
Jon: iphone home screen if you
put finger down and hold you can't activate it – requires some
kind of timing. When you hold it goes dark and then light
again. If you lift up your finger without holding it down long
enough to trigger the long press the icon doesn't activated
all.
... similar to not requiring specific timing for keystrokes,
need something like that for touch
David: made changes, also put in example of phone dialer
Kathy: two instances of another need wordsmithing.
Detlev: change needed – type of interaction that's predictable
Kathy: David will finish wordsmithing and email out to larger group. If anyone else sees changes, please suggest in email. Made good progress this week – continue to work on it on 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. Default Present: Kathy, jon_avila, Alan, Chris, David, Detlev, Jeanne, Kim, Marc, marcjohlic Present: Alan David Detlev Kathy Kim Marc jon_avila marcjohlic Found Date: 07 Apr 2016 Guessing minutes URL: http://www.w3.org/2016/04/07-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]