Re: WCAG Agenda May 24, 2016

My experience is that pass through gestures don't work well.

You can't take your hand off the screen... they are an emergency tactic
like hitting hyperspace in the old Asteroids game in the 70's, you never
know what will happen... usually nothing...

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://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, May 23, 2016 at 7:57 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 24/05/2016 00:33, James Nurthen wrote:
>
> Requiring all the functionality to be exposed visually is going to be
>> way too distracting (and hard to use for a VO user to use as well) and I
>> really don't want to have to go down the modes path again (I hate modes
>> for a lot of reasons).
>> Imagine using iOS mail if there were icons for "Mark
>> unread","Flag","More","Delete" after each message. Swiping through all
>> of those icons would be really annoying. I would love to be able to
>> replicate the native iOS experience in a web app with VO running but
>> there doesn't seem to be any way to do so - and until there is
>> passthrough gestures for things like these seem to be the best approach.
>> I do agree that these things need to be kept to the minimum and ideally
>> used for non-essential functionality, or functionality that is available
>> somewhere else (perhaps after a drill-down operation) but I'm not sure
>> we can prohibit them completely without running the risk of making the
>> UI worse for everybody.
>>
>
> My point isn't that every gesture needs to have a visible button right
> there, but that in general the same action/effect can somehow be performed
> even if you can't execute a gesture. In the case of the mail app, this
> *may* mean providing those icons/controls for each message, or going via
> the "Edit" > check messages > choose "Mark"/"Move"/"Delete" bulk options,
> or even "Go to the message itself, then activate the options there from the
> command bar at the bottom".
>
> Just the same way that I'd interpret the requirement for general keyboard
> accessibility.
>
> By all means, use gestures as a quick power-user shortcut, but make sure
> alternatives are available.
>
> I was stating that, as the author, by allowing my user to zoom, the user
>> can zoom in enough that they will be able to create big enough touch
>> targets. If I don't disable zoom then I have allowed my user to be able
>> to meet this requirement without having to do anything.
>>
>
> Shouldn't touch/activation targets be big enough out of the box (where
> "the box" here is the ideal mobile-optimised scenario with the appropriate
> width=device-width sizing), rather than allowing authors to simply say
> "well, if they're too small, users can simply zoom in, can't they?"
>
> Also, in the context of native, there's generally no pinch-to-zoom or
> similar, so that would fall through the cracks.
>
> This doesn't sound practical really does it. How can I control where the
>> links are in any arbitrary block of text on any device?
>>
>
> By avoiding high link density in the first place?
>
> At least in the case of links, some UAs now provide built-in mechanisms to
> help the user disambiguate taps (e.g. Chrome brings up a zoomed-in view
> when you tap in a region with multiple links in close proximity - something
> that Opera played with back in 2009
> http://www.iheni.com/opera-fingertouch/), but this can't be consistently
> relied on.
>
> The idea of defining minimum touch target sizes (which we're trying to
> also extend to mouse/pointers in general) is present in many guides such as
> http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/design/touch-target-size,
>
> https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/LayoutandAppearance.html,
>
> https://developers.google.com/speed/docs/insights/SizeTapTargetsAppropriately#overview
>
> How would you propose resolving this situation while allowing users to
> confidently tap/activate the right links? Or was that related to allowing
> pinch-to-zoom as sufficient solution?
>
> P
>
> --
> 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
>
>
>