RE: Comments on proposed new SC 2.5.3

> wording) for situations where a down-activation is ok (on-screen piano, space shooter, etc, where a mistaken activation is not that dramatic/problematic,

I agree as well and this was something I had commented in the past an recently -- we need an exception for when down press without reversal is essential to the activity such as playing a piano.   We should model it similar to those found for SC 2.2.1 Timing.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
jon.avila@ssbbartgroup.com
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!


-----Original Message-----
From: Patrick H. Lauke [mailto:redux@splintered.co.uk] 
Sent: Monday, April 18, 2016 3:46 AM
To: David MacDonald
Cc: public-mobile-a11y-tf@w3.org
Subject: Re: Comments on proposed new SC 2.5.3



On 18/04/2016 03:56, David MacDonald wrote:
> One slight problem of asynchronous collaboration is that a few hours 
> after Detlev's comments we had the weekly call and worked for a hour 
> on it ... It is no longer tied to touch, and addresses, I believe in a 
> fairly elegant way, all the concerns to date...
>
> 2.5.3 Up-Event Activation: Single touch and/or pointer activation 
> triggers on the up-event, or has at least one of the following 
> characteristics (Level A):
> - provides confirmation,
> - is reversible,
> - a mechanism is available to trigger on the up-event.
>
> Note: This is when platform assistive technology that remaps touch 
> gestures is not turned on.

I'm not completely sure that wording (which includes "Up-Event") is completely appropriate, as it already hints at the technical solution, rather than describing the more generic problem it's trying to avoid (i.e. the "Avoid that users accidentally activate functionality..." aspect)

Also, the wording there doesn't include exemption (in the normative SC
wording) for situations where a down-activation is ok (on-screen piano, space shooter, etc, where a mistaken activation is not that dramatic/problematic, and the responsiveness of firing on down is essential to the control itself)

However, I agree this proposed new wording is already much better than the one I initially commented on/reacted to :)

P

> Also have revised the understanding document and provided some 
> alternative language for the SC.
> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5

> .3
>
>
> On Sat, Apr 16, 2016 at 5:29 PM, Patrick H. Lauke 
> <redux@splintered.co.uk <mailto:redux@splintered.co.uk>> wrote:
>
>
>
>     On 14/04/2016 15:53, Detlev Fischer wrote:
>
>         Just taking a minute to think about 2.5.3
>
>         Echoing Patrick's advice that we should not focus on touch if the
>         issue is more general, it seems fairly obvious that  "2.5.3 Touch Up
>         Activation" or "2.5.3 Single Taps and Long Presses Revocable"
>         describes an issue that is equally valid for mouse pointer
>         activation.
>
>         Which suggests we might draw the boundary wider and rename it to
>         something like SC 2.5.3 "Support undo"
>
>         Which contradicts the renaming I have suggested in the last telco.
>         "Touch Up Activation" sounds easier (which is a benefit), but
>         narrowing the issue to touch seems inappropriate for a SC - it would
>         be OK on the level of Technique.
>
>         So itf we try to tackle the general issue of supporting undo by not
>         triggering things on touchstart / mouseDown, the question remains
>         wehther it is really inside scope for WCAG.
>
>
>     Going back even further, rather than "undo" was the original issue,
>     fundamentally, about "Avoid that users accidentally activate
>     controls and/or have a way to 'bail out'"? (which won't win any
>     terseness awards, but thought I'd throw the lot in there).
>
>     So the normative part can, in a tech agnostic way, hopefully convey
>     this idea (which is just as applicable to keyboard, switch, mouse,
>     touch, voice activation, etc users) that an app/site should be built
>     in a way that a user doesn't accidentally click on things they
>     didn't intend to, and that if they already started a click
>     activation (e.g.  touch down, mouse button already pressed down,
>     etc) they either have a way of cancelling this activation (by moving
>     their finger or mouse while still pressed outside/sufficiently away
>     from the control before lifting their finger/releasing the mouse
>     button), OR by providing some way of undo-ing/reverting the action -
>     IF the action is "of consequence" (e.g. if it was a touchscreen
>     piano, or the fire button of a real-time [rather than turn
>     based/tactical] space shooter, it's no big deal if it activated by
>     accident, and an undo would not be practical/possible).
>
>     Then, in techniques, it can go further into tech specific "bind
>     event listeners to both touchend / the "up" AND the generic "click"
>     / activation; for mouse, don't listen to "mouseover" but "mouseup"
>     AND "click"; etc.
>
>     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 Monday, 18 April 2016 14:39:41 UTC