MATF Minutes 20 August, 2015

MATF Minutes 20 August, 2015 link: 
http://www.w3.org/2015/08/20-mobile-a11y-minutes.html

Text of minutes:


  Mobile Accessibility Task Force Teleconference


    20 Aug 2015

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


    Attendees

Present
    Kathy, Kim, Jon_avila, marcjohlic
Regrets
    Alan, Jan, Henny
Chair
    Kathleen_Wahlbin
Scribe
    Kim


    Contents

  * Topics <http://www.w3.org/2015/08/20-mobile-a11y-minutes.html#agenda>
     1. questions on techniques and progress
        <http://www.w3.org/2015/08/20-mobile-a11y-minutes.html#item01>
  * Summary of Action Items
    <http://www.w3.org/2015/08/20-mobile-a11y-minutes.html#ActionSummary>

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

<trackbot> Date: 20 August 2015

Kathy: discussion on mailing list around the new success criteria -- 
talk more about that and see if we can flesh out some of the techniques 
that would go under their and talk about specifically the first one
... before that talk briefly about the technique development assignments 
to see how people are going on those, any questions, if things are ready 
on your end to get review


      questions on techniques and progress

<jon_avila> * we can't hear you david

<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>

Kathy: we have a small group today but I thought we could start looking 
at this wiki page that we put together an touch accessibility and this 
is based on the email thread that was going around. I put in the couple 
techniques that we had.. I figured we could work on this list. first one 
all operable through keyboard -- list material

Here's the email thread:

https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Jul/thread.html

Kathy: Jon I agree it doesn't go far enough -- if manufacturers change 
something when we still require touch, something to think about when 
were looking at this
... also wanted to talk about the whole idea of gestures being the same 
as keyboard

David: try to recap the conversation that was online -- I was trying to 
articulate this whole issue of the flatscreen blind people use flat 
screens let's run with it let's make it work for them let's not fall 
back to a reliance on keyboards. John wanted to make sure that it really 
would be a mobile solution -- don't have to sit down and pull out 
Bluetooth keyboard, can do it standing up
... I was confused by some of Patrick's comments -- sounds like he has 
more experience than some of us in terms of programming so I'm very 
interested in what he has to say, but I was confused by the statement 
that you can't require touch to work while you are using a voiceover 
because if somebody has custom gestures are going to be overridden and 
the gesture is not going to work anymore...
... and there's nothing you can do about that
... we may need more research into this -- my experience with just 
seeing blind people use this -- I don't want us to drop the ball on 
this. It's a very dynamic conversation and I think it's a fruitful one

Jon: I thought Patrick was generally agreeing with us -- even going 
further to say that Safari without a screen reader key events don't work 
very well. This is evidenced by things like aria controls not even 
working with a keyboard on iOS -- works on desktop browser, but IOS up 
and down arrow keys just aren't being sent
... he was saying VoiceOver doesn't send up and down arrows at all so 
there's no way to communicate that
... my frustration is there may be some people on the list who assume 
that mobile applications work the same as desktop
... good points but it's not relevant to this environment because it is 
broken in this environment in my opinion. Because it's broken fix it or 
somehow word something to require access but we have to be careful in 
the wording. Maybe touch is actually how it works but maybe that's not 
the right wording. Clearly keyboard interface isn't the right wording 
either not only is it misleading but...
... it doesn't work right on mobile platforms.
... originally I was thinking other language like alternative input or 
APIs or some other wording. People don't seem to like that, saying we 
have keyboard interface that covers that. I don't know what direction we 
should go. In order to come up with the wording that we need to involve 
the people who will be blockers now in order for this to be worth our time

David: I didn't feel that there was blocking from anyone at least in 
this thread

Jon: I get the impression from one commentor that we didn't need this 
because keyboard interface is already in WCAG

David: I think there's more to do in the mobile environment -- 
resoundingly. It's not unlikely situation we had in the early days of 
WCAG. Hope they will fix keyboard access -- once they fix it then the 
mechanism is available

Kathy: so if a mechanism is available and that mechanism is keyboard 
than would we be saying that they wouldn't have to do touch?

David: I'm not saying that yet

Kathy: it's an interesting argument -- under WCAG we don't require mouse 
access

David: no complaints about that

Jeanne: we are a joint working task force with WCAG. flip this. The 
broken keyboard access is a browser problem -- some of it an operating 
system problem, not for the authors to fix. We need to be putting 
pressure on these companies to fix this. My suggestion is we write a use 
case for how this is broken and what the browsers need to do to fix it. 
And let's start a separate document which we...
... can cross reference -- separate wiki page for now. Put this on as a 
browser operating system problem that must be fixed by them, and not try 
to force authors to fix it
... as much as I love WCAG, what WCAG has done is by making it the 
author responsibility, take the pressure off the browser/operating system

Jon: from an end-user standpoint I feel like they would just have to sit 
and wait until those manufacturers decide to fix it and I just don't -- 
there are people who have regulations in place now have to meet 
requirements now and they need guidance and I think we have to provide 
them guidance on how to do that -- maybe things that are best practices 
rather than requirements. We should still...
... put together the techniques whether they are requirements are not

