Re: Reworking Moble TF Doc to turn into WACG Extension

I've placed the comments in Blue, and for those who have trouble
distinguishing colour ...the speaker's name is in front of each comment
with a colon.
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 Tue, Sep 1, 2015 at 6:49 AM, David MacDonald <david100@sympatico.ca>
wrote:

> I've placed the comments in Blue, and for those who have trouble
> distinguishing colour the speaker's name is in front of each comment with a
> colon.
> 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 Mon, Aug 31, 2015 at 6:01 PM, Gregg Vanderheiden <
> gregg@raisingthefloor.org> wrote:
>
>> Hi David
>>
>> thanks for compiling all this
>>
>> I would suggest you put everyone comments in a light blue box (maybe
>> indented one level) so that they are separable visually (and semantically)
>> from the actual text of the document.
>>
>> also if each person is in a different box it is easier to parse.
>>
>> ( oh I see that guidelines are blue boxes —   hmmm
>> maybe just put them in blue text and indent them (or mark them up as
>> quotes and put them in blue)
>>
>> *gregg*
>>
>> ----------------------------------
>> Gregg Vanderheiden
>> gregg@raisingthefloor.org
>>
>>
>>
>>
>> On Aug 31, 2015, at 3:52 PM, David MacDonald <david100@sympatico.ca>
>> wrote:
>>
>> 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 <http://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
>>>
>>>
>>
>>
>