- From: David MacDonald <david100@sympatico.ca>
- Date: Fri, 11 Dec 2015 10:32:53 -0500
- To: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <CAAdDpDbugmh4GPQvZcbf-8k0gFJp7GorfcY+6BfJhmGnh0RCEw@mail.gmail.com>
*2.5.3 Single Taps and Long Presses Revocable:* Interface elements that require a single tap or a long press as input will only trigger the corresponding event when the finger is lifted inside that element unless their is a means of confirming before triggering the event, or the event can be reversed (Level A) I think drag and drop should be reversible. If others agree, then perhaps the language of the proposal will work, given that the drag and drop can be revocable. We could articulate that in the understanding with a sentence such as "drag and drop events that can be reversed would be an example of a revocable event" 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, Dec 10, 2015 at 9:00 PM, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote: > Ø *2.5.3 Single Taps and Long Presses Revocable:* Interface elements > that require a single tap or a long press as input will only trigger the > corresponding event when the finger is lifted inside that element unless > their is a means of confirming before triggering the event, or the event > can be reversed (Level > > > This is similar to what we discussed on the call last week and we also > discussed having an exception for drag and drop. > > > > Perhaps Patrick can point us to some examples where the platform acts on > the touch so we might understand the scenarios where this is needed. > > > > Jonathan > > > > -- > Jonathan Avila > Chief Accessibility Officer > SSB BART Group > jon.avila@ssbbartgroup.com > > > > 703-637-8957 (o) > Follow us: Facebook <http://www.facebook.com/#%21/ssbbartgroup> | Twitter > <http://twitter.com/#%21/SSBBARTGroup> | LinkedIn > <http://www.linkedin.com/company/355266?trk=tyah> | Blog > <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP> > > > > *From:* David MacDonald [mailto:david100@sympatico.ca] > *Sent:* Thursday, December 10, 2015 12:17 PM > *To:* Patrick H. Lauke > *Cc:* public-mobile-a11y-tf@w3.org > *Subject:* Re: SC's or techniques on Force and duration > > > > Hi Patrick > > We've been looking at a proposed new Success Criteria: > *2.5.3 Single Taps and Long Presses Revocable:* Interface elements that > require a single tap or a long press as input will only trigger the > corresponding event when the finger is lifted inside that element. (Level A) > > You commented: > *Patrick:* I like the concept, but the wording that follows (requiring > that things only trigger if touch point is still wihin the same element) is > overly specific/limiting in my view. Also, it is partly out of the > developer's control. For instance, in current iOS and Android, touch events > have a magic "auto-capture" behavior: you can start a touch sequence on an > element, move your touch point outside of the element, and release it...it > will still fire touchmove/touchend events (but not click, granted). Pointer > Events include an explicit feature to capture pointers and to emulate the > same behavior as touch events. However, it would be possible to make > taps/long presses revocable by, for instance, prompting the user with a > confirmation dialog as a result of a tap/press (if the action is > significant/destructive in particular). This would still fulfill the > "revocable" requirement, just in a different way to "must be lifted inside > the element". In short: I'd keep the principle of "revocable" actions, but > would not pin down the "the finger (touch point, whatever...keeping it a > bit more agnostic) is lifted inside the element". > > A couple of questions > > 1) Several of us tried touching events on our phones and moving away while > pressing, and they did not fire using the "magic auto capture" you mention. > Is this a special control behaviour that the author calls out voluntarily, > or is it attached only to certain iOS/android touch events. > > 2) The primary problem we are trying to address is allowing people to > change their mind after they select something and before they remove their > finger but we understand your desire to make it more generic. Perhaps we > can keep our wording and add and OR statement. > > > How is this? > *2.5.3 Single Taps and Long Presses Revocable:* Interface elements that > require a single tap or a long press as input will only trigger the > corresponding event when the finger is lifted inside that element unless > their is a means of confirming before triggering the event, or the event > can be reversed (Level A) > > Note > > > Cheers, > > David MacDonald > > > > *CanAdapt* *Solutions Inc.* > > Tel: 613.235.4902 > > LinkedIn <http://www.linkedin.com/in/davidmacdonald100> > > 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 Wed, Nov 18, 2015 at 5:29 AM, Patrick H. Lauke <redux@splintered.co.uk> > wrote: > > On 18/11/2015 10:26, Patrick H. Lauke wrote: > > These could broadly be lumped in with "gesture" overall (i.e. expanding > the definition of a gesture as being related to movement - a swipe, > pinch, etc - as well as other properties of the interaction - force, > duration, or in some cases even rotation of the touch point [...] > > > Also, tilt information for stylus/pen interactions, I guess > https://twitter.com/patrick_h_lauke/status/666620487410327552 (i.e. if an > app triggers specific actions depending on the tilt of a stylus, these need > to be available for users that don't have a tilt-capable input > device/mechanism). > > > > P > -- > 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 Friday, 11 December 2015 15:33:32 UTC