<Kathy> trackbot, start meeting

<trackbot> Meeting: Mobile Accessibility Task Force Teleconference

<trackbot> Date: 07 July 2016

Kathy: We are going to briefly discuss what we can change, then end call early
... we can't change the SC, but we can change the definition or the understanding
... start thinking about two-stage approach. Can we change definition under 2.1 now without changing the success criteria language, or do we need something patched in now and go down that direction for 3.0
... that's what we need to look at overall for 2.1 and 3.0

Patrick: interchange with Greg and link – my whole point initially was a wanted to get this discussed within our task force first so we can iron out some of these things before. Uphill struggle to get folks to understand

Kathy: we might want to just bring this overall to the working group regardless but I think we should have several different options. I posed the question – they said we could change the definition but the success criteria couldn't change until 3.0

Patrick: that's a very limiting approach particularly because the change I propose doesn't go against what it currently says – not that things that were not accessible in 2.0 will now become accessible but rather the opposite that certain approaches that were valid under 2.0 but don't work for touch – so making it harder to satisfy amended criteria. But I get the point that if we are...
... taking...
... the current language as being immutable we could probably look at redefining what keyboard interface actually means though it will in my view make it look more awkward, particularly in the light of WCAG already being criticized for using obscure language. It can be done we can say keyboard interface actually includes. It just adds a layer of indirection which may not be completely...
... obvious. We can add to understanding to stress that point. On the very first reading it will always still look like why is touch with AT a keyboard interface

Kathy: I think overall we need to bring this to the working group. So we'll have a discussion in the task force and probably that will happen next week, because not very many people on the call right now. If you can look at the definition and see if you can change the definition by keeping the success criteria language the way it is and see if we could go in – timeline is so short we...
... have to have all this wrapped up we can't spend too much time going back and forth. If we have multiple options for the working group and we can get them to tell us what we can and can't do and just move forward and get things defined within the limits their setting for us…

Patrick: I agree with that. I will take a look at last comments and see if there's a way I can salvage the work that I put in this – change definition etc. the main point that needs to be addressed is basically touch +AT. It uses gestures but it's the ATthat interprets them.Then we can move onto as an author if you do your own gesture detection, how to make sure that still works for...
... users that are using touch interface but might have mobility issues, not necessarily touch +AT but broad touch itself. And then the advanced touch which is using stylus that also has tilt and rotation and everything else – the fancy touch that we talked about..
... once we've sorted the touch plus AT scenario we can move on other input modalities that arise from having touch and stylus…

Kathy: encourage everyone to read through the thread. We'll discuss next week

David: the idea of expanding it doesn't bother me. My only concern is it seems to me that it can be construed that the keyboard requirements are less that so another words every test that I do over the last eight years but still have to be done, and that would still fail people on keyboard accessibility. I love the idea of unifying and expanding, as long as we don't lose what we've had in...
... terms of functional understanding of keyboard accessibility

Patrick: everything that previously failed would still fail. But not everything that passed previously would still pass. Things such as if you used keyboard specific input handlers such as onkeypress or onkeydown, it would pass under 2.0 it would not pass in the stricter definition – so it is actually a strengthening in my eyes of this particular requirement. Maybe too much the opposite...
... way perhaps.

David: I know this is a problem with iOS but technically mobile will not pass if it can be keyboard operated. I guess as long as we're not losing that in the wording reflects that. User who may be able to help us, lawyer who went blind, government regulation. Language that isn't too broad or too narrow

Patrick: duplicate a lot of language – compromise, though. 3.0 unify the idea
... option one, option two let's tweak it slightly, option three let's duplicate it, but that's not our preferred position. We can send and say this will be our preferred, least preferred but we can live with and see how it goes
... I think we can get somewhere with this – an agreement that the thinking behind it is fine now it's just finding the right form for everyone. I think we can get somewhere anyway. I'll keep working on that this week. May have additional thoughts and ideas by the next call, will put in the wiki