<jeanne> +1 for Techniques to address it, -1 for success criteria to 
require it.

Jon: we did bring up some of the keyboard access to Firefox, Marco -- 
was pushing back, don't see it is their problem.

Kathy: one question for Jeanne -- if we did in a perfect world get the 
browsers and the manufacturers Apple, Google to fix the platform so we 
had keyboard access you would think that touch isn't required?

Jeanne: I do think touch should be required but we shouldn't be 
wordsmithing assuming browsers don't have to fix
... project in UAAG last year -- browsers by default with no CSS added 
don't need WCAG for contrast, some for resizing, checkboxes, there are a 
number of places where they don't meet WCAG and they don't have to 
because WCAG require authors. I don't want to do anything in this group 
that perpetuates that.
... it's important for us to keep looking at that bigger picture of 
holding the browser's feet to the fire and not having it just be about 
WCAG and remembering that we are joint task force and we have 
responsibility to say to the browsers this is what you should be doing
... browsers want use cases -- we need to start writing use cases down 
and making that a public document as well. In the long-term I agree with 
Jonathan that short-term people need a way to work around the browser 
problems, but in the long term we still need something that will have 
the browsers and OS vendors take responsibility for making their 
products more accessible.

Kathy: I think it's important. I think we can create a wiki page to at 
least start documenting this.

Jon: tying this to another thread the department of justice is making 
UAAG 1 and WCAG 2 part of settlement. Is important. Vendors aren't part 
of the group and because they weren't part of the group appeared we were 
putting resources there -- since they weren't part of this maybe it 
would be better to use resources elsewhere

<Kathy> Here is a WIKI page that we can use to document the use cases: 
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Keyboard_Accessibility_Use_Cases

Jeanne: we've tried to get them into the group for years.They said no 
one is implementing UAAG. That is not true we had two implementations 
for every success criteria.
... one of the browsers has been steadily implementing UAAG

Jon: they are interested in doing more, but can only use documents not 
drafts,
... maybe work more with Department of Justice and access board -- more 
buy-in would help. We are stuck in these situations where in order to 
apply this to mobile, going to have to look at multiple documents and 
try to figure out are they complying, are they doing what they need to 
do to provide access. People really do need this guidance. We see other 
organizations putting things out...
... because it's taken so long.
... now we have a situation where we might have conflicting guidelines. 
It would be just be great if we had a standard -- if it wasn't so 
fragmented.

Jeanne: that's the hope of the new combined guidance group for next year

David: can we start to write as an adjunct, an extension

Kathy: the accessibility guidelines and mapping that like we did with 
the BBC stuff?

David: we have numbers on everything but I think if we rewrite them in 
the WCAG of success criterion it's the same style -- it's a very messy 
process but what Detlev is a great start

Jeanne: it is set up so it will be easy to roll into success criteria

David: I haven't heard any discussion of anything going forward in at 
least five years of changing the whole style of success criteria -- 
principles guidelines success criteria

Kim: do think it is broken at the operating system/browser level, and 
developers need more sense of users

Jon: touch may be limiting, what if you could use back button, as long 
as there is another way

<jeanne> Kim: I am a speech user who uses the keyboard by speaking. YOu 
are literally using the keyboard commands, but do not have a physical 
keyboard attached

<jeanne> Kim, if everything were anchored to the keyboard, I would have 
access to the phone. Right now, I can speak into the phone, and if it 
gets something wrong, I can't correct it by speech. I have no keyboard 
access except by speaking the words. If the speech engine gets something 
wrong, I can't fix it by speech. Keyboard access lets me jump back by 
arrow or by word.

<jeanne> ... I want to see it anchored to a keyboard, so what I can use 
on the PC, I can use on the phone.

<jeanne> Jon: I bring up the physical keyboard, because that is what 
people see as the solution. Because you can attach a physical keyboard, 
they feel they meet the requirement.

<jeanne> ... the Technique tests always say to attach a keyboard.

<jeanne> Kim: It's important for a speech user to be able to open a new 
program where you don't know the custom commands. In a practical sense, 
speech needs full keyboard access

<jeanne> Jon: If a form field is properly labeled, and you can see the 
visual label, that provides a better experience.

<jeanne> Kim: Consistency is extremely important. If some forms work 
correctly and others don't. You have a mess. You can set up custom 
commands that work across programs.

<jeanne> ... speech users will use things in different ways, having a 
work around that works for everything is really important.

<jeanne> Jon: Does that mean that you think that ARIA labeling is wrong?

<jeanne> Kim: No, that doesn't solve the problem.

<jeanne> ... what I see the problem is people solving the problem in 
different ways, that makes the experience inconsistent.

<jeanne> Jon: Screen reader users -- beyond the keyboard support that 
already is there -- the page could be accessible without ARIA landmarks, 
but landmarks enhance the experience.

<jeanne> Kim: it is important that speech users have keyboard access, 
and to have the ability to customize keyboard shortcuts.

<jeanne> ... If I accidently say the wrong thing in Gmail, it can 
execute single key shortcuts that changes my mail and I don't know what 
was done.

<jeanne> ... it is a big deal to memorize speech commands -- harder than 
memorizing keyboard shortcuts.


    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/08/20 15:56:40 $