Re: Device manipulation

PS link is here
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Guideline_2.6:_Make_it_easier_to_use_the_physical_features_of_the_phone.#Proposed_new_Success_Criteria_on_Device_Manipulation


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 26, 2016 at 12:13 PM, David MacDonald <david100@sympatico.ca>
wrote:

> 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
>>
>>
>>
>