See also: IRC log
<trackbot> Date: 18 September 2014
<scribe> scribe: kim patch
<Kathy> http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
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:[End of scribe.perl diagnostic output]