Continuing the discussion from Additional use cases for InputDeviceCapabilities just to keep this thread focused on the one specific use case being discussed:
Ah, cool. A pseudo-class in conjunction with this JS API makes perfect sense to me. Hopefully we can couple their definitions somehow (similar to how :focus and onfocus are coupled). Can you point me to the proposed semantics for the pseudo class? I.e. does this new pseudo-class also imply
:focus or would you use it together with
:focus? Is it just basically “this element was focused by keyboard”?
Perhaps we can even do the name bike-shedding together. Not sure if
:direct-focus works (i.e. an element that was focused by a device directly like a mouse) as a parallel to
InputDeviceCapabilities.directTargeting. Other possible name pairs (in both keyboard-positive and keyboard-negative senses):
- but bad for DPAD (and perhaps voice/assistive?) which is indirect but not really “sequential”.
- the key here is that pointers target elements at a point on a plane, while keyboard and DPAD do not).
- The more I think of it, I like this one. The key property is that focusing happens along some path (sequential or not), and so you need a visual affordance to show you were you currently are on that path.
@aboxhall, I don’t know much about the assistive tooling landscape here. What sort of DOM events do various accessibility technologies generate? Eg. if screen readers generate mouse events as they move focus around the page, is it helpful to have those mouse events also have something like
sourceCapabilities.serialFocusing==true to make it clear the mouse cursor wasn’t really positioned at a precise co-ordinate by the user? If so that might influence our semantics / name choice here. Or do the tools all just emulate a keyboard, and so solving this problem for keyboard is sufficient?