<trackbot> Date: 18 September 2014

<scribe> scribe: kim patch

<Kathy> http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments

15 minute discussion to talk about techniques people are working on.

Kathy: when we are modifying the technique, the feedback from WCAG said should be more specific to mobile. Want to make sure we are encompassing all the feedback. Andrew?

Andrew: we're going through some growing pains trying to figure out exactly how we need to do this. unfortunately I don't think we've had a clear strategy where we can say this is what needs to happen. that's part of what we've been expecting that we get from you guys. This is what we are planning on doing, this is how you will see the techniques come in. Absent that, we get a technique and...
... then people start thinking about – that's not the way we like it. The result is it ends up creating frustration for the people who did the work to create those modifications. That's something that may be merits a step back so that we can do that.
... so everyone feels like they're putting their efforts in the direction that's going to be likely the most productive.

Kathy: when we were going through making the changes what we did was we took a look at all the different sections and stated whether we thought there should be a change or not. I think the difference is just the level of changes that we were doing – we were taking a look saying where would we add an example and I think WCAG were saying a lot of them could be applicable, but wwe haven't...
... necessarily done changes to these
... G4 example – we added a mobile example, feedback was we should add mobile to the other examples. I think that's where the difference was. So I think when were going through the techniques we need to make sure we are including mobile language throughout, not just an example, but incorporating mobile throughout the technique.

Jon: with G4 I thought all the examples relied on the keyboard. You could do a gesture but that might not be discoverable, so I just suggested a button. That would apply beyond mobile space because it's a button. Just seem like the comments were we don't need a button.

Feedback was we shouldn't be promoting this type of activity anyway because we don't want people to use carousel. So for me that's frustrating. People are doing it. This technique is addressing it. When people make comments like we shouldn't be doing this at all I don't think that's productive.

Andrew: I agree. range of school of thought with techniques – one is only do things that are pure, other is we interact with all sorts, and we need to deal with it all
... I think when push comes to shove people in the working group agree, although it may be grudgingly, that we have to deal with all of it.
... I think this is a conversation we will have again and again. Is this something we want to advocate for.
... G4 key thing is not having such a difference between example that supports mobile and doesn't support mobile. Most productive piece of feedback is hey, everything needs to be mobile ready why not put the same advice that we are talking about in the second example back in the first example because it illustrates the same sort of point.
... any technique, applicability to mobile environments – need to distinguish where it doesn't apply to mobile or where we need to call it out

Jon: my fear is that it may become confusing or overly complicated to do that, but I agree that that's how we should do it

Andrew: I think on a general technique you will have some of that overlap. It may be that there is a need for an HTML specific technique that does it in those different ways. It might be part of two different HTML techniques but also an example that's alluded to within a general technique

Jon: sometimes it's hard to know where the boundary is between a general technique and talking about certain technologies

Andrew: totally agree. My desire is to improve the consistency of the techniques in terms of how they bridge that gap. But there's a lot of techniques and we find those sorts of inconsistencies all the time. I do think that is worth trying to make general techniques general and to make HTML or other technology techniques specific
... I'm trying to feel out where that distinction is or where the line is – we solely to figure them out

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G4

Detlev: G4, that first example – if it's too specific we can just skip it. Example, tapping one would stop the scrolling, that would not require an extra pause button, that may be debatable. Wondering about opinions about what would qualify in that case. Acceptable gesture for interacting to do the same thing – stopping the scroll. Having said that that maybes to specific, so if we want to...
... move on I'll accept that.

Kathy: we did change it to include a gesture
... …pressing or using a repeat gesture would restart it again

Detev: even putting in those examples could be slightly misleading

Kathy: that suggestion came directly from the WCAG working group – Andrew was there further discussion

Andrew: the first example which originally said scrolling, pressing the escape key. The key issue with that first example is that it even talks about a specific key. It might be that the way to make this more mobile friendly is that it needs to say either less or more. it could say users who need more time to read it can perform a predefined action – toggle scrolling – without signing that...
... it has to be without something we identify as a keyboard action. I think it's better to say that they can execute a defined keystroke or use a touch gesture to stop and again restart it. It's not telling you a whole lot is just giving you the general idea.
... I do think there would also be benefit in an HTML technique that would tell you how. I don't know if we have that currently related to G4, but if we did we would want to make sure that it had a keyboard as well as a touch mechanism for executing that control.

<jon_avila> we don't have an HTML technique as far as I know.

Andrew: these examples are general, people don't have to read these examples and then say I'd know exactly how to call these up

Kathy: but are we losing something that people had before

Andrew: I don't think were losing much. If we said users who need more time can press the appropriate key on the keyboard or use the appropriate gesture as indicated by the site, or by user convention. But we don't need to say how exactly to do it. We're just conveying rough possibilities. They can't be too crazy, but with this one the main issue that made it not mobile was it was talking...
... about the escape key. The way to address it was to not talk about the escape.

Gavin: concern because we have other techniques to cover the inability to use a touch-based gesture. There are so many different types of devices out there – are we only talking about touch-based devices or the lower common denominator

<jon_avila> +q

