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

PS in the understanding documenbt for this SC we would explain that touch
gestures with VO on could be and probably would be the VO equivalent to the
standard gestures used with VO off.

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 Mon, Aug 17, 2015 at 7:27 AM, David MacDonald <david100@sympatico.ca>
wrote:

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