Re: Clarification for UI Request events (why no "activate"?)

On 05/02/2013 03:36 PM, James Craig wrote:
> +Doug Schepers
> 
> On May 2, 2013, at 1:50 PM, Eitan Isaacson <eitan@mozilla.com>
> wrote:
> 
>> Response below.
>> 
>> On 05/02/2013 11:38 AM, James Craig wrote:
>>>> For one, it is centered around a mouse metaphor and is not 
>>>> input-agnostic.
>>> 
>>> It's only mouse-centric in its onomatopoetic name. Click has been
>>> the de facto input-agnostic activation event for more than a
>>> decade, and user inputs from all modalities have the ability to
>>> trigger a 'click'.
>> 
>> I would say that it is more than name only: 1. It uses the
>> MouseEvent interface, that requires pixel coordinates,
> 
> 0,0 pixel coordinates suffice in most cases. More precise pixel
> coordinates can be extrapolated by rendered position and bounds of
> the element to be clicked. For example, when WebKit receives an
> AXPress action on an element in OS X, it sends the x and y
> coordinates of the 'click' event as the width/2 and height/2 of the
> rendered bounds, and this does not rely on mouse behavior. FWIW,
> WebKit also simulates mousedown and mouseup when an assistive
> technology triggers AXPress.
> 

I am familiar with that technique. This spec, in my mind, should be
discouraging that kind of pattern and any other form of input emulation
and synthesis. That is one for the primary goals of being input-agnostic.

>> modifier keys,
> 
> See the "mark request" link listed in the previous email.
> 

Right, my point was that 'click' is not input agnostic.

>> which mouse buttons (with the assumption that a proper click is
>> always the left button).
> 
> "primary button" I believe, which may or may not be the left one,
> depending on mouse preferences. The secondary action is usually
> triggered in the AX API with an AXShowMenu action.
> 

Same.

> See this 2009 thread about DOMActivate in favor of click. 
> http://lists.w3.org/Archives/Public/public-forms/2009Jul/0008.html
> 
> Maciej wrote:
>> Unfortunately, Web compatibility requires sending a "click" event
>> for non-mouse-driven activations. In particular, it is a common
>> practice to give an <a> element or an <input type="button"> element
>> an onclick attribute and the page author expects it to trigger even
>> for keyboard activation. This practice precedes the existence of
>> the DOMActivate event and remains common. Authors almost never use
>> a DOMActivate handler instead.
> 

Thanks for the link, I guess this is the discussion I was looking for
earlier. It puts a lot of this in perspective. I still think there is a
need for a mouse agnostic activate.

> I think you can still use DOMActivate if truly necessary, but most
> web apps use click handlers instead. Doug will be able to speak to
> this point better.
> 

DOMActivate was deprecated. And it is definitely humbling to think about
re-introducing something similar. But that is the goal of this spec.

>>> The primary goal of IndieUI is to let the OS or AT layer 
>>> determine what input is meaningful and pass that on to an app.
>>> For example, what you mentioned as "swipe" may in some cases, be
>>> sent as a "scrollrequest" or a "moverequest", but "swipe" in an
>>> of itself is tied to a specific interface.
>>> 
>> 
>> Correct. And I am arguing that click falls in the same category.
>> 
>> A click is distinct from a button press,
> 
> Sematically, I agree. Functionality, they are nearly identical.
> 
>> as a swipe is distinct from a scroll request.
> 
> The spec has events lists for "scrollrequest", "moverequest",
> "valueChangeRequest" and others that may sufficiently alleviate the
> need for most distinctions between a swipe and a scroll.
> 

My point was that we should be separating the input from the function.
Just like a swipe does different things in different apps, a click does
different things as well. Both a swipe and a click have the same
relationship with the resulting function. We have a few more decades
with a click so the separation of the input and outcome are foggy, we
say "click the link", when we mean "click the mouse button to activate
the link".

Also, this is quickly changing. I don't think it is common to hear
"click the button" when a touch screen is involved. They would say "tap
the button".

>> I think it is interesting that a SecondaryAction is being proposed.
>> One could make the argument that a secondary action, is really just
>> a right mouse click, since it is the de-facto input-agnostic method
>> for more than a decade.
> 
> Point taken, but it's debatable that simulating is input-agnostic. As
> far as I know, unlike click, there is no way to simulate a secondary
> mouse click from a keyboard or input methods other than specialized
> assistive technology.
> 

MS keyboards introduced the menu key, or Shift+F10. We still say
"right-click", but the function has been abstracted from the input.
Which is what I am proposing too.

>> I think that a PrimaryAction or DefaultAction request would
>> compliment it greatly :)
> 
> That's DOMActivate, is it not?
> 

Yes.

>>> MarkRequest: https://www.w3.org/WAI/IndieUI/track/actions/25
>>> 
>>> Other issues and actions for IndieUI Events 1.0: 
>>> https://www.w3.org/WAI/IndieUI/track/products/2
>>> 
>>>> I think it would fit under Indie-UI's goals to separate the
>>>> nuanced and fragile input interpretation from the actual
>>>> activation of a widget.
>>> 
>>> Do my responses above alleviate the concerns you have, or did I
>>> leave something unaddressed?
>> 
>> I hope my response clarified my earlier mail. I am raising this
>> issue because I am working on making Firefox OS accessible with a
>> new built-in screen reader. IndieUI is exactly what we need to make
>> this happen. Simply adding 'click' listeners can introduce
>> unintended consequences in apps that are heavily tuned to touch
>> interaction. That is partly my inspiration for my original example.
>> So I would like to see IndieUI go the extra step and offer a
>> complete divorce from the mouse event anachronism :)
> 
> 
> Unfortunately I think divorcing IndieUI from 'click' entirely would
> just result in a lot of web apps not working at all with IndieUI,
> which defeats the main purpose. If web apps don't yet work with
> DOMActivate which has been around for years, why should they have to
> use anything other than click? It's what the authors know, so let's
> keep it simple.
> 

Some thought would definitely need to be put in to a migration path.

> I remain unconvinced. Could you attend the next IndieUI conference
> call (Wed, May 15 at 2PM Pacific) to further discuss the idea?
> 

I would be happy to.

Cheers,
 Eitan.

Received on Friday, 3 May 2013 00:05:59 UTC