Mike: we haven't really raised the fact that voice is becoming a way to control a device and there's no mention of voice as an alternate in many of these examples. It just illustrates the fact that we don't always know what's going to be on a particular platform. We don't call things like switch control
... my sense of this is give the general principle and give an example, problem is is the example intended to be mobile or desktop. I think that's where the confusion – a traditional PC experience with keyboard, but if you have a keyboard attached it could be the same thing with mobile. Maybe it's just being more clear about when we intend to discuss a mobile example versus a traditional...
... example

Andrew: I think Gavin's and Mike's points are correct and well taken. It's easy to talk about the things that we know well and they needed what we have to thread is how to be sufficiently broad and vague enough while remaining useful
... that's a little bit easier for some of the general techniques and maybe that pushes example more in the direction of users who need more time can do X and doesn't say escapee and doesn't say perform a touch action or gesture but – I don't know what the right language is to say the user needs to provide the appropriate response to pause the scrolling and again to restart it
... but saying something along those lines would allow it to be more encompassing or at least not eliminating future possibilities where there's voice as the desired may be not future – these are things we want to include. users can execute, may be keyboard, gesture, voice, also we use it open for future – brain interface

Alan: I think that's a good point, the technique should be general enough – scrolling should be able to pause. And then a list of all these things that could be – keyboard, touch, speech. But the key aspect is just the usability the ability to do something.

Kim: how does IndieUI fit in:

<jon_avila> we could say "device independent method"

Andrew: and implementations yet – if the answer is no then maybe it's too early
... or putting information about that in the user agent support notes to help people understand where a specific technology-based technique actually would work versus not

Jon: I'm all for saying device independent, but at the same time we don't want to lose information. One of the problems with separating out mobile and HTML is we are talking about HTML on many the mobile platforms. I hate to just separate out – I'd like to be able to reference mobile in HTML. It would be nice if there were a platform support section where we could say this is how it might be...
... solved on a particular platform. Device independent, but on platforms with a keyboard it may be a keystroke, it may be a voice command. It would seem like it would be great if we could have a place to do that in a consistent way. This is going to come up in many of the techniques

Andrew: I hope I didn't convey in some way that I thought that mobile would not be part of the HTML techniques. I hope and expect that it should. I think there may also be times where there's examples within a particular HTML technique where – here's how you do it on mobile devices, here's how you do it on desktop devices. Because ideally you create one chunk of HTML code that works...
... everywhere but in some cases people are going to be generating different chunks that depend on different devices it's available on.
... changes the technology – support changing or IndieUI becoming more available – examples change. right now the easiest way to do that would be to break down some of that information in the user support notes. We're talking about revisiting how all the information is structured– may be more clear and direct

<AWK> +1

<jon_avila> yes

Kim: wanted to stress that it's important from a user perspective to have access to all input methods across all platforms

Gavin: is there a need for a separate heading of mobile specific – whether or not that's an easier experience for someone to understand them

Kathy: we still haven't quite figured out how the mobile techniques are going to surface or if there's going to be some sort of tag or something else. I think that's what Andrew was talking about and one of the options is to have a heading for mobile specific. Andrew – you guys are working on what we are going to do with that, right

Andrew: probably one of the most useful things would be which of these techniques is totally inapplicable to mobile. And then the question is okay, is this technique actually useful in the real world. Maybe it is at this point but, my reluctance to have a section that says this applies to mobile is I would rather shift things so we can start from the presumption that – of course this...
... applies to mobile. I'm not sure how that actually plays out in reality with the information that we have and the techniques that we've got
... bottom line we want to make sure people know these techniques apply the mobile but I'm not sure how we'll do that yet

Gavin: is there any overlapping work with mobile best practices group?

Jeanne: not much overlap
... on the idea of a separate mobile document – I was proposing to Judy that we have a separate mobile document and have it include all the techniques that we think apply to mobile even the ones that we aren't changing. I think that's going to be easier to do than identifying the techniques that don't apply to mobile. Document with techniques that we think do apply to mobile without any...
... changes.

Kathy: do we need to revisit the ones that we said need no changes based on the language WCAG said that was needed

Jeanne: Judy said she was open to the idea but it needed a lot of discussion before it could go that way

Kathy: how do people feel about moving forward on making changes to existing techniques – do you feel you have more clarity on that now as far as direction or is there other information we can provide to further clarify that?

Gavin: it's clear for me

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G4

Kathy: let's take a look at G4 for a minute – as we were talking I made some changes to it. Based on the discussion we just had, does this then address what we were talking about

<jeanne> q_

Jon: I think these are fine as examples, but I would rather be general, then say these as examples after that

<Detlev> +1

<gavinevans> +1 with independent manner

<jon_avila> +1 to jan

Jan: I agree with John, if we say this is to be controllable in a device independent manner and defined device independent manner as all these things – then we don't have to have all these examples be so long and repetitive

