[Interest invokers] Keyboard inputs

[mfreed7]

This issue mirrors #1052, but to discuss the keyboard interaction pattern specifically, for interesttarget.

Pulling from the conversation on #1052, a few things seem clear to me:

• Activating the interestarget on keyboard focus seems like a bad idea. Users who are merely trying to tab their way through a document will get lots of "noise" with additional visual items showing up. Worse, if the activated hovercard contains interactive elements, those will be next in tab order and will re-route the user through each such hovercard.
• Some might say that adding a delay (i.e. focus an element for a period of time) alleviates the above problem, but it merely adds confusion. Users will now have to tab very quickly through documents for fear of accidentally activating hovercards along the way. The same is true of mouse users hovering elements; however, mouse users have the luxury of being able to move the mouse all the way out of the way, and then later back to the same spot within the document. Keyboard users have no such luxury - they are in a linked list of focusable elements, and can't easily traverse out of order.
• If focus cannot be the interesttarget trigger, then by definition the trigger must be another keyboard hotkey. The task becomes:
  1. Choosing a hotkey, and standardizing it, or...
  2. Allowing user agents to select the hotkey, and provide a way for users to discover the proper hotkey

I think the best for users would be #1, so that the same hotkey activates all hovercards, across browsers and platforms. Ideally this should be an easy hotkey to press, not requiring modifier keys, etc. Perhaps the best, most self-discoverable such hotkey would be either the up or down arrow?

My fear is that it'll be hard to find an available hotkey that works across all platforms and browsers. But perhaps the arrow keys might be one such option? I don't know what happens when you have something like a radio button group where each radio has an interesttarget, or similar situations. Perhaps we could just make all such conflicts illegal (ignore interesttarget)?

[lukewarlow]

I think if we had a hotkey we'd need to make sure it's remappable in browser settings per WCAG.

Arrow keys would be interesting, though idk if that would mess with navigation for stuff like focus groups where it's perhaps legit to have an interest target.

Coming up with a new pattern on top of a potential novel touch system does concern me from an is this thing going to be speccable perspective. Both technically and politically. But if it's necessary then it's obviously worth it.

[css-meeting-bot]

The Open UI Community Group just discussed [Interest invokers] Keyboard inputs, and agreed to the following:

• RESOLVED: add a UA stylesheet rule that indicates (when focused) that interesttarget elements are special. No need for anything more, e.g. a popup describing how to activate it. This indicator can't just be a change of the :focus outline style, because developers commonly override that.

The full IRC log of that discussion

<bkardell_> masonf: Just wanted to get more attention on this and talk about it - interest target needs a way (says, for example whatwg) that we need a way to always do this -- we just talked about how to activate with touch screens, now we need to talk about keyboards
<bkardell_> masonf: the one idea that came up which I think we rejected is when you focus it, it activates- it feels kind of parallel, but it turns out I think that that's not good for users generally because the tab key gets you through the document in order and it's kind of conflating two things
<scott2> q+
<bkardell_> masonf: the natural conclusion is that it can't be focus, it has to be some other key combination - the two options I think is that can be a standard one, or it just needs to abstractly require UAs to support
<masonf> ack scott
<bkardell_> scott2: I agree with everything you just said - I think I might have even been one of the people that pointed out that distinction you're talking about. there are even requirements for when something is activated on focus that there needs to be a way to dismiss it while still retaining focus
<brecht_dr> q+
<bkardell_> scott2: I would love there to be some indication that you can actually do this. I think some kind of styling might be useful - a default UA style that changes the focus indicator somehow - a slightly different variant that says "this thing is different and you can do something with it" - there is always going to be this problem with discoverability... if UAs could agree, that would be great
<bkardell_> scott2: across windows for a combo box alt+down arrow is the unofficial official way to activate it.. one of the reasons I think you would need a modifier key is that we don't want to undo the ability to scroll the screen with arrow keys - that is part of why I have been always against things like summary details or accordion using up and down -- it is very frustrating if you have a screen sized or positioned such that you can't actually do
<bkardell_> it
<masonf> ack brecht
<bkardell_> brecht_dr: +1 to the idea of having some kind of visual indicator that it will trigger an interest popover - an icon, could be on some pseudo element ... I think that works better than just learn keyboard behavior based on an outline - it's too subtle
<bkardell_> masonf: can you say - what do you mean by the pseudoelement
<bkardell_> brecht_dr: if you have a button with an interest target attached - it gets a pseudo element with some kind of indicator
<bkardell_> masonf: I had a similar idea that when you focus, something else shows up... but as Scott said it's a lot of popups
<masonf> There could just be a rule like `[interesttarget]:focus {outline: ...}`.
<bkardell_> scott2: I remember the idea that an information icon came up and was universally shunned - that is why I came up with an outline, to kind of split the difference - so there is some kind of default style where people could override it
<bkardell_> masonf: I think this is a pretty easy selector though, right?
<bkardell_> q+
<masonf> ack bkardell
<masonf> bkardell_: I actually liked the extra popup to show what the hotkey is for showing the hovercard. But as Mason points out, you can easily do that yourself.
<bkardell_> scott2: I would advocate that we have an indicator that all UAs can agree to and that we can make work 'by default' - websites can change it, but it's very well agreed and understood that a focus indicator means "this thing has focus"... in terms of people using screen readers and stuff, we can make that really clear. It's really the sighted keyboard user I think we need some visual indicator 'this is different'
<bkardell_> masonf: ok I think I see and I agree - do we want this to be default or just so simple you can easily do it?
<bkardell_> scott2: I think by default
<brecht_dr> +1 on by default
<bkardell_> q+
<bkardell_> q-
<brecht_dr> q+
<bkardell_> +1 on by default
<bkardell_> brecht_dr: that's kind of why I suggested a pseudo-element - if a UA changes something by default, someone can do their own icon which limits the discoverability, etc.
<bkardell_> q+
<bkardell_> brecht_dr: if it could be changeable that would help
<masonf> Proposed resolution: add a UA stylesheet rule like `[interesttarget]:focus {outline: ...}` to indicate that this element is special. No need for anything more, e.g. a popup describing how to activate it.
<masonf> ack brecht
<masonf> ack bkardell
<bkardell_> scott2: I don't disagree - people want to style stuff I just want there to be a way to have it by defaul
<masonf> bkardell_: I also prefer it to be default. If there's difficulty in that, I wouldn't necessarily want to die on that hill. Probably I wouldn't even require that people be able to change it outright, perhaps just customize it like changing the color.
<masonf> bkardell_: I prefer on by default, and prefer it to use color magic to make sure it's visible.
<masonf> Proposed resolution: add a UA stylesheet rule that indicates that interesttarget elements are special. No need for anything more, e.g. a popup describing how to activate it.
<masonf> Proposed resolution: add a UA stylesheet rule that indicates (when focused) that interesttarget elements are special. No need for anything more, e.g. a popup describing how to activate it. This indicator can't just be a change of the :focus outline style, because developers commonly override that.
<brecht_dr> +1
<masonf> RESOLVED: add a UA stylesheet rule that indicates (when focused) that interesttarget elements are special. No need for anything more, e.g. a popup describing how to activate it. This indicator can't just be a change of the :focus outline style, because developers commonly override that.
<masonf> bkardell - I'm guessing it's the "Show a quick highlight on the focused object" in settings? That shows a separate outline for a few seconds each time you focus something new.

