See also: IRC log
<trackbot> Date: 02 October 2014
<scribe> Scribe: Kim_patch
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
Kathy: we have all of the ones
assigned in G4 except 1
... questions on techniques that have been assigned
Jon: often not a way to hide or return to the alternative, on mobile there really isn't embedded content
<Kathy> http://www.w3.org/TR/WCAG20-TECHS/G82.html
Jon: canvas really isn't method to hide, remove or mask it (G82). I can take that one and add a canvas example. Anything else people can recommend – are there any canvas techniques?
Andrew: don't know
Kathy: sending a technique by Monday means it will get on the survey for the next week, survey Tuesday morning to give people time to review before Thursday's call
<Kathy> https://www.w3.org/2002/09/wbs/66524/20140916_survey/results
Kathy: survey from a couple weeks
ago. We've gone through some of these, I want to get them
wrapped up and finished
... #1 G4 accepted as proposed, but I wanted to bring up the
WCAG working group was working on additional language to put
into the description. One of the things that they were looking
at adding was information about standard keyboard interface.
Suggested change would include "a standard keyboard interface
is always required under 2.2.1…
<Kathy> http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G4.html
Kathy: Katie and I talked about this on Tuesday after the WCAG working group call. The problem with adding that is if we are going to modify the description we need to include some additional language. The second sentence says a mechanism can be provided either by interactive control to conform to WCAG or by keyboard shortcuts.
<Kathy> This mechanism can be provided either through interactive controls that conform to WCAG or through keyboard shortcuts. Standard keyboard interface accessibility is always required (under 2.1.1), and if non-standard keyboard shortcuts are used, they are documented.
Kathy: wanted to bring that to
the task force to see what your thoughts are on that – what you
think of modifying the description overall
... I want to make sure the language is consistent – keyboard
access is always referred to in a similar way. Right now we've
got language that we are adding – or a keyboard interface such
as an on-screen keyboard - into other techniques. One of my
concerns here is I'm wondering if we need that clarification to
this and that also that second sentence maybe needs "custom
shortcuts"
Detlev: situation where normally
don't get virtual keyboard unless you focus on some element
that accepts text input so you wouldn't be able to bring up a
virtual keyboard – not necessarily– or you would have to know
how to do that so I'm confused whether that means accessible
content can only be provided to devices that will have some
form of either virtual or physical keyboards available...
... at all times – I don't quite understand it
Kathy: keyboard refers to physical keyboard or on-screen keyboard or other interface
Detlev: but if you don't have a virtual keyboard how do you handle that
Jan: 2.1.1 may be a note somewhere that says maybe there are interfaces without virtual keyboard
Kathy: if we add that sentence we are saying that is a problem
Detlev: you can also stop content by tapping or something else or keyboard wouldn't be the only way to conform
Kathy: if the sentence gets added – a keyboard interface is always provided, then you don't have that option
Detlev: and it's just a technique that does not apply if there is no keyboard
Jon: I think it's not necessary for us to add this here. For other devices like the Windows phone obviously providing interactive control would solve the problem. It is covered there. It would apply. In addition we do have to solve the problem of the keyboard interface because WCAG is so keyboard focused.
Kathy: we can come back and say that we don't feel it's necessary and then let the WCAG working group decide. But if it is added I think we need to use the language that we have been working on.
Andrew: I think it was Katie, I
think David might've been another person. Two different ways,
focus on techniques and not muddy the waters, or make sure to
remind people what's important. If the mobile group feels that
it's muddying the waters then you should say so, and can
indicate that back for the WCAG group to discuss. Similarly if
you don't think so or if that's not a decision the...
... working group makes, you can make an action such that when
you come up with different keyboard language the WCAG group
could commit to remain in sync with that in places where that's
mentioned.
Kathy: I think that's a good way to approach it..
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G9
<Kathy> http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G9.html
Kathy: G9 we have discussed this
a couple of times. We have added can be accessed on a mobile
device, video and audio
... any other comments on those changes?
<Kathy> https://www.w3.org/2002/09/wbs/66524/20140916_survey/results
Jon: I agree with everything I'm good with it. As far as being alive, the content document talks about live presentations so I'm glad we are adding an example. This is a good update, modernizing the technique.
Andrew: is this a live webinar and you are viewing it on a mobile device, or are you sitting in the room and getting the captions on the fly
Jan: live event in the room
Andrew: is there a way to clarify that further
Jon: in the latter example, if I'm in the room and a PowerPoint at the same time?
Jan: no because it's not like
coming across the web
... it's not media if you are watching the person in this stage
in front of you
... to clarify this is a webinar of a live event and you are
seeing the person's live video stream
<Detlev> sounds fine
<AWK> A live conference is streaming video with audio for remote participants using Communication Access Real-Time Translation (CART) to provide users who are Deaf or hard of hearing with speech to text translation services that can be accessed on a mobile device (this also helps on-site participants needing captioning)
Jeanne: why not just say a webinar? It seems more immediate – everyone understands what a webinar is
Andrew: trying to help people understand that it's a challenge. But I understand, the biggest concern is if people read this and think it's for a live event, someone will point out that that stuff is not live content and so you don't need to meet WCAC with it
Kathy: any objections to not saying live conference and just saying webinar?
Jeanne: after remote participants put in parentheses webinar and that covers both
<Kathy> A live conference is streaming video with audio for remote participants (webinar) using Communication Access Real-Time Translation (CART) to provide users who are Deaf or hard of hearing with speech to text translation services that can be accessed on a mobile device (this also helps on-site participants needing captioning).
Kathy: any objections to this text?
<Detlev> +1
Kathy: a live conference and a webinar for remote participants is streaming…
Jan: a live conference streaming an audio video webinar for remote participants
<Kathy> A live conference is streaming audio video webinar for remote participants using Communication Access Real-Time Translation (CART) to provide users who are Deaf or hard of hearing with speech to text translation services that can be accessed on a mobile device (this also helps on-site participants needing captioning).
Kathy: any objections to accepting this as amended?
<Jan> A live conference is streaming audio-video webinar for remote participants using Communication Access Real-Time Translation (CART) to provide users who are Deaf or hard of hearing with speech to text translation services that can be accessed on a mobile device (this also helps on-site participants needing captioning).
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G202
G202
<Kathy> http://www.w3.org/TR/WCAG20-TECHS/G202.html
Kathy: we've gone back and forth
on this in terms of keyboard interface in the language that
were using. Instead of the keyboard emulator we change that to
keyboard interface. This one gets really into what we are doing
as far as adding definitions for the keyboard interface to
clarify this and using keyboard interface as the term we are
using because that is actually defined already within
WCAG
... anything further changed or does anyone think this needs
further discussion?
<Jan> Check that all functionality can be accessed using only the keyboard or keyboard interface, such as via an onscreen keyboard controllable by external switches.
Kathy: any objections?
no objections heard
<Kathy> https://www.w3.org/2002/09/wbs/66524/20140929_survey/
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G21
G21
<Kathy> http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G21.html
Kathy: this is about ensuring that users are not trapped within content
<Kathy> https://www.w3.org/2002/09/wbs/66524/20140929_survey/results
<Detlev> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G21
Detlev: I thought it worthwhile to make it more general by mentioning tab key, arrow key, swiping for focus
<Kathy> Ensuring that the keyboard function for advancing focus within content in a device-supported way (e.g., the tab key, arrow key or swiping gestures) exits the subset of the content after it reaches the final navigation location.
<Kathy> Ensuring that the keyboard function for advancing focus within content in a device-supported way (e.g. via the tab key, arrow key or swiping gestures) exits the subset of the content after it reaches the final navigation location.
Kathy: any objections?
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G78
no objections heard
Kathy: we will accept this one is amended
Detlev: Sentence hard to understand. It may need some rewording to make it easier to understand
Kathy: suggestions?
... could send this to the working group and see what they
say
Detlev: I like examples that show it, but this might not be the place for that. If they want to reword it to make it clearer I would be good with that.
Kathy: objections to sending with note about clarifying
G85
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G85
Jon: if it's not in the test, it's not a requirement
Jan: makes it sound like the
author is on the hook to provide the sounds, vibrations. But
actually it's much better to have something in the markup, and
then the user agent decides how to get across in error
... also the was mention of HTML5 examples and that didn't
happen
Kathy: I was leaving that up to the HTML5 task force
Detlev: it's quite difficult to
grasp what the different methods of providing error handling –
how they would interact. The classic scenario is just
client-side check and behind that service side checks, but now
you have HTML 5 built in.
... in many cases it's an either or, either something at the
top, or on-the-fly pop-ups. so it often seems to be either or
ways of dealing with missing or erroneous input
Kathy: at another example. It's
got a number of examples, one we added.
... second paragraph of description at the end – what if we
just took out authors are advised…
<jon_avila> I have jump off the call.
Kathy: I'll put this one back on the survey and send it back out
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 WARNING: Replacing list of attendees. Old list: Kim_Patch Kathy_Wahlbin Jeanne Andrew_Kirkpatrick Detlev [IPcaller] New list: Kim_Patch Kathy_Wahlbin Jeanne Andrew_Kirkpatrick Detlev Brent_Shiver Jan Jon Default Present: Kim_Patch, Kathy_Wahlbin, Jeanne, Andrew_Kirkpatrick, Detlev, Brent_Shiver, Jan, Jon Present: Kim_Patch Kathy_Wahlbin Jeanne Andrew_Kirkpatrick Detlev Brent_Shiver Jan Jon Regrets: Alan Agenda: http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2014Sep/0016.html Found Date: 02 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/02-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]