MATF Minutes 3 September, 2015

MATF Minutes 3 September, 2015 link:
http://www.w3.org/2015/09/03-mobile-a11y-minutes.html

Text of minutes:


  Mobile Accessibility Task Force Teleconference


    03 Sep 2015

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


    Attendees

Present
    Kathy, jeanne, David_MacDonald, jon_avila, Henny, Alan, Jan, Detlev
Regrets
    Henny
Chair
    Kimberly_Patch
Scribe
    jeanne, kim


    Contents

  * Topics <http://www.w3.org/2015/09/03-mobile-a11y-minutes.html#agenda>
     1. questions on techniques and progress
        <http://www.w3.org/2015/09/03-mobile-a11y-minutes.html#item01>
     2. discussion of David's Success Criteria
        http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal_Discussion.html
        <http://www.w3.org/2015/09/03-mobile-a11y-minutes.html#item02>
  * Summary of Action Items
    <http://www.w3.org/2015/09/03-mobile-a11y-minutes.html#ActionSummary>

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

<trackbot> Date: 03 September 2015

<Kim> trackbot, start meeting

<trackbot> Meeting: Mobile Accessibility Task Force Teleconference

<trackbot> Date: 03 September 2015

<David> test

<Alan_> +present

<Kim> Kathy: focusing on touch the last few weeks. Started on wiki, 
David went through our success document. If we're going to do an 
extension or have other techniques we were looking at defining what the 
success criteria would be. Things important for mobile or a touch 
interface. We've had the conversation -- it's not just about mobile but 
about ways of interacting

<Kim> Kathy: looking at that and say what's important, what's needed, 
how does that work with keyboard access in shortcuts or gestures and 
shortcuts and having a big discussion around that

<Kathy> 
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Touch_Accessibility_(Guideline_2.5) 
<http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Touch_Accessibility_%28Guideline_2.5%29>


      questions on techniques and progress

<Kathy> http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal.html

<Kathy> 
http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal_Discussion.html


      discussion of David's Success Criteria
      http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal_Discussion.html

<Kim> Kathy: David overview

<Kim> David: it's all pointing now to github

<David> http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal.html

<Kim> David: first proposal, reworked it

<Kim> David: second one is I pulled out all proposed criteria, combed 
through discussion to try to put everything all in one place so we can 
see what everyone is saying

<David> 
http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal_Discussion.html

<Kim> +present

<Kim> David: guidelines, comments about what people are saying about 
them, and at bottom an understanding document -- those things would be 
linked to the corresponding success criteria. That's where it is right now

<Kim> Kathy: this is really great, appreciate getting all comments in there

<Kim> Kathy: biggest discussion all elements available by touch

<Kim> David: a lot of strong opinions around this

<Kim> David: that's separate from getting an overview of how stuff is 
laid out

<Kim> Kathy: a good topic for today touch accessibility in general. 
David thanks for all your work on that. Any general questions about what 
we've done to date before we get into a conversation more about touch

<Kim> Jeanne: quick question for David -- what did you copy over to form 
the proposal, first public working draft or editor's draft?

<Kim> David: link from the website, first link that was on the page for 
mobile

<Kim> Jeanne: that's the TR document -- that doesn't have all the work 
we did this spring and the follow-up we did for comments on the first 
public working draft. I'd like to suggest that we continue the 
discussion, the discussion is great, and thanks for all the work to get 
something in writing and getting the discussion going but not to 
consider that discussion proposal as any kind of document --...

<Kim> ...it doesn't have the work from the spring and it doesn't have 
the right code so it needs to be done over, which is fine, but as we are 
doing stuff in Github we can't think about this proposal as the document 
going forward

<Kim> Jeanne: we need to create document going forward. Before we start 
stripping out things and putting it into an understanding document we 
need to think about what we want to do.

<Kim> Kathy: as far as the understanding document, should we follow what 
what WCAG is currently doing

<Kim> Jeanne: it makes sense for WCAG because it's a large document, but 
what we are doing is a small document, going off to different document 
might not be as usable. It's fairly easy to split things off, but it's 
harder to put them back together again if that's what we decide back to do

<Kim> Jeanne: Patrick has raised some points about whether or not we 
should be doing extensions, a new version of WCAG things like that -- I 
don't want us to get caught up and that too much. There's a lot in flux

<Kim> Kathy: what I'd like to talk about today is touch accessibility -- 
there's been lively discussion. Have people been able to read through 
what David has done -- nice summary at the bottom