Andrew: my only concern about just saying they do it in a device independent manner is I think we also want to leave open the possibility that people – they may implement multiple ways to do the same thing so that it doesn't have to be one device independent way, that might be the best way. It may be that it is done through a variety of ways. So another way to do it would be to take one of...
... the examples, and say the user can pause or restart the scrolling through a device independent mechanism and another can say it's done through a variety of different mechanisms that allow a totality of possibilities. One is highlighting the ideal and one is highlighting what might be the reality in some circumstances. Just a suggestion

<AWK> "modality independent"?

Detlev: device independent, I'm not sure if that's the right-mode independent, input mode independent? That the detailed question that we can sort out. I agree with Jon that it's good to have a generic statement that it can be controlled in a not mode specific manner. But I do like the examples which are specific – mention escaped or tapping to stop would be helpful, otherwise the general...
... techniques become so general that they are meaningless.
... I quite like the idea of general, then specific examples for keyboard, touch and speech, something like that, I quite like that

Kathy: given that, what would you change – the second example?

<AWK> A site contains a carousel of products that automatically rotate. Users who need more time to read about the product can pause the scrolling by activating the "Pause" button by any input mode available on their device.

Detlev: I quite like the suggestion that users who need more time to read can restart. Then list the three different examples of different input modes. I don't mind some repetition there even because for me as a reader, as a user of the general technique I need what it means in a concrete case. If you are trying to understand what you should do it's always better to have some examples even...
... for general technique

Gavin: although it's needed from a general specific techniques point of view, needing a device independent method. There is the other side that's needed – more of a general project manager coming in saying I need to meet this technique what way do, how does this impact user in general. I think the two are needed. The examples should complement the techniques.

Jon: regarding example number three, as someone pointed out there is G186 which covers already, so if we wanted to leave that out that would be okay

Kathy: how many people are for keeping number three?

<gavinevans> that should be G186

Jan: I like the mention of carousel

Andrew: suggestion for third one

<AWK> A site contains a carousel of products that automatically rotate. Users who need more time to read about the product can pause the scrolling by activating the "Pause" button by any input mode available on their device.

Andrew: making it general, but still talks about the carousel

<Detlev> +1 for "any input mode available on their device"

Mike: saying activating the pause button is the wrong approach – it's really the function of pausing, not a button that you want to pause or swipe – so I think that's going the wrong direction. I think it would be better to say can pause for continued scrolling by any means available to them

Jon: my only concern is we have a discoverability issue. If you have a button it's very discoverable. In principle I agree that we have the other techniques for control, but I think in general especially where it comes to mobile, even a mouse you don't have on a mobile device. So I think the issue of knowing what is going to happen and discoverability is more of an issue on mobile

Mike: making things discoverable should be its own technique – the technique were focused here on is can you pause something that's in motion

Andrew: one additional distinction: for a sufficient technique the check that I always do mentally is am I trying to describe what is perfect and ideal or am I trying to describe what is sufficient. For this third example if we had a carousel and there was a button on there would we think that it would be sufficient to meet 2.2.1 if the users were able to activate that button using...
... whatever means they had other devices for input. And it may be that there's a different interface that's provided in a different example where there's no button and obviously there's discoverability challenges and how do people do this but I'm looking at this one, this third example and saying this one seems like it's focused around using a button, but it still should be sufficient.

<jon_avila> +1

Andrew: it's the activation of that button that is what is making this one meet the success criteria. It's not to say that there's not other ways to meet the success criteria where there's not a button, but here's an example where you can meet the success criteria and I happens to be that you activate a button through one of several possible mechanisms

Kathy: so you want to keep the button example

Andrew: yes, it works. maybe it's activating a button, but it may also be shaking their left arm because that's been communicated as the predefined mechanism to stop animation on an iwatch

<jon_avila> I have to jump off the voice call. This has been a good dicussion.

Kathy: we are out of time. Great discussion on this. Volunteer to change these examples for next week?

<Detlev> sounds good to me

Andrew: I think you guys are very close. I would suggest, because we have to have this discussion with WCAG as well, but if people on this call agree with the three bullets I think this would be good to send to the working group to consider if you guys are comfortable with it

<Detlev> +1

Kathy: if people are comfortable with what we have now we can send it to the working group and get their feedback

<shebanek_> +1

Kathy: so we will send this to the working group to see if we are on the right track

<AWK> I'll raise it with the WG on Tuesday.

Kathy: continue to work on Techniques, if you can send things you plan to have done by end of the day Friday or Monday at noon at the latest so I can put them in the survey I would appreciate it

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
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: KimPatch
Found Scribe: kim patch
Default Present: Kathy_Wahlbin, Kim_Patch, Alan_Smith, Jeanne, +44.179.281.aaaa, AWK, gavinevans, Jan, Detlev, +1.408.425.aabb, shebanek, +1.703.637.aacc, jon_avila
Present: Kathy_Wahlbin Kim_Patch Alan_Smith Jeanne +44.179.281.aaaa AWK gavinevans Jan Detlev +1.408.425.aabb shebanek +1.703.637.aacc jon_avila
Regrets: Brent Shiver
Agenda: http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2014Sep/0009.html
Found Date: 18 Sep 2014
Guessing minutes URL: http://www.w3.org/2014/09/18-mobile-a11y-minutes.html
People with action items: