Meeting Minutes - March 14, 2014

http://www.w3.org/2014/03/14-mobile-a11y-minutes.html 
<http://www.w3.org/2014/03/14-mobile-a11y-minutes.html>

*Mobile Accessibility Task Force Teleconference***


    14 Mar 2014

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

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


    Attendees

Present
    Kim_Patch, Kathy_Wahlbin, Alan_Smith, jon_avila, David_Todd, Jeanne
Regrets
    Jan, Gavin, Kathleen
Chair
    Kathy Wahlbin
Scribe
    Kim


    Contents

  * Topics <http://www.w3.org/2014/03/14-mobile-a11y-minutes.html#agenda>
     1. Keyboard Access & Mobile
        <http://www.w3.org/2014/03/14-mobile-a11y-minutes.html#item01>
     2. Next Steps
        <http://www.w3.org/2014/03/14-mobile-a11y-minutes.html#item02>
  * Summary of Action Items
    <http://www.w3.org/2014/03/14-mobile-a11y-minutes.html#ActionSummary>

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

<trackbot> Date: 14 March 2014

<Kathy> meeting: Mobile A11Y TF

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


      Keyboard Access & Mobile

<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


      Next Steps

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


    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-03-14 14:42:15 $

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