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've added an exception based on the wording of 2.2.1. And added language
to the understanding.

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

The success criteria have to be testable statements. I don't think
"up-event" is technology specific. I think it's understandable and crosses
most technologies. I'm nervous about adding a layer of abstraction. We did
that with an earlier draft, and it was confusing...

The Guideline level is where we deal with generalities. This is under a new
proposed guideline:

Guideline 2.5: Touch and Pointer: Make it easier for users to operate touch
and pointer functionality.

The new language is:

2.5.3 Up-Event Activation: Single touch and/or pointer activation is
triggered on the up-event, or has at least one of the following is true
(Level A):

   1. confirmation is provided which can dismiss activation; or
   2. the action is reversible; or
   3. a mechanism is available to allow the user to trigger activation on
   the up-event; or
   4. timing of the event is essential and waiting for the up-event would
   invalidate the activity.

Note: This is when platform assistive technology that remaps touch gestures
is *not *turned on.

I've also updated the Understanding Doc.

https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3


On Mon, Apr 18, 2016 at 10:39 AM, Jonathan Avila <jon.avila@ssbbartgroup.com
> wrote:

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