See also: IRC log
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_3.4.1
Kathy: David's comment – whether or not keyboard operability is already required in 2.1.1 so whether it's needed here. Jonathan agreed with that
<chriscm> Hey All. Internet struggles. Hopefully connected to the WebEx shortly.
Henny: What input
Kathy: have to discuss what
actually falls under device manipulation
... cross out and/or keyboard – that would mean that if they
were available by keyboard we're still requiring those to be by
touch because we've got rid of the or, but it does keep them
kind of separate from each other
... we could think about combining some of those in the
future
<jeanne> definition of device manipulation -> https://w3c.github.io/Mobile-A11y-Extension/#def-device-manipulation
Kathy: we can leave the and/or
keyboard in there for now and come back and revisit that.
... revisiting now…
Jon: ultimately if they were
available – we would say how they were performed – I have a
concern but not a suggestion
... maybe supplement 2.1.1
Kathy: we could do that for WCAG 3.0 not for 2.1. 2.1 we can only add success criteria guidelines or add techniques to existing success criteria. Can't change existing success criteria.
<davidmacdonald> i'm in late
<davidmacdonald> hi
<marcjohlic> And existing 2.1.1 Keyboard: https://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html
<davidmacdonald> getting my mike together... understand, but can't talk yet
(need to add "." at end of 2.6 link above, because it disappears when you click on it)
Jon: how is this different from
2.5?
... already have the criteria that says everything must be
available by touch
Kathy: maybe we need to add notes
under the touch – or we could have a failure that advice
manipulation gesture is the only way to accomplish a key task
under 2.5.1
... 2.5.1 saying everything needs to be available by touch
David: traveling on the road do not have access to the keyboard, it's a lot to ask keyboard and touch available – we might get pushback on it but I think it's worth bringing to group
Kathy: Key Point is 2.5.1 already requiring touch, and we already have success criteria requiring keyboard, so this is not needed at all
<Kathy> https://w3c.github.io/Mobile-A11y-Extension/touch.html
David: is it requiring everything by touch or requiring everything that is available by touch still available with accessibility
Kathy: referring back to touch and pointer – you could argue that device in a place in gesture isn't available via touch right now…
David: this is just requiring that once you turn on your assistive technology touch that was already there works. This doesn't require you to have a touch gesture for everything
Jon: I didn't realize we had left this out of 2.5 – I think everything should be available by touch
David: turn 2.5.1 into 2.5.2 and do new 2.5.1 everything required by touch
Kathy: have been requiring touch
or keyboard but not necessarily both
... I can see the arguments on both sides – everything needs to
be available by touch when touch is the primary way of
interaction
David: the way that we used to think about a desktop with a keyboard so everything is accessible by keyboard on a mobile device it really is touch
kathy: it's already everything by
keyboard, also adding everything by touch
... speech is another way of interacting with keyboard. That
was Henny's point earlier that we have to be considering speech
API
David: do we like the idea of
requiring touch in addition to keyboard
... the new 2.5..1 everything is available by touch. The new
2.5.2 everything available by touch is still available by touch
with AT
Jon: developer standpoint: I can create controls on the screen or keystrokes and that's the current requirement. But the keystrokes would require someone to have a keyboard. so I think I'm in favor because that breaks out a loophole requiring people to carry around a keyboard in order to operate the mobile device. Maybe doesn't go far enough with some of the issues for speech users …
Kathy: I like that. When we talked about this originally I thought that was the direction we were going to go and then we had. Trying to think back why we didn't do that to begin with. We did have conversations about this before
<jon_avila> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Touch_Accessibility_(Guideline_2.5)
Kathy: also feedback from WCAG working group – a fair bit so far, they have until next week to send it back.
Marc: through touch or keyboard?
<Detlev> sorry to be late - had computer trouble
David: what about about touch on mobile views
Kathy: touch on laptops etc.
David: touch only SC
Kathy: failure about device manipulation
David: failure it's only available by keyboard
Kathy: then were going to get
into what if a device is to have a touchscreen, or an
application is only meant for desktop through keyboard
interaction
... not everything has touchscreen
... nonverbal user can't use speech, doesn't have keyboard.
Keyboard alone, speech alone is not sufficient to go
through
Jeanne: example of a person who's using a tablet that's bolted to the wheelchair where the undo function is only available through shake. That person would not be able to undo things on their tablet. Touch user, don't have keyboard, but can't shake the device
<Zakim> jeanne, you wanted to give the example of the person with a tablet bolted to their wheelchair and cannot shake the device to undo.
Marc: rather than including almost writing in a way so you're not excluding the methods of input that are available on the device. You're not locking someone somehow into a shake gesture or you are not locking someone into only doing it on the keyboard. But is there a way to write a success criteria that would cover that or do we have to cover them all separately
Chris: iif you use onclick events in JavaScript those by default respond to etc. Others don't
<Henny> I have to drop off. School pick up.
Marc: yes exactly I don't know if there's a way to write that for devices just yet
Chris: and any wording that I can think of off the top of my head would be extremely device specific
Marc: I'm just a have a way to address all at once rather than have to address all specifically
Kathy: more of a 3.0 topic
because it goes into revisiting the whole keyword success
criteria
... I like the way that you're thinking – anticipate things in
the future but right now we have to stay within the existing
success criteria and add on to those
Chris: talkback trap – I think
the keyboard if you are thinking about the way WCAG exists
right now – if it works on the keyboard it's probably
reasonably accessible. Because each operating system variant if
it works on the keyboard that suggests that people are
following the correct programming practices etc. If we're
talking about a 2.1 extensionI believe the way to accomplish
what were...
... talking about his let's focus on the keyboard/touch and the
sequential navigation thing. And maybe in 3.0 we can be a
little more abstract and talk about it in the way that Marc is
wanting to
Kathy: are there scenarios right
now that if something is keyboard accessible it doesn't have a
touch equivalent
... I had one last night – skip link kept Kicking me out to the
URL bar. Keyboard accessible worked on the desktop, when you're
using touch doesn't work
... that gets into things that are with screenreader turned on.
This is going back to the point of where we were originally
with saying everything is available by touch. Think the
conversation went – what's not going to be available is
keyboard is available. Is there anything in touch that's not
going to be. I think there might be a few cases.
Chris: you might get 75,80% of the way there by focusing on the keyboard.
Kathy: we can have suggestions
for things to be included in 3.0 but were not working on that
right now
... everything available by touch is not necessarily out of
scope – question is is it needed
Kim: everything needs to be keyboard enabled, everything doesn't need to be device manipulation enabled, but touch is in the middle – question is do we need everything to be available by touch
Detlev: I can't think of anything right now which wouldn't be able to work by a virtual keyboard
David: are we solving a real
problem
... we could do a new success criteria that says everything is
available by touch but are we going to be solving a whole bunch
of people's problems if we do that – it's a huge burden on
developers. Is it more of a usability thing everybody is going
to be using touch so we shouldn't worry about it
Jon: we were focusing on device manipulation gestures – what are the equivalent for those with the keyboard. Assistive touch and Samsung but how would you do that with a native android
<Kathy> I guess the WebEx cuts off at noon
<chriscm> LOL, nice chatting with everyone I guess.... :)
<davidmacdonald> ooops, guess that topic is over :)
<Kathy> we will pick up the conversation next week
<Kathy> thanks everyone
<jon_avila> http://www.html5rocks.com/en/tutorials/device/orientation/
<Detlev> got kicked out by webex
<marcjohlic> :D
<davidmacdonald> So the big question is if we require everything to be available by touch, are we solving real barriers or should we tighten it up i.e., all non touch, non keyboard manipulation is available by touch
Kim: another question is is it easy to do – if there are use cases and it's just a matter of making sure there's a virtual keyboard for everything it may be not such a headache for developers
<davidmacdonald> I think that is where we should go.... "all device manipulation is available by touch" with a definition of manipulation already there.
<davidmacdonald> hope that's captured in minutes.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim Present: Kathy Kim Henny jeanne Marc David Jon Detlev Regrets: Alistair Patrick Alan Found Date: 26 May 2016 Guessing minutes URL: http://www.w3.org/2016/05/26-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]