RE: Tweak 2.5.3

Ø  What the criterion, as it reads now, essentially does is universally define the selection gesture to be on touch up.

I don’t think it says that.   We can tweak the note to describe case 1 and case 2 that you point out.


Ø  It doesn't seem to me to be our place to define this.  This removes a lot of developer flexibility, without really accomplishing anything specific from an accessibility point of view.  In fact, what we really accomplish is alienating Type 1 Users.  When two subsets of disabled users may find one black and white approach better than the other, shouldn't we allow flexibility?  In fact, don't we want to REQUIRE flexibility?
Yes, I think we do that.  The SC allows for touch down as long as the action can be undone.


Ø  I would propose making this a Triple or Double A requirement, and having the success criterion read very similar to what it does now.

I’d vote to keep this AA and not AAA but it’s open for discussion.


Ø  However, say something about: Users should have the ability to define whether selection (onClick events in web speak) occurs on touch down, or on touch up.  This would satisfy both users.  It certainly satisfies Type 1 users better than the current requirement.

We are talking about something very different from onclick IMO.  Also, we don’t want to require authors to provide both options – that would be a user agent thing.

iOS has touch accommodation features and allows for when it’s turned on to use initial or final touch location – final is checked by default.

The iOS settings also allow for touch repeat and for touch duration as well as a touch delay.  These user agent settings seem to address the needs that we were originally trying to solve – but these settings came out a few months ago after we had already identified this success criteria.

Dwell time, accidental touches, and repeated touch because the first touch was not accepted, button location, pushing off of the touch screen with force, were items (among others) identified in the CSUN presentation I attended.

So perhaps our SC should be focused around these things such as providing visual feedback, and methods for something to be undone and not relying on the duration of the touch for activation.  That is we make this more general and get rid of specifics about touch up or down.

Jonathan

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

Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: Chris McMeeking [mailto:chris.mcmeeking@deque.com]
Sent: Thursday, March 31, 2016 4:13 PM
To: Kathy Wahlbin
Cc: Jonathan Avila; ALAN SMITH; David MacDonald; public-mobile-a11y-tf@w3.org
Subject: Re: Tweak 2.5.3

Upon further reflection, if the AT is not on, I believe the current wording of the criteria has a fatal flaw.  Let's assume there are two types of disabilities at play.

Type 1: The user has an easy time targeting for touch down, but difficult controlling through the entire motion.  As such the initial target is precise, but the release point is not.  Think mild cerebral palsy.

Type 2: The second set of users use the screen for support throughout the gesture.  Their initial contact point may be off, but they release at the correct spot.  Think essential tremor or geriatric.

When we originally started discussing this criteria, it seemed to me that it was about not having 2 actions take place per gesture (ex: not responding to both touch up and touch down, but rather one or the other).  This makes a lot of sense.  Both Type 1 and Type 2 users would have a problem with a system that took advantage of both gestures.

What the criterion, as it reads now, essentially does is universally define the selection gesture to be on touch up.  It doesn't seem to me to be our place to define this.  This removes a lot of developer flexibility, without really accomplishing anything specific from an accessibility point of view.  In fact, what we really accomplish is alienating Type 1 Users.  When two subsets of disabled users may find one black and white approach better than the other, shouldn't we allow flexibility?  In fact, don't we want to REQUIRE flexibility?

I would propose making this a Triple or Double A requirement, and having the success criterion read very similar to what it does now.  However, say something about: Users should have the ability to define whether selection (onClick events in web speak) occurs on touch down, or on touch up.  This would satisfy both users.  It certainly satisfies Type 1 users better than the current requirement.

Chris



On Thu, Mar 31, 2016 at 3:15 PM, Kathy Wahlbin <kathyw@ia11y.com<mailto:kathyw@ia11y.com>> wrote:
Touch duration is something that can be set in the device settings.  Is there something that we would need to do from mobile application or website perspective?

Kathy

From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>]
Sent: Thursday, March 31, 2016 3:08 PM
To: ALAN SMITH <alands289@gmail.com<mailto:alands289@gmail.com>>; David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>

Cc: public-mobile-a11y-tf@w3.org<mailto:public-mobile-a11y-tf@w3.org>
Subject: RE: Tweak 2.5.3

Touch duration (dwell time) was a big factor seen in the study I attended a CSUN session on.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957<tel:703.637.8957> (Office)
Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: ALAN SMITH [mailto:alands289@gmail.com]
Sent: Thursday, March 31, 2016 3:06 PM
To: Jonathan Avila; David MacDonald
Cc: public-mobile-a11y-tf@w3.org<mailto:public-mobile-a11y-tf@w3.org>
Subject: RE: Tweak 2.5.3

