Meeting Minutes 18 September 2014 - Mobile A11y Task Force

MATF Minutes URL: http://www.w3.org/2014/09/18-mobile-a11y-minutes.html

Text of minutes:


  Mobile Accessibility Task Force Teleconference


    18 Sep 2014

Agenda 
<http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2014Sep/0009.html>

See also: IRC log <http://www.w3.org/2014/09/18-mobile-a11y-irc>


    Attendees

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
Chair
    Kathleen_Wahlbin
Scribe
    kim patch


    Contents

  * Topics <http://www.w3.org/2014/09/18-mobile-a11y-minutes.html#agenda>
     1. 15 minute discussion to talk about techniques people are working
        on. <http://www.w3.org/2014/09/18-mobile-a11y-minutes.html#item01>
  * Summary of Action Items
    <http://www.w3.org/2014/09/18-mobile-a11y-minutes.html#ActionSummary>

------------------------------------------------------------------------

<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


    Summary of Action Items

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> 
version 1.138 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2014-09-18 16:07:36 $

------------------------------------------------------------------------

-- 
___________________________________________________

Kimberly Patch
President
Redstart Systems, Inc.
(617) 325-3966
kim@redstartsystems.com

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

Blog: Patch on Speech
+Kim Patch
Twitter: RedstartSystems
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________