Re: Reworking Moble TF Doc to turn into WACG Extension

On 29/08/2015 23:39, David MacDonald wrote:
> I have posted all of your comments and other comments from the community
> on a working document I created.
> http://davidmacd.com/blog/mobile-tf-proposal-2.html
>
> I'll use that one from now on, until it's moved over to Github.

Jumping in a bit late, and probably missing some context from earlier 
discussions, a few things:

# Regarding 2.5.2 Touch Target Size, two points that I believe I brought 
up on the mailing list:

- Gregg's question about 9mm - it would be good to clarify if we mean 
*physical* mm, or CSS mm. Note that many guidelines (such as Google's 
guidelines for Android, or Microsoft's app design guidelines) use 
measurements such as dips (device independents pixels) precisely to 
avoid having to deal with differences in actual physical device 
dimensions (as it's the device/OS' responsibility to map its actual 
physical size to a reasonable dips measure, so authors can take that as 
a given that is reasonably uniform across devices).

- on a more general level, I questioned why there should be an SC 
relating to target size for *touch*, but that there's no equivalent SC 
for mouse or stylus interaction? Too small a target size can be just as 
problematic for users with tremors, mobility impairments, reduced 
dexterity, etc. I know it's not the remit of the TF, but I'd argue that 
this is exactly the sort of thing that would benefit from being a 
generalised SC applicable to all manner of pointing interaction (mouse, 
pen, touch, etc). Or is the expectation that there will be a separate TF 
for "pen and stylus TF", "mouse interaction TF", etc?

(these two points also apply to 2.5.5)


# About the rewrite addressing the concerns with 2.5.4

"2.5.4 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, without relying on pass 
through gestures on the system (Level A)"

As said, when touch AT is running, all gestures are intercepted by the 
AT at the moment (unless you mean taps?). And only iOS, to my knowledge, 
has a passthrough gesture (which is not announced/exposed to users, so a 
user would have to guess that if they tried it, something would then 
happen).

If the intention was to also mean "taps", this is lost on me and 
possibly the majority of devs, as "gesture" usually implies a swipe, 
pinch, rotation, etc, which are all intercepted. [ED: skimming towards 
the end of the document, I see that in 3.3 Touchscreen Gestures "taps" 
are listed here. This, to me - and I'd argue most other devs - is 
confusing...I don't normally think of a "tap" as a "gesture"]

So this SC (at least the "touch gestures with ... assistive technology 
activated") part is currently technically *impossible* to satisfy (for 
anything other than taps), except by not using gestures or by providing 
alternatives to gestures like actionable buttons.

This can be clarified in the prose for the SC, but perhaps a better way 
would be to drop the "gestures" word, and then the follow-up about 
passthrough, leaving a much simpler/clearer:

"2.5.4 Touch: For pages and applications that support touch, all 
functionality of the content is operable through touch with and without 
system assistive technology activated (Level A)"

I'm even wondering about the "For pages and applications that support 
touch" preamble...why have it here? Every other SC relating to touch 
should then also have it, for consistency? Or perhaps just drop that bit 
too?

"2.5.4 Touch: All functionality of the content is operable through touch 
with and without system assistive technology activated (Level A)"

OR is the original intent of this SC to be in fact

"2.5.4 Touch: For pages and applications that support touch *GESTURES*, 
all functionality of the content is operable through touch gestures with 
and without system assistive technology activated, without relying on 
pass through gestures on the system (Level A)"

is this about gestures? In that case, it's definitely technically 
impossible to satisfy this SC at all currently (see above), so I'd be 
strongly opposed to it.


# 2.5.7 Pinch Zoom ...

Just wondering if the fact that most mobile browsers (Chrome, Firefox, 
IE, Edge) provide settings to override/force zooming even when a page 
has disabled it makes any difference here? iOS/Safari is the only 
mainstream mobile browser which currently does not provide such a 
setting, granted. But what if that too did?


# 3.4.1 Expose Orientation: Changes in orientation are programmatically 
exposed to ensure detection by assistive technology such as screen readers.

Agree with Gregg this is not a web content issue as currently stated. 
Also, not every orientation change needs something like an alert to the 
user...what if nothing actually changes on the page when switching 
between portrait and landscape - does an AT user need to know that they 
just rotated the device?

Perhaps the intent here is to ensure web content notifies the user if an 
orientation change had some effect, like a complete change in layout 
(for instance, a tab navigation in landscape turning into an accordion 
in portrait; a navigation bar in landscape turning into a 
button+dropdown in portrait)? If so, this needs rewording, along similar 
lines to a change in context?

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 Sunday, 30 August 2015 01:17:43 UTC