See also: IRC log
<trackbot> Date: 14 March 2014
<Kathy> meeting: Mobile A11Y TF
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
<Kathy> http://www.w3.org/TR/2013/WD-UAAG20-20131107/#intro-modality-independence
<Kathy> Kim: UAAG came up with this note
<Kathy> Note: Users interacting with a web browser may do so using one or more input methods including keyboard, mouse, speech, touch, and gesture. It's critical that each user be free to use whatever input method or combination of methods works best for a given situation. If every potential user task is made accessible via modality independent controls that any input technology can access, a user
<Kathy> can use what works best. For instance, if a user can't use or doesn't have access to a mouse, but can use and access a keyboard, the keyboard can call a modality independent control to activate an OnMouseOver event. See Independent User Interface: Events for additional information on APIs and techniques for modality independent controls.
<Kathy> Kim: UAAG is now discussing this as they have had comments about touch
<Kathy> http://www.w3.org/TR/indie-ui-events/
<Kathy> scribe: Kim
Jon: need notes under understanding
Kathy: we can't change success criteria, we can change understanding, we can add a definition. The success criteria is always going to reference keyboard. Given that do we define what we mean by keyboard which is what was done by UAAG, or modify all
Jon: also confusion between keyboard and on-screen keyboard
Kathy: on a mobile device on-screen keyboard, Bluetooth keyboard, switch devices, touch and gestures
Jon: voice activation
Kathy: camera for tracking head movement
Jon: braille displays, braille input device. Android and iOS different.
iportal device power wheelchairs, but we don't want to get into those types of details
Kathy: accessibility support – what would that look like. All those different devices are dependent on the actual device and iOS is different from android, but how would we if we do that under accessibility support we would still have to address it somewhere in understanding, sufficient, failures
Jon: more general techniques
versus more specific techniques for platforms – I don't think
we're going to make everybody happy but if we could create some
specific techniques to decide how things could be done for a
particular platform I think it could be useful. It would be a
lot of work if we go too far that direction. But I would like
to see the techniques be mobile specific and if we can...
... more general
Kathy: example mobile specific for a platform
Jon: physical keyboard can only be used with input controls, but switch control, voiceover as an example. Also assistive touch, but clearly switch control and voiceover are looking at the programmatic aspects, switch allows it to be focused, voiceover allows it to be interacted with
Jeanne: in the past we've defined keyboard to include keyboard emulators, also general applicability note saying keyboard does not include just physical keyboard but also emulators – that's as far as we've gone
Jon: we don't want to force
people into a technology that's unrealistic. we don't want to
encourage that the only input is keyboard access. If I have an
app and it happens that it's not accessible to screen reader
users and screen reader users have to carry around an extra
keyboard to access it it seems like a fundamental change in how
it would have to be used – requiring someone to carry
an...
... external keyboard doesn't seem like an equivalent method of
access. Maybe we technically meet the requirements but I would
hate for people to have to go down that route.
... I could see that happening in android, where we have all
the keyboard shortcuts, but in order to use them you need a
keyboard
Kathy: with touch the default
that we want to make sure we had available – we look at what
the device comes with, a PC needs a keyboard. On a mobile
device you have to have the screen. You could have a keyboard
attached to it and not a touchscreen, but most of them have a
touchscreen, so how do we go about saying what is sufficient
for a particular technique
... touch if it's not available to a screen reader is not
equivalent, but what do we say to a developer – you have to
support this or is it as simple as an equivalent method for all
users, so if torch is available it's available both for screen
readers and not screen readers, but what about people with
mobility impairments who can't do touch
Jeanne: it's complicated. You do want to have a keyboard people who are deaf blind – that's how they communicate with a braille device
Alan: do we want to say the keyboard is also supported, not exclusive, but also supported. Gestures should also be supported by keyboard, but they don't have to have a keyboard, but if they do
Jon: if we do have the independent UI that would solve my concern
David: does anyone have a timeline for when browsers will implement indieUi, I'm concerned that it may not be implemented for two or three years down the road
Jeanne: there is not a timeline yet – that's not the way we've worked. I can say that I know that Apple is very active in in DUI right now so I would expect that as things are developed Apple is very involved, but I don't know if Google is or android
Kathy: I like the principle of indieUI and modality independent control, but I think we have to define what that means now in terms of control
Jeanne: this may be something we have to address and individual success criteria rather than having a broad statement
Jon: I don't think we saw this right now, keep thinking about it, maybe solicit input from other groups
Kathy: WCAG is interested in what
we are thinking about this as well. The bottom line is as we
are going through the different techniques and the
understanding document, making note of where we think we need
to address this and then we can pull all those items together
where this is an issue and try to figure out what we want to do
at that level
... at least make notes at this point and then have another
discussion as well
... still have some open topics, if we can have the majority of
them done by the end of the month then we can start going into
them. We'll start with the general techniques and then branch
out to the other techniques. If you have ones that have been
assigned that are done please try to get them done before the
end of the month that if you have additional bandwidth please
sign up for more
<AlanSmith> I can get my designated section reviewed/completed by end of month.
Kathy: BBC comparison – goal is to do a gap analysis so we can see new items that might be in there and maybe things that can be added to existing techniques. The purpose is to get a clear list of things leveraging the work that's been done by other groups and other people
Kathy: no meeting next week,
understanding documents and techniques will be the focus of the
next meeting
... good discussion on keyboard we will regroup again after we
have gone through the techniques and understanding documents.
We will summarize this on a wiki page so that we can go
back
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 Default Present: Kim_Patch, Kathy_Wahlbin, Alan_Smith, jon_avila, David_Todd, Jeanne Present: Kim_Patch Kathy_Wahlbin Alan_Smith jon_avila David_Todd Jeanne Regrets: Jan Gavin Kathleen Agenda: http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2014Mar/0011.html Found Date: 14 Mar 2014 Guessing minutes URL: http://www.w3.org/2014/03/14-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]