Re: Device manipulation

I've updated the device manipulation success criteria based on our
conversations today.

*2.6.1 [Proposed New MOBILE Success Criteria] Device manipulation:* When
device manipulation gestures are provided, a mechanism is available to
operate these functions via touch, except where the underlying function
requires input that depends on the path or pressure of the user's movement
and not just the endpoints or touch location (Level AA)

Note: see also separate keyboard requirements in 2.1.1
Device manipulation (Defn)

Moving or controlling the device with hands, body or machine. Device
manipulation includes other methods of controlling input to the mobile
device outside of using the touch screen. This includes: pressing a
physical button on the device, shaking, holding, proximity, touch, walking,
angle of holding, input via the accelerometer, <add>force of touch</add>
etc. Gestures to the camera and voice input to the microphone are addressed
separately.

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 Mon, May 23, 2016 at 2:54 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> Actually, on first reading I actually completely missed David's point, so
> disregard this.
>
> P
>
>
> On 23/05/2016 19:51, Patrick H. Lauke wrote:
>
>> 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
>
>
>