Re: Device manipulation

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

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>
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 | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>
>