- From: Henny Swan <hswan@paciellogroup.com>
- Date: Tue, 24 May 2016 11:51:30 +0100
- To: David MacDonald <david100@sympatico.ca>
- Cc: Patrick Lauke <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-Id: <4AB46490-5229-4E5E-93AF-27BDEEDC223C@paciellogroup.com>
+1 Pass thorough gestures should be seen as a secondary means to complete complex or non standard tasks. A short cut for people that know about it and have the dexterity to execute it. Henny -- Henny Swan User Experience and Design Lead The Paciello Group https://www.paciellogroup.com <https://www.paciellogroup.com/> -- This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. > On 24 May 2016, at 04:38, David MacDonald <david100@sympatico.ca> wrote: > > 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 > > CanAdapt Solutions Inc. > Tel: 613.235.4902 > LinkedIn > <http://www.linkedin.com/in/davidmacdonald100> > twitter.com/davidmacd <http://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 <mailto: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/ <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 <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://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/LayoutandAppearance.html>, https://developers.google.com/speed/docs/insights/SizeTapTargetsAppropriately#overview <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 <http://www.splintered.co.uk/> | https://github.com/patrickhlauke <https://github.com/patrickhlauke> > http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com <http://redux.deviantart.com/> > twitter: @patrick_h_lauke | skype: patrick_h_lauke > > >
Received on Tuesday, 24 May 2016 10:51:57 UTC