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

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.

<jeanne> Kathy: I am starting to use speech input more myself, and I have experienced many of the problems that Kim has. There isn't enough information out for people.

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

Kathy: I'm also feeling a lot of what Kim is talking about

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/that I want to turn up the heat on the browsers./ that./
Succeeded: s/that's going to hold their feet to the fire/that will have the browsers and OS vendors take responsibility for making their products more accessible./
Succeeded: s/don't need WCAG/don't meet WCAG/
Succeeded: s/ we've tried to get them into the group for years, the answers that I've heard under the table is they are afraid of regulation so they don't want to be part of the group so they can say that they weren't part of the group – that's part of the strategy. / we've tried to get them into the group for years./
No ScribeNick specified.  Guessing ScribeNick: Kim
Inferring Scribes: Kim
Present: Kathy Kim Jon_avila marcjohlic
Regrets: Alan Jan Henny
Found Date: 20 Aug 2015
Guessing minutes URL: http://www.w3.org/2015/08/20-mobile-a11y-minutes.html
People with action items: