W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

07 Apr 2016

See also: IRC log

Attendees

Present
Alan, David, Detlev, Kathy, Kim, Marc, jon_avila, marcjohlic
Regrets
Chair
Kathleen_Wahlbin
Scribe
Kim

Contents


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.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/04/07 16:03:54 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]