Correct note on tabindexed elements and click event

[patrickhlauke]

It appears this is an oversight/typo, but: non-interactive elements that
are forced to be focusable with tabindex do NOT fire click when user
presses ENTER. xref w3c/html#637

[annevk]

The note is simply explaining the requirement above. It does appear implementations do not implement this: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4600, but I think they should unless there's a reason they cannot. (Maybe a compatibility issue at this point?)

The idea here is making it easier to write accessible code (and emulate behavior of built-in elements with activation behavior).

[patrickhlauke]

Ah so "an activation behavior that does nothing" is supposed to mean that the click event IS fired, but otherwise there's no default behavior? I read it as, essentially, "nothing happens" (not even the click).

It appears that most (all?) browsers (IE, Edge, Firefox, Chrome) don't fire click, which is why you commonly see keydown/keyup listeners used for keyboard accessibility on those types of forced focusable controls. Agree that they really should fire click though, but suspect perhaps the fact that they currently don't may be used in some cases as a very crude way to differentiate between mouse and keyboard activation in some scripts?

[annevk]

The main potential problem I see is that if we start firing click events in addition to the keyboard events, the developer-written controls get activated twice.

@dtapuska @smaug---- thoughts?

(I believe this change followed from some work I did at Opera, but I guess tests never got written and nobody else picked up on it. Yet another good reason to land tests with changes / file browser bugs.)

[patrickhlauke]

The main potential problem I see is that if we start firing click events in addition to the keyboard events, the developer-written controls get activated twice.

indeed. you'd get a repeat of the "touch events fire compatibility mouse events" dilemma, to an extent.

[smaug----]

I agree starting to fire click events more often feels rather risky.
Obviously I wasn't aware that the spec has had this note which doesn't match reality.
Firing click has been default action of 'enter' on certain elements.

But I do like what the spec has. Unfortunately making such change is rather difficult: how to detect whether websites would be broken if browsers started to follow the spec here.

[patrickhlauke]

sorry to labour to point, but relating still to the "The note is simply explaining the requirement above": does "an activation behavior that does nothing" mean that nothing happens if i press enter, or does it mean that click IS fired but no other default action happens in the browser? my initial reading of that sentence suggested the former interpretation, but it seems that the spec intends the interpretation to be the latter? in any case, this seems confusing (at least to me, but admittedly i've not delved too deeply into what "an activation behavior that does nothing" means...

[annevk]

@patrickhlauke apologies for not explaining. There's another section called "Activation" that has the following requirement:

The user agent should allow the user to manually trigger elements that have an activation behavior, for instance using keyboard or voice input, or through mouse clicks. When the user triggers an element with a defined activation behavior in a manner other than clicking it, the default action of the interaction event must be to fire a click event at the element.

So this doesn't strictly require Enter to be that key, since we generally do not make such specific requirements, but that would be the expected one (also used for activation of <a> and such).

But it does require that an element that has activation behavior (even if that did itself does nothing) can be activated somehow (which happens through dispatch of the click event and corresponding language in the DOM Standard that triggers on that event and runs the activation behavior).

[domenic]

Overall I think we should align with implementations here instead of hoping they will change. I think it would be a major compat worry and unless we have implementers actively excited about changing in the near future we should align.

If I am understanding correctly, that would mean updating the note, as this PR does, but we also need to make sure the normative requirements align with the note. I think that would mean simply removing

An element that has its tabindex focus flag set but does not otherwise have an activation behavior defined has an activation behavior that does nothing.

Then such elements like the div in Anne's example would not have activation behavior, and thus would not cause "The user agent should allow the user to manually trigger elements that have an activation behavior" to apply to them.

I guess the note would also be updated a bit to no longer say "This means that".

[dtapuska]

Looking at the Chrome code we do exactly as the spec currently reads. See https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLElement.cpp?sq=package:chromium&rcl=1477308281&l=1129 but I don't know why in practice it doesn't fire for Patrick's example. I'll try to debug it tomorrow.

[annevk]

@domenic if we cannot make it work I think we should strongly consider introducing a new feature, "activatable" or some such, to provide developers with the same convenience that built-in elements already have. Perhaps as an extension of custom elements or just something generic. Requiring non built-ins to account for all the possible ways in which something may be activated (especially over longer periods of time as UX evolves) is way bad.

[domenic]

Yeah, I think this would be a plausible addition to the custom elements wishlist, along with many other activation/accessibility/etc. features.

[domenic]

@dtapuska any updates?

[dtapuska]

It is only dispatched when spatial navigation is enabled. It was landed first here:
https://chromium.googlesource.com/chromium/src/+/9ffa0c28c03c87cc836fd8a9fc1faa5af481a2b4

[domenic]

Fascinating. I cannot find anything on how to enable spatial navigation in Chrome, but some Googling shows it might be enable-able in Opera?

I'm not sure what we should do with this exactly. Maybe we should say something like

The user agent should provide a mode which allows the user to manually trigger elements that have an activation behavior, for instance using keyboard or voice input, or through mouse clicks. In this mode, when the user triggers an element with a defined activation behavior in a manner other than clicking it, the default action of the interaction event must be to fire a click event at the element.

NOTE: such a mode cannot be turned on by default, as many pages add key event listeners in addition to click event listeners, and so turning it on results in both events being dispatched.

Then we'd update the note in @patrickhlauke's original PR to talk about firing the click event in this mode only.

---

Or, we could just remove it entirely, and leave this spatial navigation mode as some sort of outside-the-spec enhancement?

@smaug----, do you know if Firefox has any mode like this? Maybe when a11y technology is enabled?

[dtapuska]

chrome --enable-spatial-navigation

[domenic]

Right, I meant for users :)

[patrickhlauke]

Or, we could just remove it entirely, and leave this spatial navigation mode as some sort of outside-the-spec enhancement?

that would get my vote. i understand the desire that UAs should simplify developers' life by triggering click without the need for explicit keyboard handling, but saying that UAs should therefore provide some mechanism/mode is perhaps going outside of the purpose of the spec.

But I would like to see the current reality reflected in the spec. At a stretch, perhaps add a "User agents may provide a mode..." extra clause, just to open up the possibility of it happening (and to reflect spatnav scenarios)?

[mathiasbynens]

Fascinating. I cannot find anything on how to enable spatial navigation in Chrome, but some Googling shows it might be enable-able in Opera?

Presto-based Opera (i.e. up until v12) had spatial navigation as a user setting (opera:config#UserPrefs|EnableSpatialNavigation). We added support to Chromium but AFAIK Chromium-based Opera (i.e. v15 and up) doesn’t have a user setting to enable it.

[annevk]

Created a PR to remove this and tried to include my rationale in the commit message there.

[smaug----]

There is http://searchfox.org/mozilla-central/source/toolkit/modules/SpatialNavigation.jsm and
https://bugzilla.mozilla.org/show_bug.cgi?id=698437
Looks like that relies on whatever elements have default handling for enter key, and special cases . So, in general is very close to the desktop handling, if I read the code right.