- From: ALAN SMITH <alands289@gmail.com>
- Date: Thu, 26 May 2016 14:40:55 -0400
- To: David MacDonald <david100@sympatico.ca>
- Cc: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <57474333.8251810a.fdbe8.36bd@mx.google.com>
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