Re: Reworking Moble TF Doc to turn into WACG Extension

*Patrick: *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).

*David:* All gestures are intercepted. But all standard gestures are
replaced, unless the author does something dumb to break that. I think we
need to, at a minimum ensure that standard replacement gestures are not
messed uo.

For instance: I recently tested a high profile app for a major sports
event. It had a continuous load feature like twitter that kept populating
as you scroll down with one finger. Turn on the VoiceOver and try the 3
finger equivalent of a swipe and nothing happens to populate the page. The
Blind user has hit a brick wall. I think we have to ensure this type of
thing doesn't happen on WCAG conforming things.


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 Sat, Aug 29, 2015 at 9:17 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

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