RE: SC's or techniques on Force and duration

> Further...would this sort of thing not also be a problem for a non-touchscreen user? For instance, a mouse user with dexterity problems? In fact, depending on the situation, wouldn't the auto-capture described above (being able to trigger a function even if the finger is NOT exactly over the control anymore) in fact be beneficial in certain situations, where a user may not have the most steady finger on a touchscreen?

Patrick, I think this is the thing we are trying to solve -- but in the opposite direction -- that the person may touch the wrong thing before correctly locating the correct control.  Just making something revocable doesn't seem enough as it might be difficult to get back to that screen or action.  Your examples of the sliders are good -- but that IMO is not a single tap gestures but a tap and slide.  So perhaps just keeping this single or long tap gestures is safest.

I do run into this issue often on certain mobile apps and certain sites where I'll put my finger down to perform to do something and the action is triggered right away on the thing I wasn't trying to affect.

Have you looked at the iOS settings for touch accommodations?   They seem to mirror what we are trying to say.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
jon.avila@ssbbartgroup.com
703.637.8957 (o) 
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter


-----Original Message-----
From: Patrick H. Lauke [mailto:redux@splintered.co.uk] 
Sent: Monday, December 14, 2015 8:06 PM
To: public-mobile-a11y-tf@w3.org
Subject: Re: SC's or techniques on Force and duration

On 10/12/2015 17:17, David MacDonald wrote:

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

Sorry for the late reply. Right, the automatic capture here depends on the type of events you're listening to (and the type of element you're listening on).

First of, let's assume you're binding event listeners to the actual control (and not on body or html and using event delegation).

Now, say you have a <button>. If you put your finger on the button, and move the finger out of the button while still keeping it on the screen, the button will remain in the "pressed/down" state; additionally, the browser will keep firing "touchmove" events on the button, even when the finger isn't over the button anymore - this is the auto-capture bit. 
Compare this to what you'd expect from, say, mouse events, where events would not be fired anymore at the button after the mouse pointer left the boundary of the button. Lastly, if you then lift your finger outside of the button, it won't fire a "click" event  (as the browser assumes that all that movement of the finger means it's not really a "tap") - however, it will fire a "touchend" event. Long story short: if your code is listening for "touchend", you'd have to do additional work to then check if the touchend's coordinates fall back within the boundaries of the control.

The most generic demo I have that demonstrates these events firing even when your finger is outside of the button is probably http://patrickhlauke.github.io/touch/tests/event-listener_prevent-default-touchmove.html

- put a finger on the button, then move it out of the button...note the touchmove events still fire, the button remains in a depressed state while your finger is outside of the button, and a final touchend is fired when the finger is lifted, regardless of whether it was inside or outside of the button's boundaries.

A slightly different, and probably less complex, example would be something like a native <input type="range"> - by default, iOS/Safari will allow you to do effectively the same as above: touch the slider, move your finger around the screen to change value, regardless of whether your finger remains over the input itself, and fire a "change" 
event at the end regardless of where your finger was when you lifted it.

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

Why not make the normative wording more generic (basically, just saying that actions are revocable), but then give non-normative/informative examples that are more specific? Otherwise I fear that the normative wording will be too closely tied to the current, very specific state of implementation in certain OS/UA combinations.

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

Also, looking more generally at this...would we really want to fail ALL instances of a control that doesn't implement something like "only activate if finger was lifted inside the element"/"action is revocable"? 
What if the outcome of triggering the control is completely trivial (i.e. not initiating a payment or something of import).

Further...would this sort of thing not also be a problem for a non-touchscreen user? For instance, a mouse user with dexterity problems? In fact, depending on the situation, wouldn't the auto-capture described above (being able to trigger a function even if the finger is NOT exactly over the control anymore) in fact be beneficial in certain situations, where a user may not have the most steady finger on a touchscreen?

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 Tuesday, 15 December 2015 13:36:41 UTC