Intent to Implement And Ship: <Enter on element with tab index should generate click event>

[Ramya]

Title:

Intent to Implement And Ship: <Enter on element with tab index should generate click event>

Body:

Contact emails

ram...@samsung.com

Spec

https://html.spec.whatwg.org/multipage/interaction.html#the-tabindex-attribute
https://html.spec.whatwg.org/multipage/interaction.html#activation-behaviour

Summary

As per the spec, the elements having tab index attribute are focusable and if it does not otherwise have an activation behavior defined has an activation behavior that does nothing. This means that an element that is only focusable because of its tabindex attribute will fire a click event in response to a non-mouse activation (e.g. hitting the "enter" key while the element is focused).

Motivation

If an element has tab index, it can be activated through mouse click or keyboard Enter key. As of now to trigger activation behavior from both inputs, developer will have to add keypress and click listeners. If we make the change as per spec,

click listener would suffice for both inputs (Mouse & Keyboard).

Compatibility Risk

As of now it is not supported in any of the major browsers like IE, Firefox, Chrome etc

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=122652

Requesting approval to ship?

Yes

 

Regards,

Ramya

[PhistucK]

Can you ask around whether the rest of the vendors are also going to implement this?

This means that "keypress" as well as "click" events will be triggered which might duplicate the outcome, which is pretty risky and confusing, especially if Chrome is the only one to behave this way.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Ian Kilpatrick]

Hi Ramya,

Do you have a good sense of what the Web Compatibility issues surrounding this change are?

At a first glance it seems that a lot of web apps (who currently listen to 'click' & 'keypress') would now handle the user action twice, which seems undesirable to Web Developers?

(Also just out of interest, is this a recent change to the spec?)

Thanks,

Ian

[TAMURA, Kent]

This behavior change would break existing web pages. The compatibility risk is high.

IMO, we shouldn't change the behavior, and should change the specification.

--

TAMURA Kent
Software Engineer, Google

[Daniel Bratell]

On Mon, 18 May 2015 15:17:08 +0200, PhistucK <phis...@gmail.com> wrote:

Can you ask around whether the rest of the vendors are also going to implement this?

This means that "keypress" as well as "click" events will be triggered which might duplicate the outcome, which is pretty risky and confusing, especially if Chrome is the only one to behave this way.

FWIW it is what Presto does when using spatial navigation (arrow keys on a remote control for instance, or shift-arrow in the desktop versions of Presto Opera). I can't recall seeing any specific bug reports related to that. The tricky part was focus/blur events in the pseudo-focus that we used, but sending click events seemed to be fine.

It is of course possible to create a site that will misbehave, but the alternative is typically that the site won't work at all since the page authors didn't have time/imagination enough to consider users with only a keyboard.

/Daniel

[Ian Kilpatrick]

FWIW it is what Presto does when using spatial navigation (arrow keys on a remote control for instance, or shift-arrow in the desktop versions of Presto Opera). I can't recall seeing any specific bug reports related to that. The tricky part was focus/blur events in the pseudo-focus that we used, but sending click events seemed to be fine.

'shift-arrow' & 'remote arrow-keys' are not a common input mode for the web. What concerns me is that 'enter' is a common input mode and handled by a lot of existing web-apps. (I know for certain that large web-apps listen for both click & enter-keypress).

It is of course possible to create a site that will misbehave, but the alternative is typically that the site won't work at all since the page authors didn't have time/imagination enough to consider users with only a keyboard.

The point isn't that it is possible to create a site that will misbehave. It's that there are potentially a lot of sites already created which will misbehave, potentially having serious compat issues.

I would be fine with this if there is proof that this wouldn't create compat issues.

Ian

[Rick Byers]

