Re: Proposed replies to Pointer Gestures public comments (IBM)

​It's to be expected that we each remember things a bit differently. I
think its an important question to get answered.

Here's the pull request
https://github.com/w3c/wcag21/pull/132

> All functionality can be operated without requiring complex or timed
pointer gestures or multi-pointer gestures.

Here's the issue https://github.com/w3c/wcag21/issues/61
And there is a thread there to follow.

I agree we separately discussed mobile keyboards vs real keyboards and the
limitations of keyboards with mobile users, particularly the problems of
expecting a blind person to carry around a keyboard in their backpack and
pull it out whenever they want to use their phone. But my understanding was
that proposals (including mine) to require all functionality to work with a
pointer were not successful.

​If we want to require all functionality work with a pointer in this SC,
then we'll probably need to rework the Understanding document to make that
the focus of this SC. We might get some negative feedback but I'm open to
trying.​



On Oct 9, 2017 1:37 PM, "Detlev Fischer" <detlev.fischer@testkreis.de>
wrote:

> If memory serves (which is doubtful), the original intention of Pointer
> Gestures went beyond requiring single untimed gesture operation as
> alternative for any timed and/or complex gesture. It was also meant to
> cover situations where functions can be activated via a keyboard (such as
> closing a help popup that has no close button by pressing ESC) that may not
> be available on other devices that only have a virtual keyboard. The use
> case was that users may not able to bring up the virtual keyboard unless
> some text input gets focus (and even then there may not be an ESC on that
> keyboard). So a true equivalence between 2.1.1 (everything can be done with
> a kb) and 2.5.1 (Everything can be done with pointer) was once the
> intention - plugging a gap that has only become noticeable as kb-less
> devices have spread.
>
> As you talk about potential overreach, it would be good if you could
> provide design examples that would cause problems, examples that are not
> covered by the essential exception. James Nurthen just provided one
> https://github.com/w3c/wcag21/issues/496 which I will address on Github.
>
>
> On 9 Oct 2017, at 19:05, John Foliot <john.foliot@deque.com> wrote:
>
> Hi Jason
>
> You wrote:
>
> > *I agree with David that the pertinent question is as to the scope of
> the exception*
>
> I don't disagree. My comment was specific to David's question: "
> ​​
> Is there any other kind of pointer that is not single pointer that we need
> to add here?"
> ​
>
> JF​
>
> On Mon, Oct 9, 2017 at 11:23 AM, White, Jason J <jjwhite@ets.org> wrote:
>
>>
>>
>>
>>
>> *From:* John Foliot [mailto:john.foliot@deque.com]
>> *Sent:* Monday, October 9, 2017 12:13 PM
>>
>> On the mobile platform, there are multiple gestures that require more
>> than one "finger"/pointer (pinch to zoom, swipe up with four or five
>> fingers to access the multitasking screen for iPad users, etc.) In that
>> second example, my understanding of the intent behind the SC was to say
>> that in a scenario where multiple-finger inputs are the "traditional" way
>> of interacting, that we don't exclude users who cannot provide multiple
>> inputs, and that a single-input alternative is provided.
>>
>> *[Jason] On this interpretation, it still amounts to: “all functionality
>> that can be operated with pointer input can be operated with a single
>> untimed pointer gesture, unless a multipoint or untimed gesture is
>> essential”. This text doesn’t exclude multipoint or timed gestures as
>> alternatives.*
>>
>> *I agree with David that the pertinent question is as to the scope of the
>> exception, which takes us back to some of the comments summarized at the
>> start of this thread regarding drag and drop, for example.*
>>
>>
>>
>> ------------------------------
>>
>> This e-mail and any files transmitted with it may contain privileged or
>> confidential information. It is solely for use by the individual for whom
>> it is intended, even if addressed incorrectly. If you received this e-mail
>> in error, please notify the sender; do not disclose, copy, distribute, or
>> take any action in reliance on the contents of this information; and delete
>> it from your system. Any other use of this e-mail is prohibited.
>>
>> Thank you for your compliance.
>> ------------------------------
>>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>
>
>