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



*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 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *David MacDonald <david100@sympatico.ca>
> *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
>
>
>
> *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
>
>
>
>
>