See also: IRC log
<trackbot> Date: 23 July 2015
<Kim> trackbot, start meeting
<trackbot> Meeting: Mobile Accessibility Task Force Teleconference
<trackbot> Date: 23 July 2015
<Kathy> https://www.w3.org/2002/09/wbs/66524/20150717_survey/results
<jeanne> scribe: jeanne
Kathy: On the last call, we had talked about Touchend
<Kathy> http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M003
Last week we didn't have a lot of expertise on Touch Events and touchend where they can cause problems with keyboard access.
Kim, with touchend you can slide your finger off without activating it. This is important.
Jon: There maybe situations where
there it is acceptable for touch action -- like putting your
signature on it.
... the keyboard aspect is more for on-screen signature.
... If you are drawing a letter, you don't lift your hand until
the end of the signature.
<David> Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
<David> Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
<David> Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
Detlev: Are there any other examples
Jeanne: a Flyout menu
Jon: Gestures like scrolling
David: THis is the WCAG exception - if the paths are not straight between the endpoints, The signature would be exception.
Jon: and there are more exceptions: drag and drop.
David: the exception is the Path -- not necessarily not a straight path.
Kathy: Jan said that we should limit it to actions that cause a change of context.
Kim: a Swipe gestures?
Detlev: What is the difference
between a change of context -- for example, a radio
button?
... pressing a link, selecting a checkbox -- a more binary
activity.
Kim: what are you gaining for not letting your finger off it.
Jon: it allows you to quickly glance at something without opening it full screen.
Kim: I see the shade control. Does that have to be an exception?
Detlev: This is a technique for a developer that is bound to specific web sites. Is that correct?
Jon: I think it goes beyond apps
Kim: the Shade, you don't slide your finger off it, you flick it back up. If you are used to this action, is the user going to be confused if it doesn't behave the way they expect?
Detlev: The different user agents allow different behaviors. It is beyond the scope of what web developers can control. Can't we bracket that you and focus on what web developers can do?
Jon: Web devvelopers can create Shades.
Kim: @@
Detlev: It applies to more things like a checkbox, a button, a link.
Kim: Better to define what you want and not have it apply to everything else.
Jon: We need the success criteria with all the exceptions, than the Technique could focus on one aspect.
<Kim> Kim: said moving an icon to a different position on the screen is also direct action like shade
Jon: we need to have Failure techniques
Kathy: Would it make sense to draft the Success Criteria now, or do we need more research.
Jon: The challenge is that we go back and forth
<David> +1
<David> http://www.w3.org/TR/WCAG20-TECHS/G107.html
Jeanne: We can start writing what will eventually become success criteria as long as we don't call them normative success criteria yet. WE can flag them so we know that is what it will be, once we are chartered to do that.
Detlev: This is a modification of
an existing Technique.
... for those it is valid, whether it is a touch or mouse
interaction
Jon: there isn't an exact parallel with G107. With this touch technique, we are talking about users putting their finger on an element that they don't want to. It doesn't fit well into the current WCAG>
Detlev: you are right, it is different.
<scribe> scribe: Kim
Jon: this is really about with a
touch device it so much easier for someone to accidentally
touch the wrong thing especially with motor dexterity
challenges.
... I don't know exactly where it fits – helping the user
prevent errors almost related to that but not
Detlev: maybe touch operable but that doesn't exist yet
Jeanne: we should be able to write things that are not in WCAG – not yet, but that's the direction we're going
Jon: people are really looking for this – at least a best practice someplace where the experts agree
Kathy: as long as we maintain WCAG
David: May pick up WCAG with
extension for mobile
... like a Zen diagram with WCAG inside it
Kathy: given that – regardless of what principle it would go under is there a success criteria in here that we can roughly word – this scenario that we've been talking about
David: it would definitely go in operable
Marc: somewhere under 2.2
Jon: feels like some of our potential success criteria don't fit under a number like 2.1 but they may fit under 2. Could we create our own numbers
David: I would say yes when we were making WCAG we thought of all kinds of other success criteria that got dropped
<David> Operable: 2.5 User can recover from wrongly placed finger while finger remains on screen
Kathy: I doing that it might be
easier to have it as an extension – no conflict with other
extensions, we'll have to wait and see how much crossover there
is
... it's not just the success criteria but adding aanother
whole guideline – if we added a guideline for touch or touch
operability we could have some success criteria under that. So
if we went down that path what would be some of the success
criteria that we could make sure we don't lose at this
point
David: Guideline said something about touch events and all are touch events would be in this particular success criteria – all our techniques
<jeanne> We have sections in Mobile Accessibility Note that we could build from.
David: mention behavior that
technology – you can put your finger on the screen and move it
without activating an event. We could have a success criteria
that require that – this is a new way of interacting we never
anticipated a blind person interacting with the screen. It's a
whole new area. We can create a bucket for all that stuff – all
the characteristics of touching like the...
... size is...
... big enough
... characteristics, sizes, behaviors
Jon: primarily related to principal 2, these could be a success criteria
David: we may find that in these extension specs we may need to provide guidance it's not testable, so we couldn't make it required. We will probably run into that more in cognitive
Jeanne: at least we will know
which is testable and which isn't – mark it so we can change it
later. We've done a lot of this already..
... we'll have to go back and recode as details get worked out,
but we are the leading group in figuring out extensions and
what they can do – that's why a lot of the stuff isn't worked
out yet but the way we do it and the problems we find in the
successes we find will shape other taskforces: cognitive,
low-vision
Kathy: ideas for success criteria that would go under a new guideline so we don't lose track of the things we talked about today?
David: the mobile note we have right now – written things so that their success criterion?
Jeanne: just coded them that way
Kathy: review for Jan - touch doesn't fit under guideline, touch guideline and success criteria under that
Jon: what we want to capture from
today's discussion is the exceptions we talked about touch end
and touch start
... direct control – would like the exception to be a little
bit more broad than just the examples we thought of
<Jan> JR: Wondering if mouse and other pointers could fit under such a new guideline addressing touch
Detlev: things that involve tap gestures rather than slides
David: we can probably solve most of the problem just by saying buttons and links and probably two or three other things – static things, things that don't require movement, there are other ways we can say it
Detlev: action initiated by touch start such as text entry boxes. is there any harm on doing that on touch start as long as you don't change the contents?
David: I don't see why you wouldn't want to do that on touch end – you have to take your finger off to start touching anyway. Say I didn't get it right, slide into it, lift my finger off and then start typing. I think that's fine. I think interactive elements that are static or don't require movement or something like that
Detlev: do you want me to add those conditional stuff as we go forward with this technique
David: we want to add success
criteria technique is one layer below – it's a principal and a
pretty fundamental principle and doesn't require us to talk
about specific technologies
... for success criterion it would be a little bit shorter the
title would maybe be a sentence or something we just need to
find a pithy way to say it to capture what it is we are trying
to say. It's basically anything that's interactive and static
that you don't need to move on it in order to make it work we
want to make sure that it's touch off. That's the starting
point
Kathy: we can change it to be more of a success criteria and then build off of that – the actual techniques we can look at what we have in notes, the exceptions. That might be a good way to go
David: I'm excited about making a new success criterion
Jon: one more comment about exceptions – why it might be useful to have exceptions. There might be other ways to solve this problem – could you and your application say I'm going to allow things to be on direct touch but put a delay factor in their, and I want activated for one second or two second and give them time to touch something else – could that meet the requirements of users?
David: yes, but from a usability perspective people will get anxious if things don't happen right away
Jon: if you release your finger it would happen immediately but if you touch your finger, and then drag away. If you haven't moved your finger away and three seconds is going to initiate anyway or if you lift your finger on the place you touch it will activate immediately
Detlev: it's not a very common paradigm so I wouldn't be surprised if people were surprised – it would need user testing at least
Jon: not saying it's great just trying to think of exceptions. how do we meet the outcome based goal
David: after we get these drafted I can run them by mobile developers – can you think of anything you can do that this would mess up? I have some sources, people doing movable app for professional organizations I'm sure others have that too
Jeanne: wording from UAAG – "provide a mechanism to" and then developers have a means to solve that in a way that works best for them
Kathy: at the end of the call – great discussion. Detlev do you have enough to rework this as a success criteria.
Detlev: sure – I don't know where to put it because we don't have success criteria marked up yet – can we create a dummy 2.5?
Jeanne: send it in email – I'll put it in the document
Kathy: Detlev, if you want to send it to David first for feedback.
Jeanne: send it to the list that's the best way
<jeanne> regrets for next week
Kathy: send others so we can put them on a survey
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/parallet with G116./parallel with G107./ Found Scribe: jeanne Inferring ScribeNick: jeanne Found Scribe: Kim Inferring ScribeNick: Kim Scribes: jeanne, Kim ScribeNicks: jeanne, Kim Present: Kathy marcjohlic WARNING: Fewer than 3 people found for Present list! Found Date: 23 Jul 2015 Guessing minutes URL: http://www.w3.org/2015/07/23-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]