Mobile Accessibility Task Force Teleconference -- 23 Jul 2015

<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

Continuation of the Survey Discussion- https://www.w3.org/2002/09/wbs/66524/20150717_survey/

<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

- DRAFT -

Mobile Accessibility Task Force Teleconference

23 Jul 2015

Attendees

Contents

Continuation of the Survey Discussion- https://www.w3.org/2002/09/wbs/66524/20150717_survey/

Summary of Action Items

Scribe.perl diagnostic output