Does "Click" literally mean just click event? What about other (accessible) ways of activating navigations via user action?

[mmocny]

Alongside of "click" events you could have other events fire (pointer, focus, change, etc). If one of those kicks off the navigation, presumably those could be a separate Task Attribution tree? And it could meet all the other criteria

Also, it seems possible to navigate using alternative inputs, which are still user driven, and which are still semantic, but that don't involve a "click" event at all. Perhaps using keyboard to navigate an application that offers keyboard shortcuts, or using keyboard to activate form elements (change or submit). Some of these may or may not fire click as well, I think.

[yoavweiss]

For some reason, I thought that "click" event also covers keyboard based "clicks". I now see that I was partially right: it does for buttons, but not for <a> based links.

Do you have a sense of which event types we would need to cover in order to properly capture keyboard based SPA navigations?

[mmocny]

I thought that "click" event also covers keyboard based "clicks"

Fun fact! If you actually add an href= to that link, suddenly it will fire click after keyboard activation :)

Other subtle things I've noticed while playing around with keyboard:

• You can use Space bar to activate click events on buttons and other input elements, but not links.
  • I see references to other button types for activating focused-element (i.e. via Android virtual keyboard/hardware buttons). I suspect these also just fire click.
• With "Enter" you get the click event on the DOWN part of the interaction. With "Space" you get click on the UP part of the interaction. I haven't audited mobile behaviour to see how exactly it differs.

Do you have a sense of which event types we would need to cover in order to properly capture keyboard based SPA navigations?

Given the above, I think you can probably just rely on click event, if you are only asking specifically about anchors/button activations. I also think that lines up with the default/declarative way to use navigation API.

You likely also want submit event for <form>.

This list breaks down the userInitiated concept and Same-document navigations, and the other things that pop our are: "Browser UI back/forward" (pretty important) and <area> (similar to <a>?).

But, there's a whole other can of worms once you consider programmatic activation since I think that can happen in the context of arbitrary user-initiated events.

Here's an example page that uses programmatic activation (in this case, it actually does it from click event handler... but still doesn't seem to count).

The navigate event in that demo seems to consider these types of programmatic activations as userInitiated: false -- but I'm not sure if that really makes sense in a world with TaskAttribution tracking.

[tunetheweb]

Using Forward and Back browser keyboard shortcuts (e.g. ⌘ + [/] on Chrome on Mac) can be used to navigate through an SPA, without a click.

Maybe should listen for keyup, keydown, and click events?

[dieulot]

Not accessibility related: Something I’ve been thinking about — but is seldom used in the wild — is to trigger navigation on mousedown instead of click (≈ mouseup).

That’s what some parts (though usually not “navigations”) of native interfaces use. Running Windows XP in a VM today feels super fast in part because of a liberal use of mousedown triggers.

You lose some power user advantages (mostly drag and drop, and mousing away to cancel a navigation) but I’m convinced you would come out ahead on user experience for most people. (That’s often a controversial take for power users though.)

It’s not really used in the wild as far as I know though, so not handling that case at least on first release might make sense.

[myfonj]

It’s not really used in the wild as far as I know though.

Probably not on the web, but, while not "navigation related", mousedown triggering view state change in most (Windows) desktop applications' menus still adhere to "single click and drag" tradition:

• open list with mousedown,
• open sub-list with mouseenter (:hover if you will),
• trigger item on mouseup".

So in Edge for example you can "drag" from triple dot menu button, through "Help and Feedback" and release mouse on "About Edge" to trigger it. This mechanism is pretty common in Windows desktop UI. Notable exceptions are Firefox' triple dash menu (but not regular "alt menu") and Windows 10 Start menu, what is a shame. (Windows XP start menu tree was definitely single-clickable.)

so not handling that case at least on first release might make sense.

Yes, from accessibility/portability point of view, I think such feature must be only supplemental to "normal" multiple discrete click/tap approach.

[yoavweiss]

Using Forward and Back browser keyboard shortcuts (e.g. ⌘ + [/] on Chrome on Mac) can be used to navigate through an SPA, without a click.

Interesting! What events does the SPA use to support this? popstate? navigate? Something else?

[mmocny]

What events does the SPA use to support this? popstate? navigate? Something else?

Likely so. It looks like we fire popstate for both "forward" and "back" navs, and the new navigate event as well. navigate also fires for form submit.

Something else?

I know for example that Esc key and modal dialogs were part of the research efforts during Navigation API development. The solutions for modal ended up mostly distinct, but I wonder if you can treat Esc as a form of spa nav...

---

Q: why is it important to hook onto click specifically? What about just using any Input that was considered a user Interaction? Then we could have similar concepts for Events, Layout Shifts, Paint algorithms, etc.

[tunetheweb]

As discussed, GitHub's keyboard shortcuts (type ? to see them) are another good example of actual navs - outside of the history api example I gave above.

For example typing gi on this page (outside of a text input) will take you to the main Issues tab.

[zcorpan]

@yoavweiss

For some reason, I thought that "click" event also covers keyboard based "clicks". I now see that I was partially right: it does for buttons, but not for <a> based links.

Your test is "wrong" because you have no href attribute and, therefore, it's not a link. Keyboard activation for <a href> fires click. See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/11055

Spec: https://html.spec.whatwg.org/multipage/interaction.html#activation

[yoavweiss]

Thanks @zcorpan for pointing out where I got things wrong!

With that in mind, I think the only case worth considering is the one Barry mentioned - that of keyboard shortcuts. I wonder if/how we can capture that without triggering the heuristic on every text input..

[yoavweiss]

Maybe a keydown event whose target is either the body/root element can be considered similarly to "click" for the heuristic purposes. That way it doesn't capture any input on a focused element.

[yoavweiss]

https://chromium-review.googlesource.com/c/chromium/src/+/4839506