RE: Reworking Moble TF Doc to turn into WACG Extension

> - 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? 
[ja] My guess is that touch target size would need to be larger than a mouse pointer touch area -- so the touch target would catch those as well.

> Too small a target size can be just as problematic for users with tremors, mobility impairments, reduced dexterity, etc. 
[ja] That's exactly who this SC is aimed at.  This SC is not specifically aimed at screen reader users or low vision users but people with motor impairments.

> 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?
[jda] If you use a pen or stylus it's also touch -- so it's already covered  This doesn't mean touch with a finger -- it means touch with something -- a finger, a stylus, a prosthetic, a pen, etc..

> 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

Yes, that is the intention.  For example, if you change from landscape to portrait a set of links disappears and now there is a button menu instead.  Or controls disappear or appear depending on the orientation.

Jonathan

-- 
Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
jon.avila@ssbbartgroup.com

703-637-8957 (o) 
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter


-----Original Message-----
From: Patrick H. Lauke [mailto:redux@splintered.co.uk] 
Sent: Saturday, August 29, 2015 9:17 PM
To: public-mobile-a11y-tf@w3.org
Subject: 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 Monday, 31 August 2015 01:19:30 UTC