<jon_avila> * I've read most of it

<Kathy> 
http://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal_Discussion.html

<Kim> Kathy: we will take a couple minutes to read through

<Kim> Kathy: we are talking about the first one, 2.5

<Kim> David: summary at bottom

<Kim> David: I created a general guideline -- all functionality by 
touch. Gregg rather put in WCAG, Patrick wants to talk about all touch 
events, Jonathan is on the call I'll let him speak for himself. 
generally Jon and I were in the same camp -- want to see something 
happen for touch in new success criteria.

<Kim> David: I think it would be very difficult to require all 
functionality to work with touch. Three reasons. It may not be possible. 
There may be settings that can only be done on the keyboard for an 
administrator or something like that. I think what we are really trying 
to say is anything that is touch responsive ought to be available for 
anybody using assistive technology. So I reworded guideline

<Kim> David: some discussion underneath that. I think the uptake of that 
is we have to have a serious conversation -- Jeannne touched on earlier 
-- do we want to act as an extension or try to roll it into WCAG

<Kim> David: the way I'm reading it is if we are trying to create some 
advice, advantage is all the jurisdictions that follow WCAG would be 
required to follow, disadvantage is some connections would be contrived

<Kim> David: that's a summary of the first part -- touch accessibility. 
Underneath that there are five success criteria. I'll stop here

<Kim> Jon: the aspect of this that were dealing with is some things in 
my opinion are broken in the mobile environment particularly IOS but 
also android -- we're trying to bridge that gap -- what needs to be 
accessible -- terminology seems to be a problem tap, touch what does it 
mean. We have to figure that part out in order to proceed

<Kim> Kathy: from reading Gregg he was saying that the keyboard 
interface does include touch and anything else, speech, but I think most 
people who read this think of keyboard interface as physical keyboard -- 
I think that your point Jon

<Kim> Jon: and beyond that it's misleading, you can't use voice on iOS 
to do all those things you can with the keyboard interface, you can't 
use touch with voiceover -- it's broken

<Kim> Jon: keyboard interface, it's meant to go further. Demonstration 
of issues on iOS -- understand in detail actual problems better 
recommendation about how to go forward. Part of the problem is we 
haven't done a very good job of demonstrating where those gaps are

<Kim> David: long conversation about this with Gregg -- I think he got 
it. Example ever populating twitter type of thing, swipe down with one 
finger when voiceover off and it's fine but then voiceover on and do the 
equivalent of a swipe which is three fingers down and it's not -- none 
of that stuff works when you have voiceover on. Greg really gets that 
WCAG real-world problems of people with...

<Kim> ...disabilities

<jeanne> Hover is not well implemented on touch

<Kim> Detlev: not sure I understand that you can't make everything touch 
accessible. Browser-based. I don't get the example I think that David's 
example with some keyword that has to be put in so there you would have 
a virtual keyboard displayed on your mobile device and you could use 
touch to activate things via the virtual keyboard. I'm still not quite 
sure that I get the point that it may...

<Kim> ...not be possible to provide everything by touch. So that's one 
thing. The other is for the inverse case keyboard accessibility there 
are cases where certain things are not keyboard accessible and where we 
have ways of meeting the success criteria anyway by providing 
alternative means of inputting -- for example drag-and-drop an 
equivalent implemented operable in other ways

<Kim> Detlev: so there are parts that don't meet WCAG, but alternative 
way. If we include button presses, things like the home button on 
devices which are also tactile, if we include those iis there anything 
that's impossible to do by touch

<Kim> Jan: entering name -- blackberry phones that have a physical 
keyboard need physical keyboard

<Kim> Detlev: amend that rule by touch or physical keys on the device -- 
just not attached keyboard

<Kim> Jan: problem is app developer doesn't know whether company will 
come out with something that is just little screen and keyboard

<Kim> Jan: if we exclude the text entry case I think almost everything 
else could be covered

<Kim> Jan: somebody said Gregg's interpretation is that keyboard 
interface covers touch interaction -- is that right?

<Kim> David: maybe we should get him on the call

<Kim> Jan: if it is so wide maybe it shouldn't be called keyboard

<David_> hmmm my mike is no working?

<Kim> Kathy: that's Jonathan's point, everything should be available by 
touch on keyboard but it's broken

<David_> talking... will dial in

<Kim> call dropped -- can someone else scribe for a minute

