RE: Device manipulation

David,

Great, thanks for your clarification.
I did not consider it a touch gesture.

Alan

Sent from Mail for Windows 10

From: David MacDonald
Sent: Thursday, May 26, 2016 2:20 PM
To: ALAN SMITH
Cc: public-mobile-a11y-tf@w3.org
Subject: Re: Device manipulation

Hi Alan... that sounds like a sufficient way to do something... it is a touch gesture on the edge of rhe screen, which is essentially the same action as a touch gesture for the end user, so I don't see are reason to require it to be provided in another touch way in the middle of the screen...


Cheers,
David MacDonald
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 

twitter.com/davidmacd
GitHub
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

On Thu, May 26, 2016 at 1:15 PM, ALAN SMITH <alands289@gmail.com> wrote:
Great work. Sorry I missed the call.
 
How does a tap or single tap on the side of a device which is used in place of a gesture fit into this description?
When the manipulation is used instead of a gesture, do we also need to have a touch option?
 
Maybe the term “device manipulation gestures” needs a little rewording? 
As I don’t consider tapping the side of a device a gesture, since in the Android devices this is considered an alternate to a gesture in their terms.
 
Alan
 
Sent from Mail for Windows 10
 
From: David MacDonald
Sent: Thursday, May 26, 2016 12:14 PM
To: public-mobile-a11y-tf@w3.org
Subject: 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
 
CanAdapt Solutions Inc.
Tel:  613.235.4902
LinkedIn 

twitter.com/davidmacd
GitHub
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
 
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
 
 

Received on Thursday, 26 May 2016 18:41:20 UTC