- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Tue, 24 May 2016 00:57:18 +0100
- To: w3c-wai-gl@w3.org, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
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:49 UTC