Mobile Accessibility Task Force Teleconference -- 03 Sep 2015

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

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

- DRAFT -

Mobile Accessibility Task Force Teleconference

03 Sep 2015

Attendees

Contents

questions on techniques and progress

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

Summary of Action Items

Scribe.perl diagnostic output