Re: Rough draft of some success criteria for a extension guideline "Touch accessible"

>>Jonathan: Would that include hardware buttons?  For example, would
touching the hardware back button count here?  We’d also need some sort of
clause to say when touch is supported by the platform.

 Buttons may make sense to add. I'm not sure. Would like to get feedback on
that.

>What if something was keyboard accessible and speech accessible?
We already have a requirement for keyboard use. I don't think that should
go away.

Yes we would need to add the disclaimer line about this being for touch
interfaces.

>Patrick says: As it's not possible to recognise gestures when VoiceOver is
enabled, as VO intercepts gestures for its own purposes (similar to how
desktop AT intercept key presses) unless the user explicitly uses a
pass-through gesture, does this imply that interfaces need to be made to
also work just with an activation/double-tap ? i.e., does double-tap count
in this context as a "gesture"? If not, it's not technically possible for
web pages to force pass-through (no equivalent to role="application" for
desktop/keyboard handling)...

David: VO uses gestures for its own purposes and then adds gestures to
substitute for those it replaced i.e., VO 3 finger swipe= 1 finger swipe.
I'm suggesting that everything that can be accomplished with VO off with
gestures can be accomplished with VO on.

>Jonathan: In theory I think this would benefit people from prosthetics
too.  For example, many apps support zoom by double tapping without
requiring a pinch.

David: It would be great to operate everything through taps... even
creating a Morse code type of thing, where all gestures could be done with
taps for those who can't swipe, but it would require a lot more
functionality than is currently available.  I think we should park it, and
perhaps provide it as a best practise technique under this Success Criteria.

How about this amendment?

2.5.1 Touch: For pages and applications that support touch, all
functionality of the content is operable through touch gestures with and
without system assistive technology activated. (Level A)


Cheers,

David MacDonald



*Can**Adapt* *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 Sun, Aug 16, 2015 at 9:42 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

> Ø  2.5.1 Touch: All functionality of the content is operable through
> touch gestures with and without system assistive technology activated.
> (Level A)
>
> Would that include hardware buttons?  For example, would touching the
> hardware back button count here?  We’d also need some sort of clause to say
> when touch is supported by the platform.  Some mobile platforms may not
> support touch and may only have physical buttons.  What if something was
> keyboard accessible and speech accessible?  That is what if some actions
> just can’t be done with touch using a screen reader but they provide
> keyboard access and other method such as speech or hardware button presses?
>
>
>
> I like your proposed changed much better than the prior suggestion!
>
>
>
> 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, August 13, 2015 2:07 PM
> *To:* Detlev Fischer
> *Cc:* public-mobile-a11y-tf@w3.org
> *Subject:* Re: Rough draft of some success criteria for a extension
> guideline "Touch accessible"
>
>
>
> >2.5.1 Touch: All functionality of the content is operable through touch
> gestures. (Level A)
>
>
> Suggested friendly amendment:
>
> 2.5.1 Touch: All functionality of the content is operable through touch
> gestures with and without system assistive technology activated. (Level A)
>
> I think this will address my concern that often touch gestures don't work
> when VoiceOver is activated.
>
>
>
>
> 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 Fri, Jul 24, 2015 at 5:49 AM, Detlev Fischer <
> detlev.fischer@testkreis.de> wrote:
>
> Hi folks,
> This is my first shot at possible success criteria for a new WCAG
> extension guideline "Touch Accessible" under Principe 2 Operable. The one
> SC I was actually asked to draft is what I provisionally called "2.5.3
> Single Taps and Long Presses Revocable". I found it easier to also sketch
> some other obvious SCs to see where this one might fit.
>
>
> Guideline 2.5 Touch Accessible: Make all functionality available via touch.
>
> 2.5.1 Touch: All functionality of the content is operable through touch
> gestures. (Level A)
>
> 2.5.2 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)
>
> 2.5.3 Modified Touch: When touch input behavior is modified by built-in
> assistive technology, all functionality of the content is still operable
> through touch gestures. (Level A)
>
> 2.5.4 No Swipe Trap: When touch input behavior is modified by built-in
> assistive technology so that touch focus can be moved to a component of the
> page using swipe gestures, then focus can be moved away from that component
> using swipe gestures or the user is advised of the method for moving focus
> away. (Level A)
>
> --------------
>
> 2.5.5 Touch Target Size: One dimension of any touch target measures at
> least 9 mm except when the user has reduced the default scale of content.
> (Level AA)
>
> 2.5.6 Touch Target Clearance: The center of each touch target has a
> distance of at least 9 mm from the center of any other touch target, except
> when the user has reduced the default scale of content. (Level AA)
>
>
> --
> Detlev Fischer
> testkreis c/o feld.wald.wiese
> Thedestr. 2, 22767 Hamburg
>
> Mobil +49 (0)1577 170 73 84
> Tel +49 (0)40 439 10 68-3
> Fax +49 (0)40 439 10 68-5
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
>
>