Re: Reworking Moble TF Doc to turn into WACG Extension

I've updated the document to add Patrick's and Jonathan's Comments
http://davidmacd.com/blog/mobile-tf-proposal-2.html

Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

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 Sun, Aug 30, 2015 at 9:18 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

> > - 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
>
>