Re: WCAG Agenda May 24, 2016

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

Received on Monday, 23 May 2016 23:57:44 UTC