- From: Kim Patch <kim@redstartsystems.com>
- Date: Thu, 14 Apr 2016 12:14:16 -0400
- To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <570FC1D8.5090602@redstartsystems.com>
*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> ___________________________________________________
Received on Thursday, 14 April 2016 16:14:25 UTC