[nmn]

Activating the interestarget on keyboard focus seems like a bad idea. Users who are merely trying to tab their way through a document will get lots of "noise" with additional visual items showing up.

I want to push back on this a bit. I think the "hovercard" pattern means showing the interesttarget on focus. The behavior is also consistent with how the content appears on "hover" when considering mouse interactions. There is also a major discoverability problem to hide the interesttarget behind a special hotkey.

However, I do agree with this part:

Worse, if the activated hovercard contains interactive elements, those will be next in tab order and will re-route the user through each such hovercard.

I think the way to solve this conflict is by having two states for the interesttarget:

1. An inert preview only
2. An "activated" state where it behaves more like a dialog and the interactive elements within become focusable.

We've used a similar pattern for Facebook recently and the pattern seems to be working very well. Here are some of the details:

• When a HovercardTrigger link is focused, the Hovercard becomes visible, but it is inert and all the content withing is aria-hidden and unfocusable.
  • There is one exception: There is a small helper text that says something like "press the up arrow key to access link shortcuts"
  • This helper text has an id and it is used as the aria-hint value on the HovercardTrigger link
• When the user presses the chosen hot-key, (up and down arrow keys in our case), the Hovercard becomes "active" and starts to behave like an interactive modal dialog.
  • The focus is moved to the first interactive element within the hovercard.
  • There is focus trapping
  • There is visible Close button
  • Pressing escape closes the hovercard and returns the focus to the HovercardTrigger link
• Pressing escape also always hides the Hovercard inert preview. Giving the ability to use the up and down arrow keys for scrolling again.

Extra Notes

• I do see the possible concern that showing a preview on focus can feel overwhelming and -busy, but I think the focus order problems can be solved by having the two "preview" and "active" modes for the interest target.
• The "visual treatment" for what appears on focus is up for debate. I could see an argument for letting the UserAgent choose the best treatment here.
  • It might make sense to show the entire hovercard (in an inert state) in some scenarios;
  • and, to show a much more subtle indicator in other scenarios.
• There are concerns today that taking over the up and down arrow keys is problematic because they are normally used for scrolling. Our rationale was that it is more discoverable for keyboard users that are used to Focus Group patterns. As a web standard and different hot key could be chosen which users would learn to use.
• There is a question about the "delay" after focusing a link similar to the delay after hovering a link.
• One big benefit of this approach is that it unifies the mouse and keyboard interactions and makes it easy to switch between the two input methods easily.
  • Hovering on the link shows the inert preview of the hovercard
  • Hovering on the hovercard "activates" it and moves focus to it behind the scenes.

[mfreed7]

Thanks for the points about keyboard focus. Let's Agenda+ to discuss it.

I've also added a bit more detail about the current direction to the explainer, in this PR: #1155. Of course, any/all of that can be changed if we need to change directions.