Do we also need to consider touch duration?
I personally know of people with injuries and other finger sensitivity conditions that need a longer touch time to perform a touch trigger.

Alan

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Jonathan Avila<mailto:jon.avila@ssbbartgroup.com>
Sent: Thursday, March 31, 2016 2:04 PM
To: David MacDonald<mailto:david100@sympatico.ca>
Cc: public-mobile-a11y-tf@w3.org<mailto:public-mobile-a11y-tf@w3.org>
Subject: RE: Tweak 2.5.3

David, thank you for putting this together.  Since we are talking without ATs that remap the gestures I think it is confusing to talk about focus.  For example, when I touch an HTML button on iOS the events are touchstart, touchend and mouseover if I drop and lift my finger on the button.  If I drop then move my finger and then lift somewhere else they are touchstart, touchmove and then touchend.  Only controls like input would receive focus on mobile safari without AT.  When AT is running other interactive elements do receive focus.  Chris mentioned that some users would actually prefer to trigger based on touchstart since they might move their finger to the wrong place when lifting.    I really wish we could find some reliable research on this topic.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957<tel:703.637.8957> (Office)
Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Thursday, March 31, 2016 12:52 PM
To: Jonathan Avila
Cc: public-mobile-a11y-tf@w3.org<mailto:public-mobile-a11y-tf@w3.org>
Subject: Re: Tweak 2.5.3

In discussions during the call I took an action to make it clear that 2.5.3 is about the environment with AT is turned off.  I thought it would be best to just make it a trailing note after the SC.

===========================
2.5.3 Independent Activation: The activation gesture has one or more of the following characteristics (Level A):

  1.  is separate from the focus gesture,
  2.  provides confirmation,
  3.  is reversible,
  4.  a mechanism is available to activate functionality independently from focus.

This is when platform assistive technology that remaps touch gestures is not turned

===================
**OR:**

If we want to incorporate it into the text of the SC then it would look like this.
2.5.3 Independent Activation: When platform assistive technology that remaps touch gestures is off, the activation gesture has one or more of the following characteristics (Level A): ...
We use "When platform assistive technology that remaps touch gestures is turned on/off" twice now. This is the most accurate term we could come up with, but is a bit of a mouthful, do we dare create an acronym (PATRTG ??) which would be defined in its first appearance and in the glossary?

===Definition==
Platform assistive technology that remaps touch gestures (PATRTG): Software that is integrated into the operating system, ships with the product, and/or is updated or installed via system updates. This software changes the characteristics of the touch interface when turned on. (e.g., When turned on, a system screen reader may remap a right swipe gesture to move focus from item to item instead of it's default behaviour of changing screens, when the assistive technology is not on.


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


On Wed, Mar 23, 2016 at 4:02 PM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
I've updated it to "focus" instead of "selection"

We might also consider "on focus" but I'd like the group to mull that over before giving that nod to JavaScript.

On Fri, Mar 18, 2016 at 9:58 PM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
my interpretation is "focus"

On Fri, Mar 18, 2016 at 3:23 PM, Jonathan Avila <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>> wrote:
I apologize that I was not on the call on Thursday but I had an unexpected eye doctor appointment.   I have a question around 2.5.3 – what is meant by selection?  We use that twice and I’m not sure what we mean by that.

Thanks

Jonathan


From: David MacDonald [mailto:david100@sympatico.ca<mailto:david100@sympatico.ca>]
Sent: Thursday, March 17, 2016 12:22 PM
To: public-mobile-a11y-tf@w3.org<mailto:public-mobile-a11y-tf@w3.org>
Subject: Re: Tweak 2.5.3


Small tweak:

As per our meeting today, I tweaked 2.5.3

2.5.3 Independent Activation: The activation gesture has one or more of the following characteristics (Level A):

1) is separate from the selection gesture,

2) provides confirmation,

3) is easily reversible, or

4)a mechanism is available to activate functionality independently from

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


On Thu, Mar 17, 2016 at 12:18 PM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
As per our meeting today, I tweaked 2.5.3

2.5.3 Independent Activation: The selection gesture has one or more of the following characteristics (Level A):
1) is separate from the activation gesture,
2) provides confirmation,
3) is easily reversible, or
4)a mechanism is available to activate functionality independently from selection.

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