What would our guidance be for developers wanting to ensure their activation logic occurs exactly once on all browsers (those that support this behavior and those that don't)?  Eg. is there a way to feature-detect this behavior?  Or is there some way to tell that the 'click' event you just got actually corresponds to a previous keypress event (and so should be ignored if the keypress handler triggered the action)?

In general I'm all for applying 'click' more generally (it IS a generic activation event), but we need to be mindful of how to effectively move the web to this model without causing too much pain.

Rick

[PhistucK]

Remember that this model actually exists already - we are only talking about elements that are not activation elements, so <span>, <div> and such are affected, but not <a> and <button> (I think), because they are activation elements and already behave according to the proposed model.

The guidelines would be to move to <a> or <button> - all of the browsers behave the same there (I believe, I have not checked) and will simply trigger a click. This whole keypress workaround can simply be avoided at all by using the right element (right per the specification, per the expected and resulting behavior and per accessibility guidelines).

☆PhistucK

[dylan....@deque.com]

If a cancel (preventDefault) on the keydown event stops the click event from firing, then the compatibility issues would be reduced because good keyboard handlers should cancel events that they have processed in this way.

[Rick Byers]

On Wed, May 20, 2015 at 12:17 PM, <dylan....@deque.com> wrote:

If a cancel (preventDefault) on the keydown event stops the click event from firing, then the compatibility issues would be reduced because good keyboard handlers should cancel events that they have processed in this way.

It looks like cancelling the keydown does reliably prevent the 'click' on button, anchor and checkbox today.  So perhaps extending this to other elements with a tabindex isn't as risky as I feared?  There is certainly still some risk though.

FWIW, cancelling the keypress appears less consistent.  It prevents the 'click' on some elements but not others.

I'm surprised Firefox doesn't match the spec here (they tend to be quite good about this sort of thing).  Perhaps they have a good reason?  Ramya, can you poke around http://bugzilla.mozilla.org to see if you can find some discussion of this issue in Firefox?  /cc Olli who may have some thoughts off the top of his head.

Rick

[Daniel Bratell]

On Wed, 20 May 2015 16:46:26 +0200, Ian Kilpatrick <ikilp...@google.com> wrote:

FWIW it is what Presto does when using spatial navigation (arrow keys on a remote control for instance, or shift-arrow in the desktop versions of Presto Opera). I can't recall seeing any specific bug reports related to that. The tricky part was focus/blur events in the pseudo-focus that we used, but sending click events seemed to be fine.

'shift-arrow' & 'remote arrow-keys' are not a common input mode for the web. What concerns me is that 'enter' is a common input mode and handled by a lot of existing web-apps. (I know for certain that large web-apps listen for both click & enter-keypress).

That was to give some background to show that it was indeed a feature that has some history, and a broad deployment. We don't market Presto based Operas in consumer products anymore so it is history but what I learned in that history was that enter triggering activation helped more than it hurt.

It is of course possible to create a site that will misbehave, but the alternative is typically that the site won't work at all since the page authors didn't have time/imagination enough to consider users with only a keyboard.

The point isn't that it is possible to create a site that will misbehave. It's that there are potentially a lot of sites already created which will misbehave, potentially having serious compat issues.

I would be fine with this if there is proof that this wouldn't create compat issues.

That is pretty much unprovable. On the other hand, what about those sites that keyboard users can't access today? It's always a balance.

/Daniel

[Mike Lawther]

Yep, it's a balance. Let me rephrase - how confident are we that this will not cause differences in behaviour between Chrome and all other current browsers that will make users and developers cry 'this is broken!'. How confident are we that this number is small relative to the number of sites that keyboard users can't access today, and will be able to after this change?

[Ian Kilpatrick]

That is pretty much unprovable. On the other hand, what about those sites that keyboard users can't access today? It's always a balance.

I agree that the current situation isn't great for keyboard on sites which don't do this or use <a>/etc by default. This is certainly a problem that we should try and solve. This might be the right proposal to do it.

I'm asking that we understand the compat risks with existing websites on the web today. To be as clear as possible, we should not do this proposal if it causes lots of existing web sites to stop working.

I just checked a few web-apps. These are some that have registered 'keypress' & 'click' event handlers (on <div>, <span> etc elements)

 - gmail

 - google maps

 - google docs

 - evernote

This might be a risk as if they don't currently preventDefault the event, then it may be double handled. Concretely if  this is for a <div>-button which triggers a pop-up menu, the menu may never be shown.

It may be that the properties listed already handle it correctly. There should be research into this.

Thanks,

Ian

[Rick Byers]

How about this as a concrete step forward: we land the new behavior behind a RuntimeEnabledFeature currently marked status=experimental.  Then Ramya and a few others of us can easily spot test some popular websites and verify there's no obvious regressions.  If we don't hear immediate complaints within a few weeks (we do have a non-trivial number of dev-channel users that run with --enable-experimental-web-platform-features), then we try enabling and see how it goes.

The implementation isn't hard, so worst case we revert and we've learned something to perhaps change the spec.  Given Daniel's experience in presto, it seems worth trying without a huge amount of up-front research...

Rick

[PhistucK]

On Thu, May 21, 2015 at 5:01 AM, Rick Byers <rby...@chromium.org> wrote:

(we do have a non-trivial number of dev-channel users that run with --enable-experimental-web-platform-features)

​Intersect that with the number of users that only use the keyboard...

Hopefully, this will simply go smoothly.

☆PhistucK

[Ian Kilpatrick]

Additionally we could reach out to QA teams within & outside Google to help us test the change, to see what impact it has.

[Daniel Bratell]

I can only offer anecdotal evidence here but my experience from embedded Presto where a mouse like input device was missing, is that explicit keyboard support is rare, even from major sites[1]. If the site was simple enough to only use <a> and <button> it would work, but as soon as they had other elements that were possible to interact with like <div onclick> only (back then) non-standardized methods saved the users.

On the other hand, the suggestion here is that activation with enter should work for custom elements with the tabIndex attribute. If they have that attribute then the author has apparently already thought at least a little about keyboard navigation so we are not talking about the typical page.

/Daniel

[1] An early version of gmail was a favourite,. It had a single <div> with mouse handlers that manually figured out what you had clicked on. Presto's spatial navigation failed miserably there, and so did screen readers and other accessibility programs.

[Rick Byers]

On Thu, May 21, 2015 at 11:19 AM, Daniel Bratell <bra...@opera.com> wrote:

On Wed, 20 May 2015 19:54:05 +0200, Mike Lawther <mikel...@chromium.org> wrote:

On 20 May 2015 at 10:16, Daniel Bratell <bra...@opera.com> wrote:

On Wed, 20 May 2015 16:46:26 +0200, Ian Kilpatrick <ikilp...@google.com> wrote:

The point isn't that it is possible to create a site that will misbehave. It's that there are potentially a lot of sites already created which will misbehave, potentially having serious compat issues.

I would be fine with this if there is proof that this wouldn't create compat issues.

That is pretty much unprovable. On the other hand, what about those sites that keyboard users can't access today? It's always a balance.

Yep, it's a balance. Let me rephrase - how confident are we that this will not cause differences in behaviour between Chrome and all other current browsers that will make users and developers cry 'this is broken!'. How confident are we that this number is small relative to the number of sites that keyboard users can't access today, and will be able to after this change?

I can only offer anecdotal evidence here but my experience from embedded Presto where a mouse like input device was missing, is that explicit keyboard support is rare, even from major sites[1]. If the site was simple enough to only use <a> and <button> it would work, but as soon as they had other elements that were possible to interact with like <div onclick> only (back then) non-standardized methods saved the users.

On the other hand, the suggestion here is that activation with enter should work for custom elements with the tabIndex attribute. If they have that attribute then the author has apparently already thought at least a little about keyboard navigation so we are not talking about the typical page.

Yeah this makes sense.  Note that if they're doing this, chances are that they have at least some <a>, button or other input elements on the page too and so have probably already found they need to preventDefault the keydown event in order to avoid double handling with click.

I think we're overthinking this.  There seems to be non-trivial benefit to this change, the risk isn't obviously large, the code change is simple and well contained, and the spec is clear on the intended behavior .  Let's just co-ordinate with Firefox (see if they have any experience and/or interest in changing) and then try the change and see if it causes any issues.  This is what we have the channel release process for.

[Ramya]

Thank you all for the inputs.
Hi Rick similar bug was filed in Firefox in https://bugzilla.mozilla.org/show_bug.cgi?id=603200
Will follow up with the discussion there how they would like to proceed on this issue.

[Philip Jägenstedt]

Hi Ramya,

There's some concern that this might break sites that already handle
mouse and keyboard events separately. It's a bit similar to a change
to the <video controls> that I made and had to revert, where sites
would have to call event.preventDefault() in click events to prevent
the new automatic play/pause behavior, but of course no sites did
because they previously had no reason to.

To gather some data on this, you could add a use counter in the exact
place where you would fire the new click event, making sure to exclude
existing synthetic click events like for <button>. If that use counter
comes back with very low numbers, we'll know that the risk is
similarly small.

Philip