Re: Device manipulation

How about, instead, changing/expanding the meaning of "keyboard" to also 
mean that things can be activated with two-step "set focus to it and 
then activate it" (something that I believe was discussed at some point, 
but not pinned down) in 2.1.1 (though I know we can't modify core WCAG 
2, but can we write this up as a note?)

Because then, 2.1.1 would cover all aspects of this device manipulation 
SC as well (so ANY functionality must be available using 
keyboard/sequential navigation - so anything that can be triggered by 
physical buttons, pressure touch, shaking of the device, pull to refresh 
gestures, etc must also be actionable this way)?

P



On 23/05/2016 17:20, David MacDonald wrote:
> It is clear under WCAG 2.1.1 that every function has to be keyboard
> enabled. I think however we may want to consider going further for the
> mobile requirement.
>
> Keyboard functionality is not fully implemented on iOS and users
> generally reserve keyboard to input of volumes of text rather than
> navigation.
> I've removed the "or keyboard" part out, since its covered in 2.1.1 and
> left it as follows.
>
> ​====​
>
> 2.6 [Proposed New MOBILE Success Criteria] Device manipulation: When
> device manipulation gestures are provided, touch operable alternative
> control options are available. (Level AA)
> ​Note: see also 2.1.1 for keyboard requirements.​
>
> ​=====​
>
> For mobile, having a touch alternative is preferable to a keyboard
> alternative, but this proposed SC along with the existing 2.1.1 will
> require both... this may seem like a lot but I think it is worth
> bringing to the the larger group. This SC is to help dexterity
> disabilities, not blindness. Most plind people are used to shaking and
> tilting their devices (i.e., blind square)
>
> We should maybe do some further study asking organizations working with
> people with dexterity problems who have mounted mobile devices whether
> the keyboard requirement of 2.1.1 would be sufficient or whether having
> a touch alternative to manipulatipn should be required.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd <http://twitter.com/davidmacd>
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> /  Adapting the web to *all* users/
>
> /            Including those with disabilities/
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
> On Thu, May 19, 2016 at 9:35 PM, Patrick H. Lauke
> <redux@splintered.co.uk <mailto:redux@splintered.co.uk>> wrote:
>
>     On 19/05/2016 23:09, Gregg Vanderheiden wrote:
>
>         Well - the keyboard interface provision ensures that there is
>         always at
>         least that method (built in or connected keyboard operation)  for
>         operating things - that will work for people who don’t have fine (or
>         even any real ) pointing ability.
>
>
>     Then isn't the same provision also covering all other manners of
>     device manipulation? Shaking, tilting, etc? i.e. is the entire SC
>     superfluous because of the keyboard interface provision? (which, as
>     a side note, I assume also includes the more general concepts like
>     moving focus/activating a la VoiceOver/TalkBack ? I vaguely remember
>     this being discussed at some point, but beyond discussion points at
>     https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Keyboard_Access/Modality_Independent_Control/IndieUI
>     can't find a definitive resolution)
>
>         But for those who can point but not well,  and for people with
>         cognitive
>         disabilities that might be confused with overloaded pointing
>         options -
>          it could be very helpful to have these find pointing movement
>         options
>         be real options and not the only way.
>
>
>     So now I'm wondering if it's really an SC, or more of a nice-to-have
>     best practice technique (which doesn't necessarily have hard
>     pass/fails), more suitable for publication as a note or
>     similar...but that probably derails the whole argument further.
>
>     P
>
>     --
>     Patrick H. Lauke
>
>     www.splintered.co.uk <http://www.splintered.co.uk> |
>     https://github.com/patrickhlauke
>     http://flickr.com/photos/redux/ | http://redux.deviantart.com
>     twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>
>


-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Monday, 23 May 2016 18:51:59 UTC