<Kim> Henny: flexible content order

<Kim> Jeanne: examples of touch not accessible -- have they solved the 
hover problem -- a lot of fly out menus used to be done, other examples 
and JavaScript for right-click, which isn't accessible anyway but I'm 
trying to think of places where touch doesn't work

<Kim> Kathy: we recently did an audit on a website, not application 
based. Issues with touch and CSS interaction. after using touch kind of 
locked the screen. Touch is blocking lots of things -- combination of 
what they had done in the code. There are a lot of issues right now with 
Touch depending on how you had coded things

<jeanne> scribe: jeanne

Kim: I keep coming back to the idea, that touch is a kind of mouse, is 
touch an everything-equivalent? Or is touch a mouse-equivalent.
... Google just came out with new keyboard equivalents. Keyboard is 
moving into the mobile space.
... we dont' want to perpetuate the mouse/keyboard problems in mobile as 
a touch/keyboard
... I want voice input, but there is no speech interface in mobile, it 
is all based on the keyboard.
... we have to look at the keyboard connects with touch on mobile as it 
is different with the way mouse connects to keyboard on the desktop

Jan: The mouse has an inactive state, but touch is always active.
... for now. The Samsung stylus now sees where you are hovering.

Kim: There is something missing on the phone, and something missing on 
the desktop.
... things are crashing together. I haven't finalized my thoughts, if we 
say that touch is available, what do we do when air gestures come along? 
And the next thing? I think we need to tie everything back to the keyboard.
... Users who are blind can use touch and keyboard. Speech users can 
only use keyboard. This diverges from the desktop situation where blind 
users could only use keyboard.
... it might not seem as important for blind users to have everything be 
keyboard accessible, but like the desktop, speech users can only use the 
keyboard.
... the use cases are different in large ways.
... The user should be able to control how they intereact with the 
device, and the user should be able to use any mix of input methods. I 
don't know if this is possible. It gets tricky when things are mixed.
... saying everything should be available by touch causes problems

David: WCAG says it has to work with keyboard. So we have this. The 
blind community are using touch, and some touch is working, and some is not.
... blind people use the screen and can operate the screen. We need to 
make sure things don't break.
... the user agent developers need to fix things on their end.
... but the authors need to fix things too
... WCAG only applies to things that disproportionally concern people 
with disabilitites
... we need to address that VoiceOver breaks touch

Kim: Can we need to go wider, that when there is a mix of input methods, 
they need to work together?
... If someone has a keyboard plugged in, when you are using speech, 
touch is @@

David: I think that is a separate success criteria

Kim: It's a wider principle, that one input method should not break 
another method.

David: I think it is separate issue, like non-interference in WCAG.

<Kim> Jon: the one thing that really bothers me about the keyboard 
interface is there's no good way of knowing what actions are available

<scribe> scribe: kim

<Zakim> Kim, you wanted to talk about touch and mouse and speech

Jon: what I like about IndieUI is it's independent -- keyboard access 
ties back to customizable part but being able to explore what are my 
available options kkeyword is not very useful
... I agree with Kim we do need overall to cover this -- we do need 
certain things with touch but we want to go beyond this. Certain things 
dealing with small screens and people with disabilities -- we want to 
have guidelines that go beyond WCAG that deal with some of these issues

Kathy: great conversation -- think about where we need to go with this. 
If all of you could take a look and read through the touch accessibility 
discussion we can continue this next week. We have been in parallel 
working on the techniques as well. Plan to revisit techniques as well do 
that work in parallel. I think as we work on the guideline we will come 
up with other techniques
... need a volunteer to put these subdocuments on Github

Jeanne: if you can volunteer send an email to Kathy, Kim and I and we 
can start talking about the requirements
... I would also encourage people to follow discussions about extensions 
that are occurring in various places right now
... I would encourage people to keep talking about the bigger issue of 
should this be an extension or should this be under WCAG

<Henny> I have to drop off the call. Apologies.

Jeanne: zoom more than 200%...

David: maybe A, AA

Jon: the other issue with extension is people feel people would think 
it's optional
... no matter what requirements will be out of sync with the current 
standards

Jeanne: some of the key settlements of court cases recent big one even 
required our document -- mention specifically the mobile accessibility 
task force note. So what we get on paper is going to have an impact

Alan: we can talk is long as we want, but what's the legal opinion how 
does the government want 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.140 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2015/09/03 16:22:22 $

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